Author Topic: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...  (Read 182583 times)

0 Members and 1 Guest are viewing this topic.

Offline Gallymimus

  • Regular Contributor
  • *
  • Posts: 178
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #125 on: April 04, 2014, 06:08:28 pm »
Sadly I'd have to agree after a unsatisfying warranty repair experience.  Scope was less than 2 months old, they had it for repair for 1 month! They sent it back yesterday with one of the stickers on the back missing and the warranty void sticker "voided".  Adhesive is still showing on the removed stickers.  It looks like second hand junk now which really sucks.  I'm surprised they didn't replace the labels.  Thank god I had other scopes and I wasn't relying on this one.  An entire month without the primary scope probably would put us out of business!

Well, that's a pretty damning experience!  Did they at least fix the rail-to-rail noise issue, and other problems you were having?


>  It looks like second hand junk now which really sucks.

That's totally unacceptable for a newly purchased, 2-month old DS4104.   :wtf:  I'd be furious.   :box:

Have you contacted Chris Armstrong at all?  He's the head honco (General Manager) at Rigol US, and I'd think he'd want to know about the QoS his techs are providing (or lack thereof).  His email is: carmstrong@rigol.com, just in case you don't already have it.


No I haven't contacted Chris, though he was copied on one of the emails during the delayed repair.  I'll give the engineers a chance to respond and then I'll give Chris a shout.

It certainly is a bummer because I've gotten several customers switched over to buying 3 or 4 pieces of Rigol test equipment every month now and I am starting to wonder if that was a good idea.
 

Offline Sailor

  • Regular Contributor
  • *
  • Posts: 170
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #126 on: April 05, 2014, 02:02:47 am »

I've decided that there are too many things about the Rigol MSO4000 that I don't like, so it will be going back to the distributor next week. Instead, I bit the bullet last night and bought this Agilent MSO7054B

http://www.ebay.com/itm/Agilent-MSO7054B-Mixed-Signal-Oscilloscope-4-analog-plus-16-digital-channels/121297000471?_trksid=p2045573.c100033.m2042&_trkparms=aid%3D111000%26algo%3DREC.RVI%26ao%3D1%26asc%3D21021%26meid%3D5800756591393017463%26pid%3D100033%26prg%3D9336%26rk%3D3%26rkt%3D4%26sd%3D331161906210

I probably can't remember all the little things that annoyed me about the Rigol, but some of the main points were:

1. The way the cursors work - measurements tied to both being on-screen at the same time; not being always-displayed in the upper screen during zoom; the way that the cursor sometimes moves slightly (relative to the waveform) during zoom-in/zoom-out operations, even though you haven't touched the multi-function knob; etc etc.
2. The way RS232 decoding works - or not, at high baud rates, and consequently what this says about their algorithm; the slow panning; the way that the decode isn't cleared from the screen when you arm for another single-shot (a bit trivial I know, but it irritates me); the way that it doesn't work in segmentation; and more...
3. The slow function of the GUI in general.
4. The lack of Mark/Search functions, which should be a no-brainer when you have such incredibly deep memory capability.
5. The sometimes erratic operation of the MF knob (probably firmware, but who knows...)

and, as I said above, a bunch of other things that I don't remember at the moment.

Many of the points are related to the work that I do, and the way that I do it. A personal thing, but that's the way it is, and I figure that I would wind up chucking the scope against a brick wall if I had to use it continually.

All of which is a pity, because I reckon the general look and feel, panel layout, and the GUI design are *really* good, but I have this gut feeling that I wouldn't be able to always trust the scope, and that I wouldn't be able to trust Rigol to correct some of the things within an appropriate time-frame. With the older (analogue) Tektronix scopes, and now their MSO4034 I have never wondered if the scope is lying to me or not, so I don't waste time looking for things that aren't there, and so on.

