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 any
one 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.