Topic: FMC150 Crosstalk Issue  (Read 5573 times)

jwdonal April 28, 2014, 02:52 PM

  • Member
  • *
  • Posts: 15
Is 4DSP aware of any crosstalk issues on the FMC150 board?  I have the FMC150 board connected to the Zedboard and I performed the following test:

1) Loop back DAC0 output to ADC0 input with direct cable (i.e. nothing in between input/output)
2) Loop back DAC1 output to ADC1 input with direct cable (i.e. nothing in between input/output)
3) Drive sine wave on DAC0 output
4) Drive flat 0V signal on DAC1 output
5) Get a capture from ADC0
6) Format ADC0 capture as WxH bitmap based on length of sine wave and the number of repetitions captured

The result can be seen in the attached image x_is_sine_y_is_0.png. The result looks correct. You can clearly see the sine wave driving the brightness/darkness of the image as it rises and falls.

Now let's do the same thing but this time set DAC1 to _also_ output a sine wave.  Here are the steps:

1) Loop back DAC0 output to ADC0 input with direct cable (i.e. nothing in between input/output)
2) Loop back DAC1 output to ADC1 input with direct cable (i.e. nothing in between input/output)
3) Drive sine wave on DAC0 output
4) Drive sine wave on DAC1 output
5) Get a capture from ADC0
6) Format ADC0 capture as WxH bitmap based on length of sine wave  and the number of repetitions captured

The result can be seen in the attached image x_is_sine_y_is_sine.png. This result is not good.  *Remember*, we are capturing from the ADC0 input __only__.  The DAC1 output is connected to the ADC1 input and should have no effect on what is captured on ADC0.

Does 4DSP have any thoughts on this?

tonyku April 28, 2014, 03:17 PM (#1)

  • Administrator
  • Member
  • *****
  • Posts: 196
Hi,

Can you send us the *.txt files (i am assuming you're using the reference application) on both the DAC and ADCs?  It's hard to make out what it shows on your screen capture, so we'd prefer it to be the raw data that we can look at.  The reference app should generate both the ADC and DAC files in ASCII format that you can attach to the post.

Thanks.

jwdonal April 28, 2014, 08:40 PM (#2)

  • Member
  • *
  • Posts: 15
The ASCII version of the ADC0 captures are too big so I have provided them in binary format - you can convert them to ASCII on your end.  I have provided the DAC files as text though.

Please note that I am referring to DAC0 as X-coordinate output (i.e. pixels across the image horizontal) and DAC1 as the Y-coordinate output (i.e. each row of the image).

The DAC0/DAC1 waveforms are both 1024 samples long with the sine wave period set to 1024 samples. So if you want to convert the data files I have provided to an image then you should treat the image as 1024x1024 pixels (like I did).

I have also provided a screenshot of the VisualAnalog plot that you guys seem to like using.  The left plot represents the x_is_sine_y_is_0_adc0 capture while the right plot represents the x_is_sine_y_is_sine_adc0 capture.

The evidence is essentially undeniable that crosstalk is occurring somewhere. We are working on narrowing down where the crosstalk is occurring, but it's somewhere on the FMC150 board. The crosstalk does not occur when the DAC1-to-ADC1 loopback cable is disconnected. This tells us that the crosstalk is not occurring at the DAC0/DAC1 outputs. The crosstalk does occur even if the 2 shielded loopback cables are separated by a great distance.  Therefore, the crosstalk is most likely occurring at the ADC input side. We are attempting to narrow down from there.

Has 4DSP never seen this behavior before? We have 3 FMC150 cards - this crosstalk issue occurs on all of them.  This problem could be easily missed depending on a user's application or your testing platform so it's possible that no one has ever noticed until now.

ebarhorst April 29, 2014, 03:24 AM (#3)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Hi


have you also been able to quantify the cross talk in the frequency domain? Typically the cross talk figure depends on the frequency of your signal and is expressed in dBFS. the cross talk should be less than -65 dBFS at 110 MHz.
What is the maximum cross talk that your application is targeting?


best regards,
Erik

tonyku April 29, 2014, 12:01 PM (#4)

  • Administrator
  • Member
  • *****
  • Posts: 196
Hello,

I took your binary file, x_sine_adc0.bin and converted it to a text file.

The output shows what you have shown on the graph on the right.

However, this problem can be seen even if you were to load the first 1024 or 2048 samples and display it in the frequency domain - i.e. you simply get a blob of frequencies and the fundamental frequency will be incorrect.   You can also try it on your end - look at the frequency plot of the large data acquisition file of, let's say, the first 2048 samples and the results are the same.

Our reference design (firmware) does I believe 16k sample acquisition and I have not seen this problem (if it shows up in 2048 samples, surely it'll show up in 16k samples).   We also have the FMC Analyzer software that runs an acquisition of 8k samples 10 times a second and the frequency plot doesn't show the issue either.

I assume this is a custom firmware on your end that does the large data acquisition?  Also, what version of the FMC150 are you using?  Is it a DC coupled version?




jwdonal May 02, 2014, 10:53 PM (#5)

  • Member
  • *
  • Posts: 15
The problem turned out to be the fact that all 3 of our boards had been modified to have DC-coupled outputs on the DACs. The modification did not use active current/voltage conversion components and was instead simply a resistor divider network. This was causing the DAC output voltages to affect one another. This was a modification that was performed in-house and not by 4DSP.

We will probably be switching to FMC151s since I assume those boards would not suffer from this same issue.

ebarhorst May 05, 2014, 10:08 AM (#6)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Hi,


thank you for your feedback. If you have no further questions regarding this subject I will proceed to close the topic


thanks,

Erik

arnaudNL May 08, 2014, 06:44 AM (#7)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
This topic is being closed because the issue is considered as resolved by 4DSP. Feel free to create a new topic for any further inquiries.