These comments will be going to the local rep, who I've known for 30 years or more. He will probably be disappointed, but I think it needs to be said. If others have a pet peeve about the 4000 series that bothers them, please tell me and I'll include it. If they hear the same things often enough from a broad base of users, it may filter through (case in point - when my question/criticism about measurements involving off-screen cursor(s)  was put to Rigol, the reply was instantaneous and to the point - no, it's not possible, the capability doesn't fit in with the way the cursors are implemented, and there won't be any change. I reckon they had been asked that question more than once or twice already ;)).

On the other hand, if anyone thinks that I am being unreasonable, then also tell me.
 

Offline Gallymimus

  • Regular Contributor
  • *
  • Posts: 178
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #127 on: April 05, 2014, 03:51:58 am »
You are spot on. The agilent 7000 series is awesome and I've gotten a lot of good use from them. Also not perfect for serial decode and analysis but a very nice system overall. I'd still probably use a saleae over buying the decodes on the stipend based on experience using both.
 

Offline Sailor

  • Regular Contributor
  • *
  • Posts: 170
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #128 on: April 05, 2014, 04:51:36 am »

Now that I'm moving to the Agilent side of things ... I see mention of PC S/W such as Vector Signal Analysis,  and Matlab GUIs and/or scripts ... Has any of that made it out into the wild (cough), or is it still held fairly close?
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #129 on: April 05, 2014, 05:28:44 am »

I've decided that there are too many things about the Rigol MSO4000 that I don't like, so it will be going back to the distributor next week. Instead, I bit the bullet last night and bought this Agilent MSO7054B...

A beautiful piece of test equipment, for those with deep enough pockets to afford one.  :)  I suspect you'll really enjoy using it.  (All I have in my pockets is lint  :-DD )

Quote
I probably can't remember all the little things that annoyed me about the Rigol, but some of the main points were:

2. The way ... decoding ... doesn't work in segmentation

That's such a ridiculous limitation, I'd almost stop right there!  And when I asked Rigol (China) about this, they claimed it worked OK decoding segmented Frames.  I'm assuming they didn't understand the question I was asking... but I was pretty explicit.  Maybe I should ask again, because this is something they shouldn't be short-changing.

Quote
4. The lack of Mark/Search functions, which should be a no-brainer when you have such incredibly deep memory capability.

Agreed!  Having huge acquisition capacity is great.  And Rigol comes with some of the deepest available, anywhere near their price ranges.  But providing no way to find specific things in it is just silly.  It's not even a hardware thing.  We're talking about post-acquisition processing, a Search and Tag capability, using the existing Trigger conditions.  Really just another subroutine, like the post-analysis it does provide (only on segments!) to find frames that deviate from a Template, or fail to fit a Mask.  Same deal, just scan the existing buffer for Trigger-selected matches, tag those spots, and let the operator jump back and forth between them.

Not exactly rocket-science, but its absence really negatively impacts the value of that deep memory.
 

Online H.O

  • Frequent Contributor
  • **
  • Posts: 807
  • Country: se
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #130 on: April 05, 2014, 07:26:32 am »
Mark,
Are you saying that you've asked Rigol directly about using the decoders on recorded frames and they said it was, or should be, working?

I certainly can't make it work. As soon as the record feature is enabled the decoder locks up completely displaying the same data on the screen even though the actual trach changes. Recording frames without the decoder turned on and THEN turning on the deocder while "browsing" the frames is also a no-go.

My contact couldn't (or atleast didn't) even say if it was supposed to work.
 

Offline Sailor

  • Regular Contributor
  • *
  • Posts: 170
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #131 on: April 05, 2014, 07:34:44 am »
  I suspect you'll really enjoy using it.

I sure hope so. One of the things that attracted me (there were many) was the 'Sequence' trigger type. I can only go by the User Manual at the moment, but it seems that you define a set of conditions (i.e. a trigger) that starts the ball rolling, followed by another set of conditions which then must be met in order to start the acquisition. And you can define a 'Reset' set of conditions that take you back to the beginning. And those conditions are drawn from all analogue and digital channels, the external trigger input, and maybe the Line trigger and a Timeout value. If that all works the way that I hope it does, it will go a long way toward removing my concerns over the 8MB memory limit, which is less than I am used to with the Tek MSO4034.

It's just over a week since I asked the distributor to check with China about the likelihood of a Mark/Search function. I haven't heard anything.
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #132 on: April 05, 2014, 07:38:51 am »
That's such a ridiculous limitation, I'd almost stop right there!  And when I asked Rigol (China) about this, they claimed it worked OK decoding segmented Frames.  I'm assuming they didn't understand the question I was asking... but I was pretty explicit.  Maybe I should ask again, because this is something they shouldn't be short-changing.
I am not sure this is applicatable as this test was done on a DS2000 , where decoding at 115.2Kb/s using  scope at 20ms/div and 56Mpts, and recorded 2 frames.
 I show 1st & 2nd frame,  I am not sure how one would set up triggering  to capture frames in segments?
maybe trigger on an Hex Byte that only occurs at the point of interest  :-//

Yes the DSO is slow, It took about 1.5s to display just the trace when move to the second Frame and about 6 seconds to display the decoded Hex of that 2nd Frame
I show more on the DS2000 forum
« Last Edit: April 05, 2014, 08:08:10 am by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #133 on: April 05, 2014, 08:36:20 am »
Mark,
Are you saying that you've asked Rigol directly about using the decoders on recorded frames and they said it was, or should be, working?

