REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol

[Mark_O]

Well , Rigol knows of the SCPI and I got 3 messages from China, thanking me for my reports and stating that my info was referred to R&D then this response 2 hours later.

We will fix this in next version ,thank you .

Yeah, that's great.  Except the new version you're testing is already the "next version".  They were already made aware of this, when CAN 'support' was first added to the 2000 firmware.

Perhaps she meant the next, next version.

[AintBigAintClever]

My DS2072A-S works happily on rev. 2.x firmware, signal generator and all. Whatever's been added in 3.x, I don't think A-S support is it.

Of course they could've added more features to the A-S than are present in 2.x, I wouldn't know without digging into the firmware (which is way, waaaaaaaaay over my head).

[Sparky]

I think we know that FW 00.03.00.01.02 was a release to support the new DS2000A-S models being so much bigger FW...

My DS2072A-S works happily on rev. 2.x firmware, signal generator and all. Whatever's been added in 3.x, I don't think A-S support is it.

What has been added in v00.03 is likely support for new MSO2072A(-S) series.

[AintBigAintClever]

Aha, that would make sense then. 

Typical, no sooner do I bite the bullet and buy a new scope than a better version comes onto the horizon! Just found a price list here, MSO prices appear to be between about €200 and €350 over their equivalent DS models.

[AndersAnd]

May be this already mentioned somewhere, but I just noticed it: MSO version of DS2000A series is coming!

Maybe that's what the big v00.03 firmware update and version number jump is about?!

See http://www.rigol.com/ and select the Chinese localization.

There's also a MSO1000Z series at the Chinese site, which isn't listed at the international site yet. The links for the MSO1000Z and MSO2000A images both below both contain the upload date March 27 2014.
FOR MSO4000 it's May 3 2013.
The logic analyzers in both MSO1000Z, MSO200A and MSO4000 are 16-bit. But there's a different much wider LA-connector on MSO100Z than the one used on both MSO2000A and MSO4000:

http://www.rigol.com/prodserv/MSODS1000Z/

MSO1000Z

http://www.rigol.com/prodserv/MSODS2000A/

MSO2000A

http://www.rigol.com/prodserv/DS4000/

MSO4000

[Teneyes]

Here is a CAN Bus Message of 3 Bytes of Data (43,41,4E)
I have zoom display of each sections of the Frame for discussion.
I will show all sections in this Post then I will highlight points where I have some concerns in additional posts
The  Display are:
   ID
   Frame DATA Length
   3  Bytes of Data
   CRC
   ACK
   Between meesage Gap

[Teneyes]

Here are my comments on the Sampling position of the signal and How the DS2000 displays data.
I do not have and experience with  analog sigansl with Data decoding.

In the first display I show how adjusting the Trigger sample point shifts the Trace and Data relative to the Orange Trigger point.I shoe at 5 %, 50 % and 95% sample point
 All looks nice and Good.

In the second display I show how adjusting the Decode sample point shifts the Trace and Data relative to the Input Trace.I show 3 conditions
        Trigger at 5 %,  and Decode at  95% sample point
        Trigger at 50%  and Decode at  50% sample point
        Trigger at 95%, and Decode at    5% sample point

Here I think I would prefer that the entire Message is shifted and NOT just the Length and DATA.
Is this a BUG??
WHat to other DSO's do?
What do others think?

You will see that the Data overlaps the CRC some times.
Just be aware of the shifting , when you are trying to examine trace timing and CAN Data  bits
good feature of the Copy trigger , is the sample point is copied so Both Trigger and Decode are the same, but if you adjust the Decode , the Trigger point does not Follow.


Note this CAN messges was done with Arb Gen.,
But I am still trying to calculate the Correct CRC

[AintBigAintClever]

My DS2072A-S works happily on rev. 2.x firmware, signal generator and all. Whatever's been added in 3.x, I don't think A-S support is it.

@AintaBigCleaver
Did you try  FW 00.03.00.01.03 ?
     or Beta  FW=00.03.00.00.00 ?

Skipped the beta. No idea what was on it out-of-the-box (idiot boy forgot to check first!). Tried it on 2.x grab-the-key firmware and 00.03.00.01.03, both of which would allow feature unlocking keys but no bandwidth change keys, so it's on 2.x non-A-keys firmware for now, fully unlocked 

