Multiple Protocol Analysis (and SPI deficiency)

Forum for discussing PicoScope version 6 (non-automotive version)
Post Reply
Mark_O
Advanced
Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Multiple Protocol Analysis (and SPI deficiency)

Post by Mark_O »

Pico6 has the enviable capability to handle as many protocol decoders as the instrument has channels. While other self-contained scope products with decode capabilities are far more limited. Most being limited to just two, with a few capable of 4, and some only 1. This is a powerful advantage for the PicoScope series, especially on the MSO products, that expand a 4 analog channel device with an additional 16 digital channels.

My question is, in the Table View, what provisions does Pico6 make for integrating the decoded data streams? In the graph view, it's easy enough to visualize the temporal relationships between the channels, because they are all visible in the same window. But in the Table View, I have the impression (possibly flawed?) that each table only shows the decoded information for a single channel. This would seem to destroy any capability to see the sequence of related cross-channel transfers. The data is "unwoven", with no way to reintegrate it.

This is a capability that would obviously be useful in a variety of situations, where comms traffic may move from one bus to another, in a cause & effect relationship. But it's absence seems (to me ) to be far worse (crippling?) when dealing with the current SPI decoder. This has been split into one decoder per data stream (plus Clock, and possibly Select). But SPI is a bidirectional bus, which is a Send/Receive situation. If I can only see one side of the conversation at a time, things will be very difficult. Pico apparently forces you to define two separate decoders for this case? This makes about as much sense to me as splitting UART Rx/Tx into two separate buses would*.

Could someone at PicoTech help clarify these questions?

- Mark

[*Oops! I see that Pico does this as well! :shock: To me, this seems FAR worse than even the cheapest and most limited stand-alone scope, which integrates the Send/Receive channels, on buses with that orientation. But on Pico, these are two separate Tabs in the Table view, with only one of them visible at a time. Am I missing something?]

Martyn
Site Admin
Site Admin
Posts: 4491
Joined: Fri Jun 10, 2011 8:15 am
Location: St. Neots

Re: Multiple Protocol Analysis (and SPI deficiency)

Post by Martyn »

The decoded data can be seen relative to other streams in the scope window, however the tables are tabbed per individual protocol.

I will suggest to the development team that a single table view, possibly with colour coding related to the channels, would be a positive addition to the software.
Martyn
Technical Support Manager

Mark_O
Advanced
Posts: 0
Joined: Fri Oct 03, 2014 5:58 am

Re: Multiple Protocol Analysis (and SPI deficiency)

Post by Mark_O »

Thanks, Martyn. That would be a major and most welcome improvement.
I will suggest to the development team that a single table view, possibly with colour coding related to the channels, would be a positive addition to the software.
I especially like the color-coding idea. That avoids a need to add an additional column, to differentiate data source. (Though having such an [optional] column will be necessary when exporting to a CSV, for example.)

This would be a big win for all comms that are bi-directional [full duplex] in nature (UART, SPI, etc.). So much of that is handshaked, request-response in nature, that seeing only one side of the conversation in isolation is a real handicap.

- Mark

Post Reply