Feeding hardware-decoded packets into libsigrok

Soeren Apel came up with an interesting use-case:

The yokogawa DLM2000 series can do I2C decoding on the device, and feed the I2C packets and associated metadata to an SCPI client:

:SERialbus<x>:I2C:DETail:LIST:ITEM?
Queries all items that will be displayed in the I2C
bus signal analysis result list.
 
Example :SERIALBUS1:I2C:DETAIL:LIST:ITEM?
-> "No.,Time(ms),1st,2nd,R/W,Data,Information"
 
 
:SERialbus<x>:I2C:DETail:LIST:VALue?
Queries all of the data for the specified analysis
number in the I2C bus signal analysis result list.
 
Example :SERIALBUS1:I2C:DETAIL:LIST:VALUE? 0
-> "0,-0.07000,AA*,,W,AE*88*,7-bit"

This hardware-level decoder has access to more raw data than device ever feeds to sigrok: it cannot stream continually via SCPI transports, for example. So it's entirely possible, even likely, that the hardware can decode more I2C data from the raw signal than libsigrok/libsigrokdecode ever could.

Thus, this is a use-case for getting I2C packets from the hardware, associating it with libsigrok timing reference (sample numbers) and feeding to libsigrokdecode as an I2C packet -- to PDs that normally take their input from the libsigrokdecode I2C PD.

This involves:

• libsigrok would need a facility to send decoded packets over the session bus. This is certainly a new packet type, for example SR_DF_I2C.
• libsigrokdecode would need a way to receive more than just raw logic. The inter-PD Python object format for (in this case) I2C would need to be nailed down and formalized, and a way for the library to receive I2C in packet format and convert to the Python object.

Other scopes that can send decoded data over SCPI

Keysight InfiniiVision 3000 X-Series Oscilloscopes and Agilent InfiniiVision 7000A Series Oscilloscopes:

:LISTer:DATA
Query Syntax :LISTer:DATA?
The :LISTer:DATA? query returns the lister data.
Return Format <binary block><NL>
<binary_block> ::= comma-separated data with newlines at the end of each row

RS232

• One or two serial ports could be used as a "poor man's capture device" to decode RS232. The communication parameters for RS232 would have to be known to capture, the higher level protocol could then be analyzed with lsrd.
• The output of a program like interceptty could be converted into the sigrok format and then be analyzed. No need to hook up any probes.

Both use cases could be useful if no "real" logic analyzer is available or for debugging.