search

fair-acc / gr-digitizers

GNU General Public License v3.0
3 stars 3 forks source link

No digital trigger received when downsampling mode is used #80

Open alexxcons opened 2 years ago

alexxcons commented 2 years ago

When sampling with e.g. 125 MS/s or less, without downsampling, triggered measurements, the trigger can clearly seen (A jump from 255 to 256 or something like that on digital port 0)

When sampling with downsampling 250MS/s and downsampling factor = 8, the received data on that digital port is always 0 (though the measurement is still triggered)

Seen on dal025: https://gitlab.com/al.schwinn/DigitizerDU2/-/blob/master/src/test/dal025/dal025.grc (ps3000)

Possibly related: #73

alexxcons commented 2 years ago

Possibly related: https://github.com/fair-acc/gr-digitizers/pull/99

RalphSteinhagen commented 2 years ago

The 'down-sampling' mode is probably not what you expect it is ... it takes the raw rate and (unfortunately in the driver not device) takes every n-th sample and drops all samples in between. There is no averaging nor zero-order-hold involved.

Thus if a trigger occurs between two samples, it is simply dropped. Thus the described effect is the normal behaviour.

My guess is that the 'down-sampling' mode shouldn't have been used in the first place because it's also dangerous in terms of generating aliasing effects.

I'd suggest to close this because it's not really an issue/bug but defined behaviour.

alexxcons commented 2 years ago

The 'down-sampling' mode is probably not what you expect it is ... it takes the raw rate and (unfortunately in the driver not device) takes every n-th sample and drops all samples in between. There is no averaging nor zero-order-hold involved.

Ouch, if so, the current settings on the digitizer-block are heavily missleading (where you can select 'average', 'min/max' and just 'decimate'.

Thus if a trigger occurs between two samples, it is simply dropped. Thus the described effect is the normal behaviour.

My guess is that the 'down-sampling' mode shouldn't have been used in the first place because it's also dangerous in terms of generating aliasing effects.

I'd suggest to close this because it's not really an issue/bug but defined behaviour.

The first post of the issue says that the scope was triggered, just the digital ports did not show the trigger pulse ... so that sounds like a diffrent story.

I will re-test, and close the bug if indeed nothing happens on both sinks when watched simultaniously.

RalphSteinhagen commented 2 years ago

For the triggering the digitizers sees all samples (actually internally at 5 GS/s) and thus triggering is always working regardless on the data export.

heavily missleading (where you can select 'average', 'min/max' and just 'decimate'.

I was also wondering whether we should drop this when I learned that these features are not part of the actual digitizer firmware but simple post-processing to simplify the decimation of the UI (apparently decimating in the driver is faster than in the Windows app). However, I have been in contact with the guys at PicoTech and continue to entice them to make this an actual FPGA firmware feature since this would help both the ENOB figure and reduce the number of samples one has to actually transfer via the bus. There won't be a short-term change but who knows ... we are getting visitors from Picotech in March...