Protocol decode wishlist

[tautech]

So most modern DSO's have some decoding capability with I²C, SPI, UART, RS232, CAN and LIN being the most common offered.
Looking at Wikipedia there is quite a list but some are beyond the BW capability of most cheaper and low BW DSO's.
https://en.wikipedia.org/wiki/Serial_communication

Are there other protocols not currently offered that need to be included in entry and mid range instruments ?

What do you need ?

[LaurentR]

Look at the list of Saleae officially supported protocols.
http://support.saleae.com/hc/en-us/sections/201990583-Supported-Protocols

That's quite a bit more than most scopes (and that's not including contributed protocols). Depending on your interest, USB might be useful, or DMX512 or JTAG. It really depends on what you are doing.

Asynchronous Serial
Inter-Integrated Circuit (I2C)
Serial Peripheral Interface (SPI)
Controller Area Network (CAN)
Digital MultipleX (DMX512)
Manchester
1-Wire
Inter-IC Sound (I2S / PCM)
Management Data Input/Output (MDIO)
BiSS C
HDMI Consumer Electronics Control (CEC)
PS/2 Keyboard/Mouse
UNI/O
Universal Serial Bus (USB) 2.0 (low speed and full speed)
Single-Wire Interface (SWI)
Simple Parallel
Local Interconnect Network (LIN)
Joint Test Action Group (JTAG)

[Berni]

It all depends on what you are working on, but they can't cover all the cases.

Some examples of things that are not offten seen are things like Dallas OneWire and Manchester encoding. A lot of things that go over the air such as IR remotes, garage door openers and such use some form of manchester or pulse width encoding to fit data reasonably reliably over the single serial link without a accurate time base.

But one does not deal with those all that often and manual decoding of them is usually not that bad.

The fancy high speed protocols like PCIe, SATA, MIPI, DisplayPort etc look like just like a continuous jumble of bits on a scope screen. Very difficult to make any sense of the data manually so a protocol decoder for those is very useful if you do need to look at one. But a active differential scope probe to tap of such fast signals, alone costs more than most entry level scopes.

[JPortici]

depends on what you are working on.
as for new protocols, a modern automotive package should at least have SENT for lower speed scopes and SENT + CAN-FD for higher speed scopes (both currently be found in picoscopes -free-, keysight x3000 -reasonably expensive-, Lecroy Wave surfer MXs-B -very expensive- and similarly priced tektronix/r&s)
they can be implemented in a slower scope

more variations on the theme.. manchester, uniwire, dmx, i2s... they'd be welcome of course and again they'd be doable in a lower end scope.

then maybe it's just me but i think that the lower end scopes are inherently limited by their hardware and should first focus on doing their job right and only then start and add features, but only when they are working. a broken feature is an useless feature. siglent should go ahead and finish off the 2000x series first. where is the power analyzer app? why is it just a sds1000x with a bit more memory and sample rate? that looks like an abandoned project. they do that one from scratch, right this time, start adding fancier decodes... it could be a hit

[nctnico]

Oscilloscopes from ZLG seem to decode a boatload of protocols (copied from their website):
ZDS2022: IIC,SPI,UART,USB,SD,CAN,LIN,FlexRay,1-Wire,PS/2,HDQ,Wiegand,DALI,DS18B20,SSI,IRDA,NEC,RC-5,RC-6,MANCHESTER,MILLER

ZDS2024 Plus: (close to US $3000) CAN,LIN,I2C,SPI,UART,USB,PS/2,DALI,Wiegand,1-Wire,DS18B20,HDQ, SD_SPI,SD_SD,IrDA,Manchester,DiffManchester,Miller,DHT11, SHT11, NEC,RC5,RC6,FlexRay,CAN FD

[tautech]

So for some of the low speed protocols how slow do we need to decode at ? 100ms/div ?

I've seen MIL protocols mentioned in threads but nobody's mentioned them. 

[mikeselectricstuff]

The question is which protocols are useful to have on a scope, i.e. need to be correlated with other hardware signals. Once protocols get more complex, it makes more sense to do them on a PC so you have a better UI for setting up filtering, higher level protocol layers etc.
Any protocol that uses hardware to implement ( ethernet,USB) isn't going to be needed by many people debugging hardware - the hardware interfaces will be well proven, so any debugging will be at higher levels and usually less timing sensitive. 

Manchester /biphase would be useful but there are many flavours so hard to cover all variants.

Of course the killer feature would be user-defineable decodes - even if these were entirely in software and not as fast, I'm sure there would be a lot of potential uses.
 

[tszaboo]

They need to upgrade the SPI itself for example. I had to debug a system, which had 18 bit ADCs daisy chained. That was impossible to do with any of the scopes we had. All of them were showing garbage.

I dont see the reason for USB. If USB isnt working, it is 99% the code doing something stupid. You cannot debug it, if you place a breakpoint, the system halts. Data is thrown back and forth, like no tomorrow, and no clear way of knowing
when, what and how is transmitted.

