Here are the details on the test I did, and just re-did just to verify I wasn't goofing it up:
Thanks for performing the tests, and the meticulous description of your process.
Packets of 6 bytes were sent at a baudrate of 38400, only the last byte in the packet changed. "Test n" where n incremented from A to Z and then started over
* Trigger set to RS232, invert, start, 38400 baud, normal sweep (of course)
* I locked the memory depth to 14kpts which is the lowest possible setting.
* I set the timebase to 200us/div in order to be able to fit my "long" 6byte packet on the screen.
* This resulted in a sample rate of 5Msps.
This is a very reasonable and realistic "light-weight" protocol test.
With 14 divisions each 200us "long" we've got 2.8ms worth of data on the screen which matches 14kpts/56Msps.
?? I think you may have meant, "14kpts/
5Msps"?
Now, turning on the decoder. The waveform update rate is still quite OK but it's not very stable. The frequency counter is jumping between ~130 and 165Hz but the decoder on the screen is nowhere NEAR that speed - obviously.
Nothing really surprising there. Your next step was very good though.
So where is the lower limit then, with these settings. With the 250ms between packets it's almost able to decode and present each packet on the sceren. I've only seen it "skip" once in a while so I'd say I'm just on the edge there. Yes, the frequency counter reports 4 waveform updates per second - as expected. Obviously there's no need for the decoder to update the displayed data faster then you can read but really, 4 times per second IS slow IMO.
I agree that it's slow. That's 250 ms, where only the first 3 ms is needed to acquire 14k samples. Then it has to process those 14k, to decimate down to 700 screen points. Updating the screen buffer takes a bit longer, since it has to merge into a variable intensity buffer first. Lastly, it takes the 700 points, and software decodes into a byte stream, then updates the display with THAT ancillary information. Normally when folks try this, they do it with WAY too much sample data. But you used 14k, which was just right. And 250 ms/update seems too long to me as well. Especially on a DS4000. I might be more forgiving on a DS1000Z.
So then I hit the Record button, what happends is that the scope starts recording frames at a rate of 4 per second obviously - as expected. The decoder on the other hand completely freezes and displays the decoded data of the last packet captured before the Record button was pressed. That's not cool if you ask me.
I concur with your "not cool" assessment, however you already knew you were right on the threshold of what it could handle and process at 4fps, BEFORE adding the RecordMode overhead. Freezing at that point isn't overly surprising (to me), though obviously that's not desirable.
Stopping the recording and then "browsing" thru the recorded frames with the jog wheel does NOT update the decoded data displayed on the screen. It's completely frozen with whatever data was there when the record button was pressed.
Not good. Though I might see how having both enabled simultaneously might not be "the way to do it". Doing so certainly brought you no benefits.
Then lets try and record frames without having the decoder enabled during recording, stopping the recording function and THEN enable the decoder. Guess what, it STILL displays that very same data from when the Record button was pressed with the decoder on the screen. And no, it does not update when browsing thru the recorded frames.
OK,
that's bad.
I would definitely expect that to work, no question. It sounds broken to me. Though from Teneyes report, it sounds like it DOES work on his DS2000.
Now, if anyone can tell me what I'm doing wrong here then I'll be forever thankful because I think I've given the scope the best possible circumstances to do it's job and I don't think it does it very good at all. This is with Software version 00.02.01 as reported by the instrument.
I don't think you did anything wrong. (Well, your last comment should have been "
very well", not "
very good".
) Your last test should have worked properly, as far as I can see. I'll report this to Rigol, specifically mentioning the DS4000 this time. My previous assumption was if it worked on one, it would likely work on all. But if it worked on a lower model, it
must certainly work on the
higher ones. That's why I think I specifically inquired about the DS1000Z, back in ? February maybe?
Thanks for taking the time to fully test this out, rather than just complaining "
it doesn't work".
In my opinion, this is a "big deal". Why? Because Rigol promotes their scopes as having advanced features like protocol decoding. It looks good on a Feature List, but if the d@mn thing doesn't work, it's no good to anyone (other than the marketing guys).