Yes.

Quote
I certainly can't make it work.

That's what I've heard from several others as well.  Which is why I contacted Rigol.

Quote
As soon as the record feature is enabled the decoder locks up completely displaying the same data on the screen even though the actual trach changes.

I'm not as concerned about that.  It may simply be too slow to keep up.

Quote
Recording frames without the decoder turned on and THEN turning on the decoder while "browsing" the frames is also a no-go.

...but this I would definitely expect to work.
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #134 on: April 05, 2014, 08:45:01 am »
I am not sure this is applicatable as this test was done on a DS2000 , where decoding at 115.2Kb/s using  scope at 20ms/div and 56Mpts, and recorded 2 frames.
 I show 1st & 2nd frame,

Very, very interesting!  Thanks, teneyes.  That sure seems to show that it's possible.  Perhaps there's some trick to the process, that is non-obvious and others have missed?

Quote
I am not sure how one would set up triggering  to capture frames in segments?
maybe trigger on an Hex Byte that only occurs at the point of interest  :-//

I can't provide details, since I don't have one here, but in general, depending on what the protocol was, you'd set up to trigger on SOF (start of frame), or a specific field value match (address, for example).

Quote
Yes the DSO is slow, It took about 1.5s to display just the trace when move to the second Frame and about 6 seconds to display the decoded Hex of that 2nd Frame

I don't mind the 'Slow', as much as the 'Doesn't Work At All'.  :)  But those times do seem much slower than I've normally seen reported, even for the Rigols.  Perhaps there's something else going on, but it sure shouldn't take 6 seconds for it to process 700 bytes of data from the screen (the only place it gets the data to decode a protocol), and display the string.

Quote
I show more on the DS2000 forum

I'll go look there as well. 
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #135 on: April 05, 2014, 08:51:58 am »
I am not sure this is applicatable as this test was done on a DS2000 , where decoding at 115.2Kb/s using  scope at 20ms/div and 56Mpts, and recorded 2 frames.
 I show 1st & 2nd frame...

Yes the DSO is slow, It took about 1.5s to display just the trace when move to the second Frame and about 6 seconds to display the decoded Hex of that 2nd Frame

OK.  I just took a closer look, and it seems like you may have captured just two very large frames?  And are zooming in in on a small slice in each, to see a reasonable number of decoded bytes on screen?  I.e., you could then scroll back and forth within each of those frames, and see a LOT more data.

If that is the case, then that explains why it's taking so long.  Each Frame you're stepping to (if you only set it for 2), is pulling 28MB of data from one buffer into another.  Then interpreting and displaying it.
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #136 on: April 05, 2014, 09:20:10 am »
Perhaps there's something else going on, but it sure shouldn't take 6 seconds for it to process 700 bytes of data from the screen (the only place it gets the data to decode a protocol), and display the string.
I figure   3200 Bytes;
            analyzed from 32000 Bits:
            which are determined from 56,000,000 Pts
            interpolated from  56,000,000 samples,
            over the 280ms of the display,
            and processed in ZOOM mode. 
            ( in SOftware)
Note:  if Not in Zoom mode the decoding from Frame to Frame is lees than  a Second
« Last Edit: April 05, 2014, 02:30:22 pm by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #137 on: April 05, 2014, 10:54:17 am »
Perhaps there's something else going on, but it sure shouldn't take 6 seconds for it to process 700 bytes of data from the screen (the only place it gets the data to decode a protocol), and display the string.
I figure   3200 Bytes;
            analyzes from 32000 Bits:
            which are determined from 56,000,000 Pts
            interpolated from  560,000,000 samples,
            over the 280ms of the display,
            and processed in ZOOM mode. 
            ( in SOftware)

I'm not so sure about all those numbers (I'm way past my bedtime), but if THAT's all you're talking about, then gee, why isn't it instantaneous?   :-DD

Quote
Note:  if Not in Zoom mode the decoding from Frame to Frame is lees than  a Second

Sounds good to me, and more like what I'd expect.

I think what would be helpful would be to set up a meaningful test (where each packet isn't so enormous, and you don't have to zoom in so far to see the bytes).  I don't know what you have available to you, but it looks like you have at least a UART output at 115kBaud.  Most such comms are in packet-type bursts, of from 3-30 bytes, so set up your transmitter to send various strings of about 20 bytes, with maybe 1 or 2 ms gaps between them.

Then set up the scope for RS232 Triggering, on Start bit.  And set a sample rate that will give you several samples for each 8.7 us bit-cell.  (1 MSa/s should be more than adequate for 115k serial.)  Then configure the RecordMode to grab a large number of frames, such that the duration of each will contain at least 200-bits x your samples/bit.  You might also want to set the RecordMode gap to something ~500 us.