[Teneyes]

Here's a Test to see Frequency tolerance of the Rigol CAN bus Decoding;
The base Frequency was set to max. of 1.0Mb/s and the input message bit rate was raised until an Error and then lower until errors.
 Displays;
      1:  Good decoding  at a higher Bit rate (1.087Mb/s) just before  Errors occured
      2:  No decoding     at a higher Bit rate (1.111Mb/s) as Errors occur

      3:  Good decoding  at a lower Bit rate (0.915Mb/s) just before  Errors occured
      4:  Error decoding  at a higher Bit rate (0.909Mb/s) as Errors occur

So I would say  Tolerance is  -8.5%  to  +8.7 %  of Baud rate:
but I am not sure what the theoretical range is?
The timing could be from the the Trigger point, but with 70 bit times there might  be re-syncing at the bit change edges

[Carrington]

Does anyone know how Agilent deals with displaying CAN data??   Hydrawerk??

Hi Teneyes. 

The other day I found this video. Is that what you wanted to see?



And also I found this video (download to see):

http://www.element14.com/community/servlet/JiveServlet/downloadBody/35783-102-2-217111/T%26M-Learning%20Center-Oscilloscopes-Video-Agilent.Training_Videos_6.wmv

[Teneyes]

Obscure Bug in FW 00.03.00.01.02
Understandable, When the range for decoding is 10Kb/s to 1.00Mb/s  and there is a Fix Baud setting for 1.00Mb/s. Then the Owner would only be trying to select a "USER" baud rate of  11-999 ( all in Kb/s)
But in "USER" Trigger mode Rigol allows the Trigger to be 1.00Kb/s -  10.00Mb/s, so that copying the trigger range is bigger than the programmed Decode range.
Is there a Need for a wider CAN decoding Baud range,?

[Mark_O]

Obscure Bug in FW 00.03.00.01.02

In the Display below , See what is wrong with the Settings

Nice catch.  Kind of strange that something as simple as copying a setting from the trigger section to the decode section would be broken.

[Mark_O]

Thanks Carrington

I could not download the second link

Me neither.

The videos and  pdf file shows how a DSO decodes message and then shows the decoded data ,but does NOT show enough detail to show Stuffed Bits and the bit by bit comparison

I doubt any of them do.  You're doing the bit-wise comparison to check if the Rigol is decoding properly.  The rest assume they do decode properly, so there's no reason to check the device operation.  I.e., the purpose is to test the bus, not the test instrument.  For that purpose, no one cares which bits are stuff bits.

[Carrington]

Thanks Carrington

You're welcome.

I could not download the second link
Could this be the Video, showing how Hardware decoding helps
Agilent video

Yes, it's the same video.

It might be interesting to see a test of  the speed of Protocol decoding between Rigol vs Tek

Sure!

The videos and  pdf file shows how a DSO decodes message and then shows the decoded data ,but does NOT show enough detail to show Stuffed Bits and the bit by bit comparison

No, about that particular detail, I haven't found anything.

[Carrington]

Thanks Carrington

I could not download the second link

Me neither.

Oops! Me neither.

I don't know if this link works:
http://www.element14.com/community/docs/DOC-35783/l/debugging-can-based-designs-video--agilent

The videos and  pdf file shows how a DSO decodes message and then shows the decoded data ,but does NOT show enough detail to show Stuffed Bits and the bit by bit comparison

I doubt any of them do.  You're doing the bit-wise comparison to check if the Rigol is decoding properly.  The rest assume they do decode properly, so there's no reason to check the device operation.  I.e., the purpose is to test the bus, not the test instrument.  For that purpose, no one cares which bits are stuff bits.

No idea, but probably you're right.

[Carrington]

By the way:

Someone in the forum already has a MSO2072A?

  I'd love to watch a review.

[Carrington]

A self-criticism   

There is nothing wrong, now we know more than before.

[Electro Fan]

Here's a Test to see Frequency tolerance of the Rigol CAN bus Decoding;
The base Frequency was set to max. of 1.0Mb/s and the input message bit rate was raised until an Error and then lower until errors.
 Displays;
      1:  Good decoding  at a higher Bit rate (1.087Mb/s) just before  Errors occured
      2:  No decoding     at a higher Bit rate (1.111Mb/s) as Errors occur

      3:  Good decoding  at a lower Bit rate (0.877Mb/s) just before  Errors occured
      4:  Error decoding  at a higher Bit rate (0.862Mb/s) as Errors occur

