Problems on WaveForms with the sampling clock

[ManonH]

Hi,

 

I’m using ADP3450 to create a test bench for an analog pixel sensor in our lab. The pixels output at the same frequency as the input clock of the sensor, so each pixel lasts one clock period.

 As we need to go fast to have a maximum images per seconds, we need high frequency (10 or 20 MHz are the working frequency of our sensor), and we want to have as little data as possible, to reduce the amount of data to transfer. So, we want to sample only 1 point per pixel, so we created another clock delayed from the sensor frame, to be sure to sample the correct value of each pixel (green one in the oscilloscope pictures below), with an external generator, and we set it to trigger 2.

So we used the "Sampling clock" function with the trigger 2 in the WaveForms Scope to test, and created signals representing the sensor frame with an external generator (yellow one on the pictrures).

The blue signal below represents a marker which allows the acquisition to start at the moment the frame begins, so we put it as the scope trigger (on trigger 1).

 

 

4MHz picture :

 

 

5MHz picture :

 

 

5MHz picture zoomed :

 

 

 

 

 

Unfortunately, we notice that with the sampling clock, we don't get all the points of the signal as desired from a certain frequency (in "Repeated" mode). Up to 4MHz everything is fine, but from 5MHz onwards we only get one sample in two, in an alternating way (samples 1-3-5, then 2-4-6, then 1-3-5, etc.).

 

Screenshot of the 4MHz output :

 

 

 

Screenshot of the 5MHz output (2 parts) :

 

 

 

 

 

By increasing the frequency, this phenomenon persists, or even increases (even fewer samples taken).

However, we do not observe any problem upstream (see the photos of the oscilloscope), or via WaveForms if we remove the sampling clock (we see the whole frame correctly, see the screenshot below).

 

Screenshot without the sampling clock :

 

 

We also tried with Analog Discovery 2, the same problem occurs from 6MHz. With other display modes (Screen, Shift, Record), we can observe the phenomenon, and we can observe it even at lower frequencies.

 

As we have only generated a few pixels that represent the beginning of the frame, this represents only a few samples, and we do not think that this is a buffer problem, but perhaps we are mistaken.

 

So I’m here to ask the question, do you think we have misconfigured or misunderstood the operation of the sampling clock or the triggers, or even the device itself? If yes, what do you advise us to try or modify? If not, do you know where the problem can come from?

 

 

I hope that my problem is clear, if you have any questions don't hesitate.

Thank you,

Manon.

 

Edited April 13, 2022 by ManonH
I made a mistake by putting the wrong pictures in the post

[attila]

Hi @ManonH

The problem is that the ADC has a delay of about 18 cycles, 180ns at 100MHz.
When setting the Delay to 0ns internally it will take sample 180ns after the trigger to be in phase and this limits the sampling clock to about 5MHz.
The solution is to set Delay to None, which sets -180ns, and delay the Trigger2 signal accordingly.

Another solution would be using the Trigger2 as reference clock input (10-50MHz) for the device. The system frequency should be between 50-125MHz so low freq reference clock will be upscaled and triggered should be used to sync with the source.

Edited April 13, 2022 by attila

[ManonH]

@attila

Thank you ! From what I have tried so far it works (maybe some adjustments to do with frequency) !

 

[attila]

Hi @ManonH

In the latest version the rate limit is removed for sampling clock with delay between -180ns and +120ns @ 100MHz.
Edit: Your setup should work even with 0ns delay.

 

Edited April 13, 2022 by attila

[ManonH]

Hi @attila,

Thank you, this will be helpfull. 

 

I have an other question I hope you can help me with.

For our sensor, we need to acquire 128k samples continuously, without any kind of losses at any time (or else our data can't be used), at the minimum (more would be better but if we can't it's not a problem). We do not fully understand how the "Record" mode of the scope works, in particular how the buffer is filled/vacuumed. 

When I'm using the Record mode with basic signal types (using WaveForms) for 256ki I see losses in the samples, and so we asked ourselves if it is because the buffer has a maximum of X samples and then display them and then acquire again X samples, etc, or if it acquires less than the X maximum samples because it's programmed like this, and we can change it.

If it's not programmed like this with WaveForms, can we change it with an option ? Or is there an option in the SDK to control this acquisition/buffer size ?

 

I hope this was clear enough.

Thank you,

Manon.

[attila]

Hi @ManonH

I think I've managed to reproduce. It will be fixed in the next version.
Until this to overcome the problem set 125MHz system frequency.

 

With the Standard boot mode it should be able to capture 128Mi samples at up to 125MHz.

[ManonH]

Hi @attila

Thank you for your quick response.

I did not succeed in obtaining an acquisition without loss of samples, at 125MHz for 128Mi samples one sees well that there are cuts, of rather different size, of which I do not know the cause. I do not observe these cuts for 125MHz with fewer samples (below for 512Ki samples), nor with a lower frequency (I took 5MHz, arbitrarily). However, I still observe sample losses at some points (see the captures below), and I don't know where this can come from. Don't hesitate if you think I did something wrong

 

128Mi samples at 125MHz : 

 

512Ki samples at 125MHz :

 

 

512Ki at 5MHz :

 

What we would need to know is whether the data transmitted by the ADC is put into the buffer directly, without interruptions, and then sent to the PC (which we assume); or whether the data is sent directly to the PC and uses a buffer on the PC/software?
In the first case, the loss would then come rather during the buffer/PC transmission or possibly during the display? 
Moreover, we suspect that the device is designed to send the data from the buffer regularly, so as not to have an overflow, which could also explain these "losses" (which would then be the transmission time to the PC); and in this case, is it because the buffer is indeed limited to 32Ki and must empty itself every 32Ki (or before)? 
As we have to have 128Ki continuously, a buffer limited to 32Ki would be a problem, but if it is only a question of transmission it can be solved.

 

I hope I was clear enough to explain what I need to know exactly (even if we think it's ok, we need to be sure).

 

Thank you,

Manon.

[attila]

Hi @ManonH

I just notice from your screenshots that you are using Linux mode. With this the recording/streaming is limited by the USB bandwidth to about 2MSps
With Standard mode more buffering is available up 128Mi samples @ 125MHz or unlimited @ about 4MSps

 

In the latest version a DDR buffering problem is partially fixed:

I think it will work for your use case.
It is still not working perfectly when the system frequency is set to fractional values (like 124.9MHz) and the noise band at lower rates (<3MBps).
I've added a temporary option to disable the "DDR recording". This should work fine at lower rate < 7MSps

[ManonH]

@attila

 

Indeed, I had not noticed that I was in Linux mode, thanks for the remark. As i'm using Windows, I didn't check that.

As for our acquisition, I think it was not clear that we could acquire the samples without interruption, even beyond 32ki. The more important is that it is possible, even if the transmission afterwards takes time. Thank you for your responsiveness, we will dig on our side and if we have other problems I will not hesitate to ask you.

On the other hand, I would like to ask another question, without much connection. As I am currently doing an internship, I will have to write a report. Would it be possible to use the images of the presentation of the equipment or some diagrams explaining its functioning for my report?

 

Thank you for your response,

Manon.