What you should wind up capturing is a lot of records (frames, packets).  And you should then be able to step through them, and zoom in enough to comfortably see about 7 bytes at a time (as you've already demonstrated).  And then scroll through the bytes within that packet.  And step to the next/previous packet.  See how effectively the Rigol handles that.

That's the kind of real-world scenario it's likely to be used in.
« Last Edit: April 05, 2014, 10:58:19 am by Mark_O »
 

Online H.O

  • Frequent Contributor
  • **
  • Posts: 807
  • Country: se
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #138 on: April 05, 2014, 11:57:05 am »
Here are the details on the test I did, and just re-did just to verify I wasn't goofing it up:

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.

With 14 divisions each 200us "long" we've got 2.8ms worth of data on the screen which matches 14kpts/5Msps. In theory we should be able to get 357 waveform updates per second minus some for the screen processing etc. I connected a frequency counter to the TrigOut connector of the DS4k to measure this.

The first test is to shoot frames into the DS4k without having the decoder enabled. I decided to try with 5ms "silence" between each 6byte packet to see what happend. The frequency counter says 165 waveform updates per second which is exactly the number of packets sent per second - no issues with that what so ever.

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.

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.

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.

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.

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.

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.

EDIT: This is with Software version 00.02.01 as reported by the instrument.
EDIT2: 14kpts/56Msps corrected to 14kpts/5Msps
« Last Edit: April 06, 2014, 08:18:53 am by H.O »
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #139 on: April 06, 2014, 12:49:46 am »
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.

Quote
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.

Quote
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"?

Quote
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.

Quote
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.

Quote
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.

Quote
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.

Quote
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.   :wtf:  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.

Quote
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).
 

Offline Sailor

  • Regular Contributor
  • *
  • Posts: 170
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #140 on: April 06, 2014, 03:42:42 am »
Now, if anyone can tell me what I'm doing wrong here then I'll be forever thankful ...

Ditto. After Teneyes post I thought that there must be some obscure setting, or sequence in doing things that I hadn't tried, so I re-visited it. But no, it is just plain stuck with the last-frame decode and nothing will change it. There are other weird things also, such as the decode data display occupying more of the horizontal space on the screen than the actual signal trace does. This isn't always the case, but it's a state that you can get into when adjusting the trigger delay etc. They pan left/right in unison, but the decode starts before the signal trace.

I'm pretty much fed up with this aspect of it.

Changing to something else about decodes, but not involving the RECORD side of things:

In real-world situations your captured data may well start in the middle of a character, so the decode will (may) screw up (fair enough), but if the character stream has essentially no gap between the end of a stop bit and the next start bit, and if the bit arrangement in successive characters is 'just right', the decode stream may not flag any errors, yet be displaying totally wrong information. Such a condition does not reflect any discredit on the scope, but there should be an option in the decode menu that allows the user (with a priori knowlege of the expected data) to specify (e.g. with a cursor) exactly where the decode operation should start. Implicit in setting that cursor value would be a 're-run' of the decode operation.

I think that would be a very useful capability.
 

Offline Gallymimus

  • Regular Contributor
  • *
  • Posts: 178
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #141 on: April 06, 2014, 05:05:50 am »



... but there should be an option in the decode menu that allows the user (with a priori knowlege of the expected data) to specify (e.g. with a cursor) exactly where the decode operation should start. Implicit in setting that cursor value would be a 're-run' of the decode operation.

I think that would be a very useful capability.

I think you are asking for a lot here.  I've never seen a serial decoder that does this not Saleae, not Lecroy, not Agilent.

All the hardware decoders I have used (Agilent, Tek, and now Rigol) really pretty much suck and don't have functions that you often say "well this is obvious and easy why doesn't it do this"
 

Offline Sailor

  • Regular Contributor
  • *
  • Posts: 170
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #142 on: April 06, 2014, 05:43:00 am »

Ahhh... maybe I should have been a bit more explicit. My thinking related to the decode of single-shot data in memory (almost all of my work is done in single-shot mode). Whether or not an instrument has hardware-decode capability, non-realtime decode of static data in memory is a snap.
 

Online H.O

  • Frequent Contributor
  • **
  • Posts: 807
  • Country: se
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #143 on: April 06, 2014, 08:42:21 am »
Hi,
Quote
??  I think you may have meant, "14kpts/5Msps"?
Yes of course, it's been corrected.