So I would say  Tolerance is  -12%  to  +8.7 %  of Baud rate:
but I am not sure what the theoretical range is?
The timing could be from the the Tigger point, but with 70 bit times there might  be re-syncing at the bit change edges

Not sure if I'm measuring the same things you are measuring but I found on my 2072 that RS232 decodes reliably in the range of - 6% to 5%.  It was at a slow rate and just one test.  EF

[Teneyes]

Well , maybe I opened the 'CAN'
Let me start will this past discussion of how soon is the DS2000 able to decode the next 'CAN' bus message.?

Here I show you that it depends on the CRC!
If the CRC is correct the DS2000 will decode if there is a 3 Bit times of Idle
If the CRC is Not correct the DS2000 will decode if there is a 7 Bit times of Idle
Here are the Displays:
   1:  CAN message bursts with Ok  CRC has good Decoding at a Interframe space of 6 bit times
   2:  CAN message bursts with Bad CRC has good Decoding at a Interframe space of 7 bit times,  Should do better
   3:  CAN message bursts with Bad CRC Skips Decoding      at a Interframe space of 6 bit times   Should do better
   4:  CAN message bursts with Ok  CRC  has good Decoding at a Interframe space of 3 bit times
   5:  CAN message bursts with Ok  CRC  has NO Decoding   at a Interframe space of  2 bit times  Could do better

I  think this is a BUG and I have reported it to Rigol

Now , although the InterFrame spacing Spec for devices on a 'CAN' bus , is 'to leave the bus idle for 3 bit times , I see no reason for using a DSO as a diagnostic tool to decode Message faster than the devices. Yes, the DSO can scan for the End of Frame (1111111) flag , then open to decode any correct message that follows. Then the DSO should display a RED Bar showing faulty interframe space and the good message.

[Teneyes]

Next out of the 'CAN'
Here is a report of the Trigger getting disabled.

When the DS2000 is using 'CAN' trigger on Frame DATA, any adjustment of the display causes the Triggering to Stop
Here are changes that stop the Triggering:
     1. Changing the Timebase
     2. Enabling Ch 2
     3 .Moving the Trigger position or level
     4 .starting a Recording
     5. moving the vertical position
Pretty much any adjustment

A 'Force' trigger only does a Single Trigger then it stops!

Now one can restart the triggering by changing one of the trigger menu items:
ID, When, ID format, but then you must change it back to what you want
I use 'All bits'  and less important  ,
Generally a DYSFUNCTIONAL mode
Here are displays
Triggering OK
and stuck in Wait

[Teneyes]

More Worms
Here are displays highlighting  what would you call them
    Annoyances
    More room for improvement
    A Difficult to use feature
Displays
   1: setting the CAN ID
   2, View Detail
 

[Teneyes]

In my past posts here I have shown you some  'CAN' bus messages with incorrect CRC
but lately I have posted  'CAN' bus messages with correct CRC
 
To do the testing I want to create a specific message,
but I did not have any 'CAN' bus devices to test and that would show a complete message to test with,
so I created my own messages that I can vary parameters (voltages, timing, data, and errors )
And to be correct I needed to create the CRC for the complete message.
I did research and tried different software , but no program generated the correct 15 bit 'CAN' bus CRC.
 
So I went back to the basics
and manually formed the CRC for the message I used in my testing
After 4 mistakes, and slow carefull working here is my long binary division for the CAN bus CRC

I hope you are amused

[Mark_O]

I was thinking more of the occasion where a process monitoring device, one is design/building, is not stuffing the bit in or is causing errors in the CAN msg.
Any time a device is showing voltage and decoded bits it is nice to see the Bit-to-Bit Matching clearly.
For Rigiol , maybe only when a Binary display of the message is selected.

I don't disagree, but even in that case, the Rigol will show that there is an error.  (Should flag a Stuff-Error, at then end.)   But you have a good point that it won't flag where the faulty bit is located.  For that, you can just look at the stream, and see where a Stuff-bit should have been inserted, but wasn't.

