Created attachment 686 [details]
40 frames of 200ms each in data source "Live"
The attached file shows a capture with sigrok-cli of 40 frames with 200ms each.
[sigrok-cli -d rigol-ds:conn=vxi/192.168.1.250/5555 -l 5 --frames=40 -O srzip -o live.sr]
sigrok-cli concatenated the frames into one file, therefore I refer to the sample time.
The math channel is provided to detect the mismatches easier.
Analog channels CH1, CH2 and logic channel D8 are connected to the same signal and
I would expect the same signal on all of them.
1. 2600ms..2800ms The expected signals are shown on all channels -> ok
2. 2800ms..3000ms D8 shows a different signal than CH1 and CH2 -> not ok
3. 3400ms..3600ms CH1 shows different signal than CH2 and D8 -> not ol
It looks to me, that the time base waiting in protocol.c:rigol_ds_trigger_wait()
does not work for fast trigger rates, i.e. less than time needed to read-out all channels.
In case 2, the scope triggered probably while reading out CH2.
In case 3, the scope triggered probably while reading out CH1.
My current working branch to address this:
But I am unsure how Live, Memory and Segmented data source modes are supposed to work.
> The math channel is provided to detect the mismatches easier.
I cannot see the math channel, only CH1/CH2 and D8, I guess sigrok does not serialize/save that one?
But in any case, yes, the waveforms I'm seeing in your example .sr file match what I was seeing while probing a pair of differential USB lines (not attempting to actually get all the nuance of the communication since I'd need a 1.5GHz scope at least, not my MSO5000, I reckon)... but it illustrates what you are seeing here, indeed, as mentioned:
Psyched to see you managed to fix it on your _live branch, I would love to see that included in your ongoing PR (https://github.com/sigrokproject/libsigrok/pull/95) :)
I updated PR#95 to include everything that was in the _live branch and some additional changes