mike1305

Decoding Serial Data

Blog Post created by mike1305 Employee on Sep 1, 2016

If you are fluent in more than one language, you can appreciate how difficult it is to translate between different languages. Not only do you have to identify what languages are being spoken between two parties, but you must appreciate the nuances of each language. Often times certain words or phrases don’t translate well, creating confusion. Perhaps one person is speaking faster than you can understand, or using a local dialect you aren’t familiar with. Or what if the person you are translating for is only interested in particular words or phrases spoken by the other party? Or when the person speaks their native tongue incorrectly?

 

Translating for the grammar police doesn’t sound like a very fun job. But it does make for a great analogy. Engineers use test tools to translate communication protocols into readable formats to look for certain activity and errors, or to simply monitor activity on the bus. Today we’re going to talk about serial decoding, how it works, and some serious advantages for those of us who don’t speak fluent electricity. Which unless you are a superhero, is everyone!

 

What are your options?

If you’re working on design or debug of a serial bus protocol in a system, like USB, you likely have many weapons in your arsenal. A common first choice is a protocol analyzer. This tool will read out protocol layer information on the bus it’s designed to analyze. An example solution is Total Phase’s Beagle I2C/SPI sniffer. This will tell you what is being communicated and help identify improperly transmitted bits or frames. But, this tool will not tell you how or why said errors are occurring, nor show you bit timing.

 

 

 

 

 

 

A next step might be a logic analyzer with decode capabilities. Plenty of options exist at all different price ranges depending on your channel density and speeds required. This will show you the data being transmitted in the protocol layer, and show you bit timing charts using high/low views.

 

 

 

 

The ultimate tool is the oscilloscope, which provides the best view of physical layer issues that could be plaguing your bus. These physical layer problems – such as noise, jitter, glitches, or unstable edges – can’t be viewed on a protocol or logic analyzer.

 

 

 

 

 

 

How does an oscilloscope decode and trigger on a serial bus?

There are two ways an oscilloscope can decode bus traffic. The first is using a software routine. An acquisition is taken, then analyzed before the next acquisition. Second is using an ASIC or FPGA. This is much faster and can be done in real time. Both methods accomplish the same thing: identifying high and low levels in time, and using a given bit rate, creating a sequence of 1’s and 0’s. Once a bit stream is translated by the oscilloscope (e.g. 10001001010110010), the protocol in question must be identified and defined. Every protocol has a syntax, and the decoded bits are fed into it to translate them to readable information to the user. Most protocols have options that can change how the data is transmitted – this can range from bit rate, address size, payload size, and bit order. All of this needs to be fed to the oscilloscope for proper translation. Once that’s done, the oscilloscope can translate information from the bus into readable information to the user!

 

 

Once that is complete, the trigger process becomes simpler. Tell the oscilloscope what you are looking for – a certain address, a certain payload, or an error – and then it will decode in the background waiting for it. Once found, it will be displayed on screen! If you want more information on the Keysight serial bus decoding capabilities on InfiniiVision and Infiniium oscilloscopes:

 

InfiniiVision Serial Bus Options Data Sheet

 

See all of the Keysight oscilloscope serial bus software options

Outcomes