I want a new scope, and I want it to be able to decode. But why do I want that?
I've tried manually decoding using an analog scope but that was frustrating because the waveform wouldn't sit still. However, if I were just a little ambitious I could program a microcontroller to read the data and display it on a terminal. I could hook up the scope too and even send a trigger signal on a particular packet and watch the waveform, for a split second I guess...
Aside from the convenience of using decode on a DSO, what advantages are there (in terms of reading the serial data)?
I have in mind a project that I set aside where I needed to figure out what data was being sent to a power wheelchair motor driver so that I could replicate it and operate it independently from the main controller.
Hello W9GFO,
I personnaly find the decodes on scope kind of pointless: They are expensive options (when properly bought) and then, you need to read it out on the little screen with no quick copy-paste abilities.
Depending on the protocal to decode, I would guide you toward:
- The Saleae Logic series that can decode a lot of stuff in a cheap package
- The Picoscope 2204A that is a real scope in a USB package, quite cheap and can decode everything I can think of (even ARINC-429 mind you).
- The Bus Pirate if you are a little more hands-on
Else, why not... but only if free with the scope.
It really depends on whether you want or need to be able to observe a cause and effect scenario between your command/control bus and the hardware it's talking to. Of course, serial decode can help you do this easily. Even better is if the scope supports live decode and triggering, so that you can trigger on a specific command/address/data_word, etc. in the serial stream - that's even more helpful when trying to troubleshoot communications issues.
If you purely want serial decoding, and don't care about seeing additional signals (analog, etc.) along with your decoded bus in a time-correlated display, then the inexpensive logic analyzers would suffice.
You want decode because your time is much more valuable than the hours spent decoding manually.
Triggering on decode is crucial when you are testing algorythms or when glitches happen.
Decoding and triggerin on a scope is nearly essential when developing hardware /software. Otherwise other tools are better.
E.g.: using a scope to map a canbus network is a gateway to a permanent visit into a mental institute. A canbus analyzer however is the proper tool and makes the job a breeze, in comparison
I want a new scope, and I want it to be able to decode. But why do I want that?
I've tried manually decoding using an analog scope but that was frustrating because the waveform wouldn't sit still.
Yes, that can be frustrating.
However, if I were just a little ambitious I could program a microcontroller to read the data and display it on a terminal.
I'd be less ambitious and use an existing cheap tool. If it is RS232 then get an RS232-USB dongle. If it is something else, then see if a "bus pirate" can capture the signals. If not, then use an LA.
I could hook up the scope too and even send a trigger signal on a particular packet and watch the waveform, for a split second I guess...
If the controller is under your, ahem, control, then insert printf statements and waggle i/o pins at opportune points in the code.
IMHO it's easier to use one of those cheap little USB logic analyzer things than to bother with serial decode on a scope. Unless you already have a scope that has that feature, but I wouldn't sacrifice other features to get that in a scope.
I want a new scope, and I want it to be able to decode. But why do I want that?
I've tried manually decoding using an analog scope but that was frustrating because the waveform wouldn't sit still. However, if I were just a little ambitious I could program a microcontroller to read the data and display it on a terminal. I could hook up the scope too and even send a trigger signal on a particular packet and watch the waveform, for a split second I guess...
Aside from the convenience of using decode on a DSO, what advantages are there (in terms of reading the serial data)?
IMHO decoding is easy to check if communication works by looking at both the signal levels and data. A good DSO will also allow to save all the messages to a CSV file so you can analyse the data on a PC using Excel or something like that to look for a very specific message.
For anything that does anytyhing realtime involving serial protocols , the ability to see serial activity in real time, correlated to other events can be a huge time saver.
And as per the video, serial decode isn't just for comms related applications.
It does seem like the sort of thing that should just be standard on any DSO made in the last 20 years, although that seems to not be the case. The data is there, the decoding would have been relatively easy to implement in software and certainly many scopes do much more complex operations. If I were designing a scope I would also include a way to create user defined protocol decoding.
The reason it should be standard is that a scope is a general-purpose instrument, and most things people poke scopes at have some sort of serial in them these days.
FFTs are now standard, and I'd argue less useful to most users than serial decode.
Apparently the new Siglent includes it as standard, hopefully this might start a trend, though was disappointed to see the new R&S had it as 2 seperate, expensive options for UART and SPI/I2C.
I have much less of a problem accepting that more niche things like CAN,LIN,FLEXRAY, ARINC or whatever should be options, but UART,I2C and SPI are everywhere
I want a new scope, and I want it to be able to decode. But why do I want that?
I've tried manually decoding using an analog scope but that was frustrating because the waveform wouldn't sit still. However, if I were just a little ambitious I could program a microcontroller to read the data and display it on a terminal. I could hook up the scope too and even send a trigger signal on a particular packet and watch the waveform, for a split second I guess...
Aside from the convenience of using decode on a DSO, what advantages are there (in terms of reading the serial data)?
I have in mind a project that I set aside where I needed to figure out what data was being sent to a power wheelchair motor driver so that I could replicate it and operate it independently from the main controller.
At worst you need a protocol trigger suite, that makes it much easier to trigger on a POI within a stream or packet.
This can be an option in some DSO's and others come with it free, likewise with a Decode suite.
Some screenshots added from another thread for you to study.
Most info can be gleaned from seen settings of the UI.
- The Picoscope 2204A that is a real scope in a USB package, quite cheap and can decode everything I can think of (even ARINC-429 mind you).
I'm just discovering possibilities of it's older brother 2408B, not very confident yet... but what the heck...
First bad: no serial trigger, just like on Saleae analyzers. Cost of doing it in software... But! I'm have some early ideas...
Now good, what I did:
- connected Arduino with "modified" USB cable to sniff on
- using Rapid trigger (~1.3Mwfm/s capability) on pulse width between USB 1.1 packets stuffed all 125MB of mem full of them
- applied decode
Excuse little crappy low-res looking screenshot - Windows 7 150% system zoom, but otherwise...
- 6553x2x10,000 samples in segmented memory
- decoded only part between cursors (just to try) in each segment
- can search/filter/sort/analyze/read stats over
all memory segments (or any single if like)
I do realise did not need 500MSa/s sampling rate for that... Just wanted to try if will it struggle with decoding full memory with excessive resolution on wfm. It did take some tens of seconds but finally manged.
- The Picoscope 2204A that is a real scope in a USB package, quite cheap and can decode everything I can think of (even ARINC-429 mind you).
I'm just discovering possibilities of it's older brother 2408B, not very confident yet... but what the heck...
First bad: no serial trigger, just like on Saleae analyzers. Cost of doing it in software... But! I'm have some early ideas...
Now good, what I did:
- connected Arduino with "modified" USB cable to sniff on
- using Rapid trigger (~1.3Mwfm/s capability) on pulse width between USB 1.1 packets stuffed all 125MB of mem full of them
- applied decode
Excuse little crappy low-res looking screenshot - Windows 7 150% system zoom, but otherwise...
- 6553x2x10,000 samples in segmented memory
- decoded only part between cursors (just to try) in each segment
- can search/filter/sort/analyze/read stats over all memory segments (or any single if like)
I do realise did not need 500MSa/s sampling rate for that... Just wanted to try if will it struggle with decoding full memory with excessive resolution on wfm. It did take some tens of seconds but finally manged.
Nice to see this confirmed
Serial decode is quite useful for the given situation, while you use it, you'll agree with me. So that's my main complain reason to my new scope TO1104
, they said serial decode function will coming soon. I don't know what means soon, anyway I still look forward to it.
I use my scope a lot as a debugging aid when I'm writing for Arduino. It's really useful to see when events happen, etc. Just connect the probe to a pin and toggle the pin in an interrupt handler or whatever so you can see what's going on.
You can send messages to the 'scope from the serial port, eg. send a letter 'A' when a particular thing happens. It appears on the screen of the 'scope in real time so you can see what the inputs were at that moment. You can also trigger the 'scope on a letter to record events when they happen.
(nb. Most logic analyzers don't do real time. You have to hit 'record', 'stop' then go in and look for things. That's the advantage a 'scope has over them).
So basically.... if you have serial decode you'll think of crazy uses for it.
If you're regularly trying to do it on an analog 'scope at the moment then a DSO with decoders is a no-brainer. It will save you loads of time.