Quote
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.
Correct but the lack of performance has nothing to do with the display buffer, intensity grading and what not because it's perfectly capable of doing that at 165 frames per second when the decoders are turned OFF. Obviously the screen isn't updated 165 times per second but it sure is updated faster then 4Hz.

Quote
I don't think you did anything wrong.
Thanks, I feel that it has kind of been the problem with all the discussions on the issues with the protocol decoders. Almost everyone who has said they are having issues with them have been told they must be doing it wrong.

Quote
Thanks for taking the time to fully test this out, rather than just complaining "it doesn't work...
Not a problem, and this is the same test I've done before when I was complaining "it doesn't work" and I have reported it to Rigol. I've included their response earlier in the thread. One thing that I did differently this time thru was to use the RS232 trigger while I used normal falling edge trigger last time. It doesn't seem to make any difference what so ever in this particular setup.

If you do contact Rigol again please do keep us updated!

Thanks!
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #144 on: April 06, 2014, 08:43:45 am »
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.
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./size]
@H.O.
While trying to recreate your error, I found the trigger seem to have a jitter , and to investigate I did a simple test and found jitter with bursts of pulses,see Pix
I think your problem is related to this quirk, bug I found on my DS2000.

Check it out on the DS2000 Blog Here

"I decided to try with 5ms "silence" between each 6byte packet to see what happend. "
@H.O.  is it possible to try with a longer Silence period between bursts
« Last Edit: April 06, 2014, 09:08:27 am by Teneyes »
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Online H.O

  • Frequent Contributor
  • **
  • Posts: 807
  • Country: se
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #145 on: April 06, 2014, 09:21:34 am »
Hi,
I'm not sure I'm following....
How do you mean the issues with the decoder not working properly is related to trigger jitter? Thru out my tests the triggering has been rock solid.

All tests with the record mode described earlier was done with 250ms silence between packets.

I'd be happy to do more tests here but I need to understand the purpose and what I'm looking for, right now I don't quite understand what you mean...
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #146 on: April 06, 2014, 09:25:22 am »

"I decided to try with 5ms "silence" between each 6byte packet to see what happend. "

@H.O.  is it possible to try with a longer Silence period between bursts

He's already got a configuration with only 1.6 ms of databurst (60 bits), inside a 2.8 ms sample window, followed by ~250 ms dead times.  That's already pretty lightweight.

Are you suspecting he's overdriving it?   :-//

Did the jitter you encountered at specific burst delays result in your being unable to decode frames as well?  You jumped into a discussion of another issue, without saying whether or not your DS2000 worked with the same config H.O had used.
 

Offline Teneyes

  • Frequent Contributor
  • **
  • Posts: 498
  • Country: ca
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #147 on: April 06, 2014, 09:38:10 am »
Did the jitter you encountered at specific burst delays result in your being unable to decode frames as well?  You jumped into a discussion of another issue, without saying whether or not your DS2000 worked with the same config H.O had used.
I was testing with the original 5ms quite between 6 bytes of data ,and  all was OK at 500us ,with decoding , but at 1ms/div , all jitter happened.
I stopped decoding,
I change to less bytes
I varied the silence period and found that quirk.
I was wondering if it occurs on the DS4000 aLso
Now I will try the long decoding test with longer silence period
IiIiIiIiIi  --  curiosity killed the cat but, satisfaction brought it back
 

Offline Mark_O

  • Frequent Contributor
  • **
  • Posts: 939
  • Country: us
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #148 on: April 06, 2014, 09:52:44 am »
H.O, I was re-reading your description, and had another thought.  I bolded a few things that jumped out at me.

Here are the details on the test I did, and just re-did just to verify I wasn't goofing it up:

...

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.

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.

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.

I'm wondering if the first part is a real bug (locking up the Decoder with a real-time data stream), and it just stayed frozen from that point on?  I.e., if you hadn't run the first test (and confused it), and the Decoder hadn't frozen first, would your second test then have succeeded?

I'm not suggesting in any way it would [EDIT: well, yeah, I am suggesting it might :) ], but if it were me, that's something I'd give a try before giving up.
« Last Edit: April 06, 2014, 09:58:58 am by Mark_O »
 

Online H.O

  • Frequent Contributor
  • **
  • Posts: 807
  • Country: se
Re: Rigol MSO4000 and DS4000. Tests, bugs, firmware, questions, etc...
« Reply #149 on: April 06, 2014, 10:11:03 am »
Teneyes,
I don't think it's a quirk. I think what's happening in your case is that at 1ms/div you're going to capture more than a single packet for each trigger event so "the next" trigger event will happen "in the middle" of the next a packet. You should be able to use trigger hold off to stabilise it.

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.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf