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 be correct.
I needed to create the CRC for the complete message also.
I did research and tried different software , but no program generated the Correct 15 bit 'CAN' bus CRC.
So I went back to basics
and manually formed the CRC for the message I used in Testing
After 4 mistakes, and slow working here is my long division for the CAN bus CRC
I hope you are amused
My hat is definitely off to you.
I've been working with numerous CAN protocols on a daily basis, for about a decade now (J1939, ISO-14229, CANOpen, ISO-15765, etc.), and I've never taken the time to do that by hand. Of course, I've always had chips available in my product designs that did that work for me. So I could afford to be 'lazy'.
In the old days, they were outboard CAN chips (Microchip, Intel, NXP), but now all the MCUs in the embedded space have one or two CAN channels built-in. Most of the work gets done in the protocol stack sitting on top of the physical transport layer.
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.
Thanks Mark_O, for the feedback ,
As for "will never occur." but I would say "
SHOULD never occur"
I can see Rigol having a test setup of a CAN Network and running tests.
Then programming the DSO to display the communication traffic. I suspect extra code was put into the program to delay the searching for Start of Next Frame in order to duplicate the Norm.
My philosophy is more to look for the odd occurrences.
( stray cat, hardware bug, geeky chick)I got eNote that Rigol Marketing is sending a report over to R&D
As for "will never occur." but I would say "SHOULD never occur"
Yes, you are correct. I'd have to agree with you on that distinction.
Has anyone had any problems with a Rigol DS1074Z(-S) scope not booting up from time to time?
I believe I am running the SP5 firmware (which it came with, not sure if there is a new version 3.0 out yet) , and from time to time the scope just sits there and doesn't boot up. No lights from the front panel light up, and the screen just says Rigol.
If I repower the scope it works fine.
It has happened with both installed and uninstalled options key (still on trial period for a few hours).
Has anyone had any problems with a Rigol DS1074Z(-S) scope not booting up from time to time?
I believe I am running the SP5 firmware (which it came with, not sure if there is a new version 3.0 out yet) , and from time to time the scope just sits there and doesn't boot up. No lights from the front panel light up, and the screen just says Rigol.
If I repower the scope it works fine.
It has happened with both installed and uninstalled options key (still on trial period for a few hours).
This does not sound right. I got a new DS1104Z this week, and it boots every time correctly. It is running firmware 02.03.SP5, and was set-up with all options, except the 500uV. Pretty nice scope in addition to a DS2000.
Very good news, Sigrok now supports the RIGOL DS2000, and runs on windows!
Is CAN decoding after the data is transfered to the PC??
Thanks, didn't even know this existed and it does support my DMM as well, good because the software that came with it is not that great.
You're welcome.
I have been following the sigrok project for some time ago, however, the previous versions were not as easy to install on Windows. And yes, it supports a wide range of hardware:
http://sigrok.org/wiki/Supported_hardware
Is CAN decoding after the data is transfered to the PC??
I suppose so.
Someone has already tried it with a DS2000?
Not the DS2000, just an example:
It has a lot of examples:
I would, but not at home right now and I don't have a good CANdidate to get the signal, I could try with RS-232 but not until later.
Analog signals (A0-A4) cannot be selected to do decoding.
Have you seen these new reviews?
Have you seen these new reviews?
Why? Most of us here have owned the DSO for months - and know much more about it than this reviewer.
Here's an Odd Occurance
Hey Len,
I'm finally back home and using the DSO again - and want to update the bug / FW list on Page 1. Can you summarize any new bugs you discovered (to save me some time) - and also, have you tested the old bugs from the list to see if any of them are fixed in v.3?
Thanks,
Mark
Well, I finally played around with the new v.3 FW and I can't say that I'm impressed.
AFAIK, the only earlier reported (main) bug they appear to have fixed is the Math Log() function - and they've made some stupid changes that don't make sense - except perhaps because they were needed for the upcoming MSO models: for example, they changed the position of some Menu selections: MemDepth and Anti-Aliasing in the ACQUIRE menu, and they've changed the font for numbers in the menus from the nice san-serif font used for the letters to some rather ugly, less-readable, squashed serif font.
They don't seem to have tackled ANY of the serious acquisition or SCPI-related bugs - thumbs down, Rigol!
Also I noticed there is a new Ethernet bug introduced in FW v.3 - any other serious bugs that people have found?
Anyway, I think it's back to v.2 for me.
Just to confirm what Teneyes already discovered (and posted) about the new DS2000 v.3 FW - this time using I2C: the DSO can now decode within segmented memory.
Although I'm not happy that Rigol hasn't tackled some of the bugs we reported over the last months (in both v.1 & v.2 FW), the ability to finally decode segmented memory means I've changed my mind and will stick with FW v.3.
Hopefully now that Rigol has finally finished (or is very close to being finished) with the expansion of the DS2000 line (i.e. MSO2000A), they might get back to getting rid of some of the leftover bugs. The good thing about expanding the line (as opposed to completely new models) is that the same DSO bugs will affect all of the owners - so a larger user base of customers who potentially might complain about the same thing.
I found another
new feature in FW v.3 - something we've been asking them for over the last year - and although it's a baby step by Rigol, at least it's a baby step in the right direction:
The External Trigger input can now (finally) be used for a
second trigger type: PULSE
This would help explain Teneyes' earlier discovery that the Ext. Trigger can now be used as a source for the counter: it seems to go hand-in-hand with adding pulse measuring capabilities.
An encouraging sign... let's hope they keep adding more triggers it can be used as a source for.
Now it would be good if Rigol would add an external trigger input on the back of the DS1074Z.
Modifying this post to say that the following steps worked well (as of today May 17, 2-14) to do the Firmware Upgrade (on a DS2072, ie, the non-A version) for FW v.3.
Rigol DS2000, DS4000, DS6000 Firmware Upgrade Procedure
Instructions originally Dated: 11.21.2012
Solution:
0. Check to see that the USB stick is recognized by inserting into the USB
input on the front panel. The instrument should indicate USB Device
Detected.
NOTE: If the device is not recognized, try another USB memory stick. We
also recommend minimizing the number of folders, files, and programs on
the stick. Drives less than 4GB in total volume are also recommended.
1. Download the proper firmware file and transfer to the root directory of a
USB memory stick. If you have downloaded the packed .rar/.zip file. Do not
forget to unpack and only copy the .GEL file to your USB stick.
2. Plug the instrument in to an uninterruptible power supply.
WARNING! Don't power cycle or disturb the instrument until the upgrade is
complete.. as the instrument can be damaged.
NOTE: USB Stick is not plugged in DS2000/DS4000/DS6000 at this time!!!
3. Press the power on button on the front panel of the instrument. All of the
buttons will light. At the same time press two or three times the Help key on
the front panel. All buttons will unlight
4. If you now can see the Rigol Logo on the screen you failed to go into update
mode. Please go back to step 3.
If the screen stays black and the Single light will illuminate (as below in the
picture) you can go ahead.
5. Now it is time to insert the USB stick into the front panel.
6. The CH1 button will flash and then go solid.
7. After 5-10 minutes, all of the buttons on the front panel will be lit. The
upgrade is complete.
8. Remove the USB drive and power cycle the instrument.
9. You can check the firmware revision by pressing
Utility > System > System info
--
A few observations:
In Step 3, as soon as the power button was pushed in I just kept quickly pressing and repressing the Help button (maybe 2-3 times very quickly), this seemed to be the best way to put the oscilloscope into the Firmware upgrade mode.
In Step 6, the CH1 button seemed to flashed for about 30 seconds or possibly somewhat longer.
Step 7 didn't seem to take nearly 5-10 minutes; maybe 4 minutes or so? When the CH1 button quits flashing and the front panel button lights come on nothing shows on the display. At this point Step 7 is complete and you can proceed to Step 8.
Are the steps below the best steps for upgrading firmware, or are there better steps?
Also, where is the best place to get FW v.3 for the 2072 (2072, not 2072A in case there is any difference)?
I use that procedure - although I don't press the Help button 2 or 3 times: just 1 time and let go - but it has to be during the 1 second that all the buttons are lit, right after you press the On button (use two hands - as detailed in the second post of this thread).
I added the download link for FW v.3 - also in the second post of this thread.
Is the screen supposed to show anything when the upgrade is done? Or does the scope need to be powered off and back on when the all the front panel lights are lit continuously? Thx!
Yes, you have to power cycle (reboot) at the end (when all the lights are lit).
Ok, success! (I think). Thanks!
fyi, the CH1 button seemed to flash in Step 6 for about 30 seconds or possibly a bit longer.
Step 7 didn't seem to take nearly 5-10 minutes
Thanks again for the always deluxe EEVblog Forum help!
Ok, success! (I think). Thanks!
No problem. You can use
the technique described in post 2 to get the full firmware version info to check that the upgrade/downgrade occurred correctly.