Unless the CAN stream is being generated by software (certainly possible, especially at slower bit rates), I can't think of any situation you'd ever see a stuff-error that wasn't due to noise, or a glitch or something along those lines.  And the transient problem should be pretty unambiguous.  I.e., all the hardware chips I've ever seen (maybe 4 or 5) manage to 'stuff' CAN reliably.  If they don't, it's factory-recall time.

[Teneyes]

      3:  Good decoding  at a lower Bit rate (0.915Mb/s) just before  Errors occured
      4:  Error decoding  at a higher Bit rate (0.909Mb/s) as Errors occur

So I would say  Tolerance is  -8.5%  to  +8.7 %  of Baud rate:

Not sure if I'm measuring the same things you are measuring but I found on my 2072 that RS232 decodes reliably in the range of - 6% to 5%.  It was at a slow rate and just one test.  EF

@Electrofan
   I have updated my test (good CRC) and I have corrected the lower range , from 12% to 8 %
As for your RS232 testing , Did you vary the Signal input Baud rate  or the DSO user setting  Baud rate.?

[Mark_O]

Well , maybe I opened a 'CAN' of worms

Let me start will this past discussion of how soon is the DS2000 able to decode the next 'CAN' bus message.?

First off, I'd like to congratulate you for taking things step by step, down to the bottom.  It's been enjoyable to watch.     For quite some time, I wondered how the DS2000 would handle CAN decoding, and you've shown it does a pretty nice job of it.

Here I show you that it depends on the CRC!
If the CRC is correct the DS2000 will decode if there is a 3 Bit times of Idle
If the CRC is Not correct the DS2000 will decode if there is a 7 Bit times of Idle

Yes, you are correct.  And not only for the DS2000, but for hardware CAN bus controllers as well.

There are still a few things about CAN you don't know, and I really don't have time for an in-depth explanation at the moment.  But CAN is a bus, which means whenever anyone sends (asserts a dominant bit), everyone sees it (including the Sender).  And, e.g., with the ACK bit, everyone sends it, at roughly the same time (assuming they're staying in sync properly). When an error-condition occurs, such as a CRC error, everyone sees that too.  It causes an REC register (receive-error counter) to increment for everyone, and a TEC register (for the transmitter).  At that point, a bus-error condition is flagged, and you simply don't wipe it, and start instantly with the next clean frame.  It simply will never happen.

Here are the Displays:
   1:  CAN message bursts with Ok  CRC has good Decoding at a Interframe space of 6 bit times
   2:  CAN message bursts with Bad CRC has good Decoding at a Interframe space of 7 bit times,  Should do better
   3:  CAN message bursts with Bad CRC Skips Decoding      at a Interframe space of 6 bit times   Should do better
   4:  CAN message bursts with Ok  CRC  has good Decoding at a Interframe space of 3 bit times
   5:  CAN message bursts with Ok  CRC  has NO Decoding   at a Interframe space of  2 bit times  Could do better

I  think this is a BUG and I have reported it to Rigol

Now , although the InterFrame spacing Spec for devices on a 'CAN' bus , is 'to leave the bus idle for 3 bit times , I see no reason for using a DSO as a diagnostic tool to decode Message faster than the devices. Yes, the DSO can scan for the End of Frame (1111111) flag , then open to decode any correct message that follows. Then the DSO should display a RED Bar showing faulty interframe space and the good message.

I understand what you're saying... that you think the Rigol should be able to detect and decode protocol conditions and state-transitions, even if they would never actually occur on a real CAN bus.  In theory, that may be interesting.  But in practice, I don't think it's either necessary or reasonable for a diagnostic test device to decode bus traffic that will never occur.

I'd have to dig back into the Bosch defining specs for CAN 2.0 to find all the nitty-gritty details of the state-transitions that occur after a bus-error, but I can tell you for sure that recovery is never instantaneous, and no properly operating CAN transmitter will ever start sending the next frame as soon as you'd like the Rigol to be able to decode it.

I am happy though, to see that you did narrow things down, and demonstrated that when the CRC was correct, the Rigol did NOT need any more IFS bits than what the CAN spec calls for, to decode properly.  It's also interesting to see how they dropped the ball on the Detail list.  Those findings are definitely legitimate bugs.