A question on digital oscilloscope option (decoding).

[CiscERsang]

Hello everyone,

I never used even cheapest digital oscillosccope. I know that most of dig. scopes are capable to decode serial frames (e.g. UART). I watched some videos on this option.


I don't understand, whether the frame must be transmited continuosly or it just captured frame (my guess). Most of videos begin with the frame on the screen.
And nobody said, what's the frame, from where, real time or not and so on.


Could anyone explain step by step this procedure?

Thank you...

[nctnico]

A frame is a bit of a loose term. It can refer to a single transaction (like one character on a serial bus) but also a collection of characters which form a packet (a.k.a. frame).

The data doesn't need to be captured continuously BUT there are two types of decoding: on some oscilloscopes (Keysight, R&S, MicSig) you have to setup the decoding before you are going to make an acquisition. You can't turn decoding on afterwards or fiddle with the settings. On other oscilloscopes (GW Instek for sure) you can turn on decoding afterwards and fiddle with the decoding settings after doing an acquisition. The latter method usually is slower though.

[CiscERsang]

A frame is a bit of a loose term. It can refer to a single transaction (like one character on a serial bus) but also a collection of characters which form a packet (a.k.a. frame).

The data doesn't need to be captured continuously BUT there are two types of decoding: on some oscilloscopes (Keysigh, R&S, MicSig) you have to setup the decoding before you are going to make an acquisition. You can't turn decoding on afterwards or fiddle with the settings. On other oscilloscopes (GW Instek for sure) you can turn on decoding afterwards and fiddle with the decoding settings after doing an acquisition. The latter method usually is slower though.

For example I need to read/decode an answer from device with serial interface..


My guess:
-I made a query;
-once after, within 100ms an answer came.

What do I have to do first with this answer? How to handle with this, it happened within 100ms or even less.

[nctnico]

I'd choose an oscilloscope with deep memory and set the time/div to 10ms/div or 20ms/div so both the query and the answer fit on the screen. Then let the oscilloscope trigger on the channel connected to the transmit side for your query. Stop the oscilloscope once the signals are captured. With decoding enabled, you should be able to see the messages. Using the horizontal controls or the zoom mode you should be able to scroll through the messages. If you are not interested in the signals then you can also see a list of all the character captured.

[schmitt trigger]

Since, from your own words, you don't have experience with scopes, then IMHO your selection criteria should include a simple and intuitive user interface.
Not all scopes are created equal in this respect.

Also, you require to know which protocols you would like to decode. UART, I2C and SPI are obvious in the microcontroller world. But perhaps you may want also to see more advanced busses like CAN.

[DaJMasta]

Scope decoding is basically limited to the size of your capture, so if you want more data decoded or more time spent listening, you zoom out, make your capture, then zoom in on what's important.  That means segmented memory options and things can help cut out some of the wasted downtime, but a scope's ability to decode something is generally only limited by whether it can be fit into the acquisition memory.  Some scopes with decoding features and some hardware dedicated for it will let you trigger off of decoding events, which can make it easier to use limited memory successfully or make it easier to find what you're looking for.

[Fungus]

I don't understand, whether the frame must be transmited continuosly or it just captured frame (my guess). Most of videos begin with the frame on the screen.
And nobody said, what's the frame, from where, real time or not and so on.

It usually makes sense to capture some data then analyze it so that's what you see in videos.

Decoding is real time though. You set the 'scope to "trigger" on a specific pattern in the signal (eg. a rising/falling edge, a special byte in the serial data, etc) and it will start capturing/decoding/displaying when it sees that pattern.

When the internal memory is full it will restart, waiting for another trigger then overwriting the previous data.

[porker1972]

There's a few gotchas when using a scope for serial decode. As always, take a long capture and high input setting to see what is going on, and then change both time and V/Div settings to the correct level for the signal of interest. Make the vertical scale as big as possible to ensure you get the best vertical (voltage) accuracy without going outside the display.

Auto/normal/single trigger mode
Most of the time, the "auto" mode is used as it will throw up the contents of the memory to the screen, regardless of the trigger condition being met or not. This is not what you want for serial data as it can jump around the screen or the auto mode refresh-time can miss packets completely. So you want to set to "normal" trigger mode - this will only display data when the trigger condition is met.

Trigger condition
Most scopes with the serial decode option will have the option to trigger on the serial packet - easiest to work from is "start of frame" condition or similar. You can then refine to a particular "packet ID"/"address" or "data value" if that's of interest. This can be tricky to set up and you often need to copy the conditions for decode to the trigger menu.

Decode
There may still be some settings you need to adjust in the menu, such as baud rate, start/stop bits, etc. in order to decode correctly.

Decode threshold level
Depending on the signal, you typically want the threshold level for decode to be at 50% of the signal level to avoid noise, bounce or probe loading or probe compensation. You can adjust the threshold level to reduce these measurement-sourced errors.

Segmented memory
Not all scopes offer this, but it's really useful for serial data. Normally, a scope fills the memory from the trigger point, and regardless of what signal is captured, that takes up memory and is displayed. So if you're bus loading is only 1%, then 99% of the memory is wasted on acquiring no signal and displaying nothing but the baseline noise. Segmented memory allows you to set the scope to only capture a signal of interest, then wait to capture the next one, and so on.  You can set as many segments as you want: 2, 10, 50, 100 or 1,000s, depending on the scope's capability and total memory length. Once this is full or you stop the scope, you can then review or overlay the individual acquisitions, effectively giving you millions or billions of points of data that are only focused on the thing you want.

[CiscERsang]

Segmented memory
Not all scopes offer this, but it's really useful for serial data. Normally, a scope fills the memory from the trigger point, and regardless of what signal is captured, that takes up memory and is displayed. So if you're bus loading is only 1%, then 99% of the memory is wasted on acquiring no signal and displaying nothing but the baseline noise. Segmented memory allows you to set the scope to only capture a signal of interest, then wait to capture the next one, and so on.  You can set as many segments as you want: 2, 10, 50, 100 or 1,000s, depending on the scope's capability and total memory length. Once this is full or you stop the scope, you can then review or overlay the individual acquisitions, effectively giving you millions or billions of points of data that are only focused on the thing you want.

And of course, segmented memory oscilloscopes cost a fortune... Judging on Scope's size and number of buttons on the panel.

]

[H.O]

Many of the low(er) end scopes have segmented memory but, as have been said, there are plenty of gotchas - that of course applies to all scopes but probably more so the cheapest ones.

For example my Rigol DS4000 series scope have 140M of memory and can capture (and subsequently decode) tens of thousands of segments/captures/frames, whatever you want to call it. But once you've captured, say 5000 frames to the scopes memory - what are you going to do? On the DS4000 you can't do much more than "step thru" them one by or play them back on the screen at a variable pace. More advanced scopes apparently (I've never used one) have better options for handling that, searching for specific events within the captured segments/frames and so on.

For many things something like cheap USB logic analyzer is a much better tool than an oscilloscope when debugging serial stuff.