MSOs with full duplex bus decoding?

[rhb]

Does anyone have a list of makes and models that can decode both directions on two buses?  Or know of an LA which can export a trigger to a generic DSO? 

I'm trying to find long decode buffer, long FFTs, deep 4 channel scope and LA memory and dual full duplex serial bus decoding.  So far it looks as if I need 2-3 different instruments or something the price of a luxury car.

[MrW0lf]

On any Picoscope you can define pretty much arb number of decoders incl ones with some lines overlapping which should cover N * duplex SPI. Arb number of 2MPts FFTs (on large memory models). All same time in multiple viewports much like it works on high end scopes. Their website currently reports 3406D MSO: 200MHz, 512 MS shared mem, 4ch analog, 16ch digital for €2025 which is approx price for luxury pedal car
On the other hand I have here my old 2205 MSO - 25MHz, 2ch analog, 16ch digital which costs nothing and can also do many tricks only limited by small memory and ch count. Software is same on all real time models.
However you may run out of sampling rate if fire up all channels at once. Wfm/s rate may drop due to excessive processing load etc. Much like with high end scopes which are not famous for insane wfm rates. Segmented memory may be of some help with that. Just stuff memory full at >1Mwfm/s rate and deal with consequences later.
If interest I might connect something up to MSO and try later. However not very home at this my focus is in analog domain.
Edit: forget - no serial trigger, only pattern. However many cheap DSOs have that, but no advanced processing or deep mem. So I've been thinking if ever gonna serial trig. just buy cheap simple DSO that can trigger on needed protocol and feed trig out to some digital ch. Lose 1 bit gain serial trigger.

[rhb]

Thanks.  I'll give the Pico 4306M another look.  I was initially a bit put off by the price and the lack of standalone functionality.  But for embedded dev work a computer is going to be there anyway to do the software dev work.  The Pico looks as if would be worth having even if I later bought a standalone scope with similar features.  The Pico and a laptop would be a pretty good portable lab for contract work.

Never having had an MSO before it's been hard to figure out what mattered until I tried doing things with the instrument.  One of my biggest problems is having been brought up pinching pennies.  True wealth is being able to ignore the subject of money at will.  Thrift is one of the easiest ways to achieve that.

[MrW0lf]

One thing to consider do you really need 200MHz/512MS. It will drop quite considerably in sampling rate when enabling all channels:

1 GS/s (1 analog channel)
500 MS/s (up to 2 analog channels or digital ports*)
250 MS/s (up to 4 analog channels or digital ports*)
125 MS/s (all other combinations)

So you can take advantage of 200MHz analog only with up to 2 channels - more channels and it may become even a problem.
On the other hand ~500€ cheaper 3405D 100MHz/256MS model will probably have analog bw in the 140MHz range (at least my 2408B 100MHz/128MS has) which is more balanced with sampling rate options in general.
Do not suggest go lower than 3405D MSO because only two top models have high timebase accuracy.

[MrW0lf]

Ok finally got around to do little demo what my old PicoScope 2205 MSO (25MHz, 2ch + 16ch, 200MSa/s, 48kSa) can do on software level.
Hardware wise it is of course very limited compared to modern models and barely catches activity presented below.

Setup contains 3 main realtime activities:

Arduino Uno + Adafruit LSMD9DS0 Gyro/Accelerometer/Magnetometer

SPI comms, 2 devices (G, XM)

D9: XM chip select
D10: G chip select
D11: MOSI
D12: MISO
D13: clock

To see what is going on 4 decoders are defined.
Comms buffered (128 buffers, max 10k).
G=>Arduino traffic in focus, filtered by data containing "FFF"

Virtual analog channel

Uno plays 8bit sine wave on D0-D7 which is converted to virtual analog channel using math. Originally I developed this tech to obtain up to 16bit analog channel for sharp look at time correlated sensor data.

Spectrum on math

Also spectrum view is active showing some noise on ChA and FFT performed on math (virtual analog channel with sine).

Wfm rate about 10Hz on old i7. Setting all this up could be smoother but on the other hand one just cannot do something combined like this on most scopes so this is why I like these little soapboxes.

Think it would be not hard to dump time correlated printf stuff directly into scope because I have 3 free digitals in this setup which could be configured as additional UART/ASCII decoder.

[rhb]

Thank your very much for taking the trouble to do that.  I'll need to study it  more fully  and download the software and run it in demo mode. Being able to send a trigger out to a faster scope makes the 2 channel Pico 3000M series probably a better choice than the 3406M.

