Setup:
--RF signal is filtered using analog filters (BPF- 50 MHz to 150 MHz)
--Signal is fed into ADC08D1520
--ADC08D1520 settings : Sampling Rate-1 Gs/s , DES mode , DDR mode
--Digital signal is fed into FPGA for signal processing
Experiment :
-- 80 MHz, -30 dBm Sine wave from signal generator
-- Raw time domain data is written into a file from FPGA
Observation:
-- We are seeing spurious spikes in FFT at frequencies other than Harmonics. Please see attached pic.
-- Spikes come and go randomly in the data
-- Closest Spike always appear mirrored at 62.5 MHz. i.e if Input frequency is 80 MHz spike is at 45 MHz. Input at 90 MHz has spike at 35 MHz
-- We verified input to ADC is clean , free of any noisy frequency component.
Any advice where this noise is coming from ?
The first two suspects to check are clock and power supply:
http://www.ti.com/lit/an/slyt338/slyt338.pdf
Did you try to check the FFT output with no input?
Did you try to change the input signal amplitude to see how this affects the spur?
All the best,
Albert
The clock(500 MHz) and power supply (2.7 V) looks clean. In absence of a signal I do not see such behaviour. Actually it is hard to say. When we have a good input signal these spikes are clearly visible.
Its interesting to note that if the sampling is 125 Ms/s one would expect to see 80 MHz as 45 MHz. Though in our case we are sampling at 1 Gs/s all the time. Thought if this might help in understanding the problem.
An added note regarding this implementation:
With Dual Edge Sampling and DDR mode, each of the 4 registers are actually being read at 125 MHz. It is not clear if this is a real harmonic or not; however, this is not always present in the data, so it does not seem to be this issue (this would always be the case if so). I'm thinking it may be a phase related issue, which may make something like this show up intermittently.
Hi Abhi
First I would like to make sure I understand your system:
1) It sounds like this is a board of your own design, can you confirm this?
2) You state the supply voltage is clean 2.7V. Can you confirm there is actually a clean 1.9V supply to the ADC?
3) I have seen similar odd FFT signatures when the output data for the converter being combined out of order before further processing. To confirm the capture and re-ordering is working correctly, please capture some data with TPM (Test Pattern Mode) enabled. The data captured should match that of the following table from the datasheet:
Please note that when combining the data from the 4 ports, for DES mode operation, the order should be as follows:
Earliest Sample to Latest Sample -> DQd, DId, DQ, DI
So the combined data from that table should look like:
01h, 02h, 03h, 04h, FEh, FDh, FCh, FBh, 01h, 02h, 03h, 04h, FEh, FDh, FCh, FBh, 01h, 02h, 03h, 04h (then sequence repeats)
01h, 02h, 03h, 04h, FEh, FDh, FCh, FBh, 01h, 02h, 03h, 04h, FEh, FDh, FCh, FBh, 01h, 02h, 03h, 04h
Please confirm and test these items, and let me know what you find.
Best regards,
Jim B
Hi Jim,
1) Yes, its our own board with filters before ADC and data going into a FPGA
2) Supply voltage is 1.9 V
3) We are verifying the TPM mode.
Can you advice what is the input range for this ADC ? We are a bit confused what we should read (bits) when we input a sine wave with no offset into the ADC.
Thanks,
Abhi
For an AC coupled input signal (capacitors between the balun or amplifier outputs and the ADC Vin+/- inputs and with the Vcmo pin connected to GND) you should see the following:
With the input signal turned off, you should see mid-code values, around 127, 128 decimal.
With the input signal turned on, you should see the sinewave centered around the mid-code values. As the input amplitude is increased you should see fairly consistent approach of the sine peaks towards the Zero and Full Scale values.
If you are working with a DC coupled signal (only recommended if you really need the DC information) your driving source must provide the proper common mode to the Vin+/- inputs. This is done by using the voltage at the Vcmo pin (not grounded in this case) to set the common mode of the driving amplifier.
I hope this is helpful. Let me know how the debugging goes.
Jim,
The manual never explicitly states it, but it seems that the test pattern will not output when in the 1:4 Demux mode (DDR and DES). Am I right that the test pattern for 1:2 Demux mode is only true for non-DES? The manual implies that the only test pattern output for DES mode will be for non-Demux, in which case I have no idea what to expect in the DQd and DId registers.
Hi Andrew
I'm sorry the product datasheet isn't clear on this topic. The Test Pattern Mode is independent from the DES or non-DES setting. The DES setting affects the clocking of the internal ADCs, and the configuration of the input Mux circuitry. It doesn’t change anything in the output section of the chip, which is where the TPM is generated. Therefore the output data pattern will be the same for non-DES 1:2 demux DDR and DES 1:4 demux DDR modes.
Have you experienced issues with TPM appearing not to work on hardware, or were your comments just based on review of the datasheet? If you have had issues with hardware I would like to help you resolve them.
I hope this is helpful.
When I made the assumption that the test pattern will only work in non-Demux DES mode, I was able to generate the pattern below, which looks correct given Table 7 in the datasheet. I did this by ignoring every 2 samples in the recorded data set, and assumed the "good" values were DI and DQ and that the values I was ignoring were DId and DQd.
Given your comments about the test pattern correctly outputting in 1:4 Demux (with DES) mode, I get the following test pattern:
Comparing to Table 6, this means that the "correct segments" are coming from DId and DQd and that it is DI and DQ that are "incorrect." When an edge is present from the ADC output clock, are DId and DQd already set, and it is only DI and DQ that are affected by the t_osk delay time? Could this mean we do not have enough delay so DI and DQ are just not ready to be sampled at the time we are sampling them? Have you ever seen this pattern before?
Thanks for all the help with this.
I realize I made some incorrect statements in my last post. I was running a system set in non-Demux and DES mode. I didn't think the test pattern would work Demux mode with DES, so I had the system configured to non-Demux mode. I think the first figure is correct since there shouldn't be any interleaving in the non-Demux mode.
After trying the 1:4 Demux settings, I was able to successfully get the test pattern. In our system we are recording 2048 samples at 1 Gsps, and then repeating this every millisecond. In about 10-40 records out of 60k records, we get data that look like the figure below, where the test pattern stops being correct. This only lasts 1-3 records (so presumably 1-3 milliseconds) and then returns to being correct for each 2048 sample record. There does not appear to be any periodicity or pattern to the test pattern being incorrect (see the second figure).
I'm glad you've made progress on this. I know that we have never experienced any issues with the Test Pattern output of these devices, so the ADC should not be causing this problem.
The pattern definitely looks correct in the first half of your upper diagram. The second portion shows the proper values, but the sequence is changed somehow. Since the values always seem to be correct, I don't think the problem is related to the initial capture into the FPGA, it is something later in the data flow.
I'm thinking the problem is somehow related to the data storage to FPGA memory and subsequent readout from memory. If you haven't used the ADC08D1520DEV evaluation board design package as a reference for your FPGA design, it might be useful to review for guidance. The package is available for download here: http://www.ti.com/litv/zip/snac035
One thing you could try to isolate the problem might be reducing or increasing the ADC clock frequency if possible. That might point to the weak area.
If I think of any other potential debugging ideas I'll let you know.
I'm just checking in to see if you have made any progress on the data capture issue. Please let us know if you've resolved the issues, or have found any new clues.
We are still seeing the same issue. I am inclined to agree with you that this is likely not an issue with the ADC. We are currently working on the rest of the data flow in the FPGA. Thank you for your help and comments.
Thanks for the update. I'm going to close this thread for now, but if you learn anything new about what's going on please let us know.