LIN+CAN should be standard, and not a 500EUR update. Flexray is so specialised, that nobody uses it, except big automotive. Price is irrelevant then. PS2 is dead.

What I would like to see is JESD204, QSPI, I2S, and NFC, with non intrusive probe kit.

[mikeselectricstuff]

What I would like to see is JESD204, QSPI, I2S, and NFC, with non intrusive probe kit.

QSPI definitely. Also maybe some generic DDR ( not at DRAM speeds, just SPI with data on both clocks).
I think Keysight have a solution for NFC.

[pascal_sweden]

It would be nice to have support for MDB and DEX, which are the 2 most common protocols used in vending machines.

I am not saying that every oscilloscope should have support for these protocols, but at least the Sigrok framework should have them included!

[abraxa]

I am not saying that every oscilloscope should have support for these protocols, but at least the Sigrok framework should have them included!

We're listening
Unfortunately though, we can't produce as many PDs as we'd like, so we depend on user contributions for the protocols we don't have easy access to (specs/measurements) and which are application specific (which I'd say is the case for MDB and DEX).

[Joel_l]

I'd be happy for user protocol support. Where I can write my own decoder and plug it in.

[Relaxe]

From Pico:
https://www.picotech.com/oscilloscope/2000/picoscope-2000-overview
PicoScope can decode 1-Wire, ARINC 429, CAN, DCC, DMX512, Ethernet,  FlexRay, I²C, I²S, LIN, PS/2, SENT, SPI, UART (RS-232 / RS-422 / RS-485), and USB 1.1 protocol data as standard, with more protocols in development and available in the future with free-of-charge software upgrades.

I had a need for ARINC 429, and the two options I have are PicoScopes or Agilent/Keysight DSOX3000/4000/6000 with DSOX?AERO option.

I really like the Picoscope, as it cost next to nothing (125$!) for the entry 2204A, and it decodes all those, for much less than a license option on the big scopes. Pretty good value imho.

[Fungus]

I'd be happy for user protocol support. Where I can write my own decoder and plug it in.

Get one of those $10 USB logic analyzers and a copy of Sigrok open source controller:

https://sigrok.org/

PicoScope can decode 1-Wire, ARINC 429, CAN, DCC, DMX512, Ethernet,  FlexRay, I²C, I²S, LIN, PS/2, SENT, SPI, UART (RS-232 / RS-422 / RS-485), and USB 1.1 protocol data as standard, with more protocols in development and available in the future with free-of-charge software upgrades.

Sigrok can do a lot better than Pico's puny little list:

https://sigrok.org/wiki/Protocol_decoders

Plus it might work with your oscilloscope, depending on model.

[MrW0lf]

Can see several Picos in "todo list"... But do agree that having non-open-source non-flexible "built in" protocols only is outdated concept. But much better than buy locked product and unlock for insane money...
Just like with math channels - I need complete freedom & full complex math: nonflexible +-*/ scope would be completely useless to me... Probably there is unlock sin/cos/tan for $1000 in some "high end" scope price list

[biot]

Sigrok can do a lot better than Pico's puny little list:

https://sigrok.org/wiki/Protocol_decoders

Plus it might work with your oscilloscope, depending on model.

Indeed sigrok has many more PDs, and supports many oscilloscopes, but please note that sigrok's protocol decoding is only for logic data i.e. retrieved from a logic analyzer or file format. It does not support live oscilloscope -> protocol decoding.

[AR]

Blueskull have you tried the scopes or for that matter their logic analysers.

[ebclr]

"ZLG is virtually the only feasible high quality, low cost dev ki"

For China, or even USA standards is far away to be considered low cost

https://zhiydz.world.taobao.com/

How ZLG handles the "chinglisg" problem ?

[thanasisk]

MIDI!

[joeqsmith]

Pretty rare it comes up for me.  As others mentioned, decoding the protocols is normally too complex so the scope would not be my choice of tools. 

[nctnico]

MIDI!

Midi = UART so that is already covered if your can set the baudrate freely (MIDI uses 32500 IIRC).

[mikeselectricstuff]

MIDI!

Midi = UART so that is already covered if your can set the baudrate freely (MIDI uses 32500 IIRC).

Ditto DMX, for all practical purposes. Pulse-width trigger if necessary to detect break.

[tautech]

Thanks for input so far guys, I suspect the addition of decoder suites in DSO's will get more competitive in the future and it's good to know what is wanted.

Should I add a poll to the thread ?
Of course for lesser instruments many protocols are not possible but some are, which should we include in a poll ?
 

What I would like to see is JESD204, QSPI, I2S, and NFC, with non intrusive probe kit.

Active or passive grabber ahla MSO/LA style ?

[oh2hyt]

Vote for I2S, it benefits to be seen with analog signals.

[bson]

I mainly only need I2C and SPI, but I would like to see an "analog" decoder - capture analog channel voltages at the time of a clock or other trigger and display them inline with the channel as if they were decoded.  (I assume with most scopes this would fit the existing decoder and measurement frameworks nicely.)