DAC to ADC configuration using AD1939

Hi Anil,

When converting from a fixed-point to a floating-point type, the result is the closest floating-point value to the operand and leads to some precision loss.

Please refer in the below VisualDSP++ help path:

C/C++ Compiler Manualfor SHARC® Processors > 1 Compiler > C/C++ Compiler Language Extensions > Compiler Built-In Functions > Fractional Built-In Functions

C/C++ Compiler Manualfor SHARC® Processors > 1 Compiler > Using default Fixed-Point Types > Data Type Conversions and Fixed-Point Types

Can you please let us know if you have experiencing any loss of precision when converting from fixed to float, or is the data completely different. So the we can guide appropriately

Regards,
Nandini C

Hi Nandini,

Thank you for the reply,

For example iam sending a sinewave from transmitter using DAC with 48k sampling rate and fc=1800Hz at tx_block_pointer the samples and plot which i observed both in software and oscilloscope getting similar,while at receiving end the after adc output that means fixed to floating point conversion hits completely different values but that values representing a sine wave but not the same frequency and sampling rate and values are often changing whenever i click the run option.the values are changing instantly suppose at trasmitter side for sinewave possitive half cycle repsenting 6 values then at receiver side it representing 4/5/6 and sometimes it starting with negative values..Hope you understood..if you are not able to understand i will try to send the snippets of waveform and values if possible i will try to add code snippets also.

Regards

Anil

Hi Anil,

Yes, we understood the issue occurs after the fixed-to-float conversion. To assist you more effectively, could you please provide the following:

Probe images along with the buffer values of the ADC output (rx_block_pointer) and after the fixed-to-float conversion?
Details on whether you are using a built-in function or the FLOAT instruction for the fixed-to-float conversion
ADC and DAC configuration settings

If possible, please also share a sample project along with the input data so we can replicate the issue on our end.

Regards,
Nandini.C

MEL.zip

Hi Nandini,

Please find the attachements.

I want to clarify that iam using builting functions only which was in examples, also the modulation_out variable which you can find in main function is the what we are transmitting and sample variable is the received one which you can find in block_process_audio.c file.

sorry for that as Iam not able to attach values of input(modulation_out/tx_block_pointer) and output(sample/rx_block_pointer) due to unable to copy of that values.Also here in image of RX first 256 samples are input and next are received values which are improper values coming in between.please check once

I don't know whether it is clipping/ADC saturation/conversion problem the values are not coming properly and I think i configured external loop back correctly,please correct me if im wrong

Thanks in advance

Anil

Hi Anil,

We are looking into this and get back to you shortly.

Regards,
Nandini C

Hi Nandini,

I also want to ask that sometimes number samples/cycle at transmitter side was not same at receiver side and i observed that the values around  0 are not able receive at receiver side.

for example at transmitter side if the values are 0.4564,0,58323,0.75234,0.0015234,0.000532.after DAC output

the values of 0.0015234,0.000532 was not able to recover after ADC output

all these when DAC connected to ADC

Regards

Anil

Hi Anil,

While analyzing the modulation_out values, we found that the issue is caused due to the overflow during the float_to_fix conversion.

To address this, we recommend enabling saturation mode by setting the ALUSAT bit in the MODE1 register before processing begins. When the ALUSAT bit in the MODE1 register is set (= 1), the ALU is in saturation mode. In this mode, positive fixed-point overflows return the maximum positive fixed-point number (0x7FFF FFFF), and negative overflows return the maximum negative number (0x8000 0000). If saturation mode is not set, an infinity input or a result that overflows returns a floating-point result of all 1s.

Alternatively, you can use the default fract fixed-point type to generate equivalent code. In this case, you can cast between fract and float types directly, without using a built-in conversion function. This cast behavior is independent of the rounding mode set in the MODE1 register, unlike the built-in conversion.

Below is sample code to cast the fract-typed argument to float type without using the built-in conversion.

#include <stdfix.h>

void fixed_to_float(float *output, const fract *input, int num) {
int i;
for (i = 0; i < num; i++) {
output[i] = input[i];
}
}

Could you please test this and let us know the results.

Additionally, the code currently configures the ADC and DAC for 8 channels. Please update the channel settings to ADC_CHANNELS_2 in the ADCCTRL2 register and DAC_CHANNELS_2 in the DACCTRL1 register. Hope you have only copied the left channel data to tx_block_pointer for testing purpose.

Regarding “I also want to ask that sometimes number samples/cycle at transmitter side was not same at receiver side and i observed that the values around 0 are not able receive at receiver side.”
>> Could you please clarify whether values around 0 are never received on the receiver side, or if this occurs intermittently?

Regards,
Nandini C

Hi Nandini,

Thank you for the reply,

Iam looking into this, I will update as soon as possible

Regards 

Anil

MEL_rx.zipMEL1_tx.zip

Hi Nandini,

Apologies for the delay

>> Could you please clarify whether values around 0 are never received on the receiver side, or if this occurs intermittently?

As discussed in earlier question similar problem encountered with when we transmit RRC coefficients. The result almost similar when we use both built-in conversion function and const fract function. At the receiver end the values are completely different and getting an offset(DC) value also(kindly check my intuition correct or not?). And my question why the values are not coming straight at the receiver end when transmit any data? To see that full cycle of values do we need to increase the receiver buffer size? or Is it because of circular buffer?

Here I am attaching the project files for both Tx and Rx and snapshots of tx_block_pointer and rx_block_pointer with received values you can check with it transmitter values which are in main function. Please kindly help in this regard.

>>To address this, we recommend enabling saturation mode by setting the ALUSAT bit 

when I am trying to set the ALUSAT bit the program getting halted and not running.

>>you can use the default fract fixed-point type to generate equivalent code.

Yes I tried the with fract function also the result is similar to built-in function output.

>>the code currently configures the ADC and DAC for 8 channels.

Yes i changed both in SPORT_TDM function and in ADSP21489_ezkit.h also nothing much changed

Regards

Anil

Hi Anil,

To assist you more effectively, could you please clarify the following points:

1.Has the sine wave clipping issue been resolved by setting the ALUSAT bit, or by using the default fractional fixed-point format?
2.Are you using a custom board or an EZ-KIT?
3.Are you using two EZ-KITs, where EZ-KIT 1 transmits data to a DAC, and the DAC output is connected via RCA cable to the ADC of EZ-KIT 2, with the data from EZ-KIT 2 being plotted?

Regards,
Nandini C