I dont think it will continuous fills the memory non stop, and never stop, there will be some dead time...?
to do things i mentioned above. Maybe i am wrong, but i dont think the DSO is a real time non stop sampling device.
Teneyes,
Try adjusting the trigger Holdoff time to around 3 - 4 mS.
It looks like the trigger circuit has re-armed and is triggering on the next pulse that it sees.
Teneyes,
Try adjusting the trigger Holdoff time to around 3 - 4 mS.
It looks like the trigger circuit has re-armed and is triggering on the next pulse that it sees.
i think the same, it triggers on the first on going pulse.
I did the same test, and indeed, it triggers on the fist pulse it finds, i think thats is correct
Played around with the delay, and that worked for me.., then it triggers oke
Can anyone Confirm that the DS2000 does NOT decode when recording frames?
Hi Len,
It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.
It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.
Mark, did you miss this demonstration, where teneyes showed it working on a DS2000? (Post capture, not real-time.)
It does not decode recorded frames. I thought this was reported and confirmed here awhile ago when first reported on one of the UltraVision models.Mark, did you miss this demonstration, where teneyes showed it working on a DS2000? (Post capture, not real-time.)
This Feature is only in latest FW 00.03.00.00 , I think Rigol is smirking at me
Here I am checking the recording & decoding of 2 Channels RS232
230byte bursts at 10sec on Ch1, Ch2 continuous
Note: The decoding of a new frame in playback takes about 2 seconds at this setup
A High Speed Test of RS232 Data Recording & decoding
I used:
...
475 Byte Block
...
Recorded 508 Frames
For a Total of 241300 Bytes recorded
Data Decoding Limit ( RS232 test)
it appears that to Decode without Errors, at least 28 Pts must be allocated for Each 'BIT' of data or else the Decode will miss a byte.
To test I used:
2ms/div
70Kpts/display
89.2Kb.s all OK = 28.027 Pts/bit
89.4Kb/s Errors occuring
See Pics
In your second test at 89.4Kb/s, if you had just zoomed out a bit from the 100us/div you were at, then it would have had more bits to work with, and started "working" again. Even though the sample Pts/dataBit hadn't changed at all.
I think.
..the key point being that the same results would have been obtained if those 508 frames had gaps of seconds or minutes or hours between them, regardless of the inter-frame latencies. (Plus, you could turn on the ClockTag, and see the date/time stamp for each frame.)
That's the power of segmented captures.