Products > Test Equipment
REVIEW - Rigol DS2072 - First Impressions of the DS2000 series from Rigol
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:
--- Quote from: Teneyes on May 04, 2014, 07:55:03 pm ---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.
--- End quote ---
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:
--- Quote from: Electro Fan on May 05, 2014, 03:32:30 am ---
--- Quote from: Teneyes on May 04, 2014, 06:02:59 am --- 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:
--- End quote ---
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
--- End quote ---
@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:
--- Quote from: Teneyes on May 06, 2014, 04:27:27 pm ---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.?
--- End quote ---
First off, I'd like to congratulate you for taking things step by step, down to the bottom. It's been enjoyable to watch. :clap: 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.
--- Quote ---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
--- End quote ---
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.
--- Quote ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version