Mark,
I just tried it. Cold booted the scope, recorded a couple of frames and then enabled the decoder. It pops up with decoded data from I don't know where/when but it still does not update when browsing thru the frames.
Sigh. I had my fingers crossed. Glad you eliminated that possibility though.
If you do contact Rigol again please do keep us updated!
I already had started writing something up, and came up with that (bogus) hypothesis when describing the issue. Now that's been shot down, I'll finish my missive and fire it off.
I cannot change the data in bytes so I changed the number of bytes (from 6 to 4 bytes)
I also Confirmed H.O.'s Bug report
I need 2 post
Here are the correct Frames (not recording)
Note I used Data trigger (xEF)
Note I used fine Timebase control to spread displayed bytes out
I also Confirmed H.O.'s Bug report
in this .GIF you can see recorded frames display the change in the Data waveforms
BUT the Decode data does NOT update
On H.O.'s Bug report
these displays show that the DS2000 can decode data bursts, and I show in Zoom Mode
So I hypothesis that the record function in the FW does not call the Decode function between segmented framesI will be reporting this to Rigol NA as a DS2000 owner
Since I've got a 4k I obviously can't say for sure regarding the 2k (I suspect the manual will tell you though). On the 4k it's in te exact same place as it always is for any trigger.....
Trigger menu -> Settings.
Since I've got a 4k I obviously can't say for sure regarding the 2k (I suspect the manual will tell you though). On the 4k it's in te exact same place as it always is for any trigger..... Trigger menu -> Settings.
Yes Edge trigger has Trigger Holdoff, (under settings)
But , Does the DS4000 have trigger Holdoff when one is using RS232 Trigger???
What do you think about this?
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.
Hi Mark
It is not on your Bug list (post 3) and at first I was thinking it was important. but Now as I was testing the best way to monitor a serial data stream is with a long buffer (using best Mem depth), then analyze by using the zoom feature , where the decoding does work. and to record long frames, then zoom and scan the Data. I guess the DSO is only a preliminary device for Serial Data debugging. I am not sure when data could be missed
But , Does the DS4000 have trigger Holdoff when one is using RS232 Trigger???
Yes it has, as you can see from the screenshot in my previous reply. I haven't tested if it actually WORKS but it's there.
I don't know why keep mixing responses from other threads but using a single capture into a deep memory buffer is not at all the same thing, or as usable IMO, as being able to use the segmentet memory. What if there's 30 seconds between packets?
...at first I was thinking it was important. but Now as I was testing the best way to monitor a serial data stream is with a long buffer (using best Mem depth), then analyze by using the zoom feature , where the decoding does work. and to record long frames, then zoom and scan the Data.
I'm afraid you've missed the whole point of Segmented acquistions (RecordMode) in the first place. In almost all communications protocols, there are not only gaps between requests & responses, but much longer gaps of 'dead time' between those pairs. By recording just one Frame worth of data at each trigger, you can easily extend the time you can monitor by 10x, 100x, or even 1000x. Using the shortest frames, that means up to 200k (!) msgs could be captured. And Rigol
brags about that 200k frame capability!
Let's take 1Mbit CAN for example. I'd need to oversample that by at least 10x, so 10MSa/s. Even with the superdeep 140 Mpts of the DS4000, that's only 14 seconds. Which is <10k msgs at 10% bus loading (10x/20x worse). With lighter traffic, it's even worse yet. But with segmented captures, 100k msgs could be captured with ExtendedIDs (and 200k for StandardIDs). And if I were using a more selective trigger (say specific address, not grabbing
every message), I could filter out a lot of "uninteresting" msgs, and extend that time coverage even further. But not with the method you're espousing.
I can tell you if I dropped the kind of money a DS4000 costs, I would d@mn sure expect this very useful function to work. Great in theory (and advertising marketing), but
doesn't work in practice is a huge
.
Oops, I shoulda read ahead.
...using a single capture into a deep memory buffer is not at all the same thing, or as usable IMO, as being able to use the segmented memory.
What if there's 30 seconds between packets?
Yeah! Exactly. What he said!
I don't know why keep mixing responses from other threads...
I'm with H.O on this. It's confusing. I see a bunch of your screen snaps, but without the Play=n frame counter, we're not talking about the same thing.
This is complicated enough, trying to evaluate one issue at a time. For me anyway, but perhaps I'm slow.
I'm happy to see you testing and posting. (You're the only one I'm aware of who has managed to show segmented frames actually being decoded, though on a DS2000.) But could we focus on one thing at a time?
Please Note the decoding of recorded frames I show is available for the DS2000 only in the latest FW 00.03.00.00
The recording shown here are bursts of 70 bytes every 3 seconds
Does the DS4000 have this feature? if Not it should be in the next FW release
Hi Teneyes,
No, the DS4k does not decode data when "playing back" recorded frames - that feature not working has kind of been the key point of the discussions over the last several days.
Thank you very much(!) for confirming that it DOES now seem to work on the DS2k after upgrading to 00.03.00 - I sincerely hope it's just a matter of time untill Rigol releases "the same" firmware for the DS4k.
...at first I was thinking it was important. but Now as I was testing the best way to monitor a serial data stream is with a long buffer (using best Mem depth), then analyze by using the zoom feature , where the decoding does work. and to record long frames, then zoom and scan the Data.
In almost all communications protocols, there are not only gaps between requests & responses, but much longer gaps of 'dead time' between those pairs. By recording just one Frame worth of data at each trigger, you can easily extend the time you can monitor by 10x, 100x, or even 1000x. Using the shortest frames, that means up to 200k (!) msgs could be captured. And Rigol brags about that 200k frame capability!
Using my DS2000 (56Mpts) here is a test of capturing & decoding 508 frames X 465 byte blocks = 236,220 Bytes,
That's good for me.
Using my DS2000 (56Mpts) here is a test of capturing & decoding 508 frames X 465 byte blocks = 236,220 Bytes,
That's good for me.
Thanks, Teneyes! Yes, you can capture up to 65,000 frames on the DS2000 (each probably around 700B, of course). Fewer as you increase the frame size. And yes, that capability, coupled with post acquisition decoding, can be very useful.
Thanks for cluing us in on the DS2000/FW3.0 dependency for this functionality. I wasn't aware that many had even bothered trying it yet (or that you were one of them), since there were some questions initially about its legitimacy. And those that had weren't noticing any significant improvements. Naturally, Rigol isn't about to make a list of things they fixed. That would require admitting that a capability that should have worked from day one (and they've been claiming did work), just showed up 2(?) years later. (Though the DS4000 folks are still waiting, even longer.
)
I wasn't aware that many had even bothered trying it yet (or that you were one of them), since there were some questions initially about its legitimacy. And those that had weren't noticing any significant improvements. Naturally, Rigol isn't about to make a list of things they fixed. That would require admitting that a capability that should have worked from day one (and they've been claiming did work), just showed up 2(?) years later. (Though the DS4000 folks are still waiting, even longer. )
I am not sure I have the latest 'Offcial' version.
I know this FW has bugs that will freeze the DSO and I am disappointed that it does
NOT fix the bugs we have reported to Rigol. I hope the DS4000 owner's get a better release. It was by accident that it was loaded, when I tried testing the Record & Decode function. The FW is a much larger file, going from 8MB to 10MB, so it should add something. (
reports all Hacked DSO's IP addy if connected to Internet, STUXNET2)
I am not sure I have the latest 'Offcial' version.
I know this FW has bugs that will freeze the DSO...
...and I am disappointed that it does fix the bugs we have reported to Rigol.
I think you meant to say, "
doesn't".
The FW is a much larger file, going from 8MB to 10MB, so it should add something.
Yes. As I mentioned somewhere else here in the Forum, the new FW adds a lot of code to support the LA functionality in the new MSO2000 models, along with SCPI support for same.
I think I found another bug in the DS4014 firmware. I skimmed this thread and didn't see it listed.
When using the Math function, with an expression, the state is not saved when turning off the scope. After powering up the scope you must go back to the Math menu, reapply the expression, and reset the volts/div scale.
I just emailed Rigol about it, and recorded this clip to show them:
Can anyone else confirm this bug with their scope?
-Farrell
To DS4000 owners:
I'm working on a new version of my Rigol Ultravision Utilities to handle all 4 channels of the DS4000 (as well as DS1000Zs). Since I don't own either DSO, I'd appreciate any owners willing to be alpha/beta testers. The link for the current alpha (as well as some explanatory info)
is here.
To DS4000 owners:
I'm working on a new version of my Rigol Ultravision Utilities to handle all 4 channels of the DS4000 (as well as DS1000Zs). Since I don't own either DSO, I'd appreciate any owners willing to be alpha/beta testers. The link for the current alpha (as well as some explanatory info) is here.
awesome will check it out on the ds4000
Hi,
question concerning the HORIZONTAL knob of the DS4000 series:
when I turn it fast the timebase sometimes jumps back or foward.
When turning the knob slower there's absolute no problem.
Would be interested in your experience. Either the routine for the rotary knob is not implemented well or it seems to be
broken. Usually a gray code is used for decoding such kind of knobs.
Is there a bug in the DS4000 series?
Rgds
Gunb
Hi,
question concerning the HORIZONTAL knob of the DS4000 series:
when I turn it fast the timebase sometimes jumps back or foward.
When turning the knob slower there's absolute no problem.
Would be interested in your experience. Either the routine for the rotary knob is not implemented well or it seems to be
broken. Usually a gray code is used for decoding such kind of knobs.
Is there a bug in the DS4000 series?
Rgds
Gunb
It's probably just quadrature rather than gray code, but it doesn't matter, the darn thing should work
I'll check mine and see if it acts that way. I bet they are not sampling the knob fast enough and it is skipping states making it look like it is going backwards.
I'll check mine and see if it acts that way. I bet they are not sampling the knob fast enough and it is skipping states making it look like it is going backwards.
... that would be nice, thank you.
Rgds
Gunb
question concerning the HORIZONTAL knob of the DS4000 series:
when I turn it fast the timebase sometimes jumps back or foward.
When turning the knob slower there's absolute no problem.
I started having the same problem with the Horizontal scale knob on my DS2000 after about 14 or 15 months of owning it. I sent it back (to the dealer) for knob replacement while I was abroad a month ago. It's fine again.