[rhb]

Unfortunately, the demo mode does not include any LA functions that I can find.  So I can't even find out what the menu system is like.   I'll contact Pico and ask about it.  I tried 6.12.9.xxxx

[JPortici]

please be careful that (unless things have changed in the newest models) the pico CANNOT trigger on serial protocols, as they are applied on the PC side. This can be frustrating as you can't trigger on errors

[MrW0lf]

If I remember correctly from some other thread rhb has GWI2000? In this context what I would do is to use GWI as "trigger slave" for PS3000. BTW 2 channel Pico models do not have any tech advantage over 4ch ones, since they have only trigger IN.

Edit: In demo you can actually try out decoding, but use analog or math channels as input. There is indeed no simulation for MSO part. AFAIK decoder functionality does not depend on input otherwise that you gain analog signal stats with analog channels.  Also there are no protocol demo signals, but you could open some file with saved wfms if someone provides it. I'm away from home lab so cannot help with this. Apply pressure on support. It would make sense that they at least keep some public library of demo wfms.

Analog stats feature can be seen here:

[rhb]

I've got an Instek MSO-2204EA which I've been evaluating.  The UI is absolutely maddening, but it seems otherwise to be well built and quite capable.  If the R&S  RTB2K would handle dual full duplex decoding I'd get one, but it can't and won't any time soon.  The Keysight MSO3000T makes my eyes water when I total all the options.

Not triggering on a bus event pretty much kills the Pico for me right now.  I'll check directly with Pico on that.

[SparkyFX]

I currently got similar requirements for a new scope and just wait for a good price for an 3406D MSO.

Not triggering on a bus event pretty much kills the Pico for me right now.

Well it triggers on edges, pulses and so on.
The decoding is not in the device, but only very few MSOs or even logic analyzers can do that, most only as an option. It is nice to have, because it means you need less sample memory, the more specific your trigger is, on the other hand you got so much sample memory with the picoscopes that it´s unlikely to lose the data as long as you can narrow in a timeslot or another event just enough and search for it in the list of events afterwards.
A workaround could be to build a detector circuit for the very case which needs to be triggered and provides an interrupt for it, once i am messing around with protocols on physical level i might have the hardware for it laying around anyway.

It could be as simple as a (long) serial to parallel shift register with an AND mask once you get the clock right, which is the hard part in all bit banging. For the picoscopes there is also an API with less limitations than their software to fetch the sample memory, so it is possible to get quite some data. As long as we are talking about the typical protocols that run within 100MHz Bandwidth. (MSO channels: 100 MHz Bandwidth, analog channels: 200 MHz for an 3406D MSO; also: no BNC trigger input for MSO models, only as digital channel)

The problem with triggering serial data is that the trigger you need usually does not exist and needs to be coded anyway, as they can be very specific. Admittedly, implementing a protocol stack just for triggering is a tough nut, so i´d rather go with full controllers for that protocol in hardware as a development tool.

[JPortici]

Well it triggers on edges, pulses and so on.

but it can't decode on bus errors, let them be checksum errors in multi-packet transactions, nacks when they should be acks and whatever, and it won't until the decoding is done inside the pico.

[SparkyFX]

I hear you, it´s just that that exceeds the general MSO profile and therefore might never implement the full protocol like a silent listener, as it will not recognize a virtual bus state at all. E.g. implementing node-internal error counters and deciding which system behavior is valid as such in a given situation at a given time. That part of the state machine is usually only available in a full implementation, but i doubt many MSOs do that. Should you actively test a device that is master or slave... you´d mostly need to create the test condition and send crafted packets. Should you develop a bit banging solution that you need to debug you could as well build two and use one for triggering or make it output a trigger - just as a suggestion, stating the obvious.

For decoding data on a bus alone i can live with waiting to show up in the list and double click on the list entry for an errorframe to see it with other channels and the packets before and after that. Triggering at wirespeed for a (any possible) serial protocol... is kind of a special problem as the processing of frames/data usually happens later.

It doesn´t replace specialized applications for a given protocol. I work a lot with CAN on all layers and got some fun projects with SPI and I²C.

edit, P.S.: with bench units its highly unlikely to get a software upgrade to cover an additional protocol at all or after its EOL, it´s even unlikely if there are decoding errors. You paid, to get more features you´ve got to buy a newer model. But as the software for the picos is the same for all models, they are practically all covered by an update with new features.