Most modern scopes offer some kind of serial data stream decoding. Many supply it as a paid for optional extra although special offers where some decoders are bundled with the instrument are common.
Pico have an unusual approach - all the serial decoders are bundled into the standard Picoscope 6 software and, hardware permitting, they work across the range of Pico's scopes.
The range is quite good:
Pico's decoders work on captured data which has been moved to the PC for processing. This means that you can't trigger off decoded data. Some scopes decode the serial protocol in hardware in the scope and they can trigger of a limited set of decoded data. In my blog Picoscope 6424E Road Test - SPI Testing with MSO Pods I talk a bit more about this.
From my my work with this and several other scopes I've found that most of the time it's not terribly important.
The 6424E can be set up to trigger from a hardware event and then to store data in buffers (it does this all the time by default). You can set the size and number of the buffers, and because the scope has a huge memory the number of buffers can be quite large. We'll see this working in this blog.
I'm looking at data from a CO2 sensor. It's using its I2C interface. It signals when data is ready by pulsing the ready pin, you are allowed to read data from it immediately after the falling edge of the Ready signal.
This is a prototype sensor and I've made it do some odd things to help put the 6424E through its paces.
The sensor is hooked up to a test system and the Picoscope is looking passively at the I2C bus.
6424E triggered on Ready (channel C) falling edge
I've set the scope to use 512 buffers each of 1Msamples. Then in the serial decoder results table I've asked the scope to find buffers containing and Address Acknowledge in the data.
I've popped up a Buffer management window to choose the buffer to look at, by default the scope shows the last one to be filled.
I'm triggering the tester to actually respond to the Ready signal by hand, and I triggered it three times in this test run.
Update 23/10/2020
The simple fixes are always the best !
It turns out that my new HP computer has mainly USB2 sockets, as far as I can tell only the two sockets on the front are USB 3 SuperSpeed capable !
So my tests so far have mostly been based on using USB2 speed connection to the Picoscope - and the notes above reference the first speed issue I've noticed.
I'll repeat the tests with a USB 3 connection.
(There is a thing you can download from Microsoft called USBview which can tell you what your ports are capable of and what they are currently doing.)
NB The following 4 paragraphs were written with the Picoscope connected by USB2 which limits its performance in these modes.
If I increase the number of samples to 5Ms per buffer the Picoscope misses most of the I2C transactions, (only saw 1 out of three).
With 1Ms per buffer the 6424E can keep up with the sensor (which generates 2 ready pulses per second).
At 5Ms per buffer the scope can't keep up and manages only 29 buffers in 30 seconds.
This is rather grim so I investigated further.
If you turn the serial decoding and low pass filtering off (must turn both off) then the scope can keep up and capture 5Ms at 2Hz repetition rate.
If you then stop it (in my case after 30 seconds) and turn serial decoding and the low pass filters back on they are applied to the captured data.
The search buffers tool found all the Address Acks that were placed on the I2C bus.
The search in buffers feature of the serial decoding table ran at a reasonable speed considering the amount of data but the operation of the
Buffer management window became criminally slow. This was made much worse by the lack of any quick way of navigating to a known buffer.
I have to say this is a bit disappointing - if I can make the scope capture at a better rate by switching stuff off during capture and back on again later then the scope should do that itself.
And it could also easily tell you that triggers have been missed, and estimate the actual update rate according to what is switched on.
So I have to be honest here and say that this was a pretty mixed experience.
The basic decoder operation seems fine and has some nice features, but the impact on update rate of having it switched on is not good.
The tools for looking at data in the buffers are not up to the job of managing the Gbytes of memory fitted to the scope.
I'm going to leave Serial Decoding here, and try to find some time to investigate the update rate thing in more detail - perhaps I've missed something.
MK
Top Comments