Saleae team - we would love samples of protocol captures!

[markgarrison]

Hello all,

Here at Saleae we’re working on improvements to our new Python high level analyzer system, but we’re struggling to collect real-world samples of protocol data - especially while working from home.

If possible, we would really appreciate it if you could share with us protocol data recordings of real-world applications.

Any protocol data will help, but the following would be the most useful:

• I2C
• SPI
• Serial
• 1-Wire
• CAN
• Manchester
  (other protocols welcome, but we won’t have high-level analyzer support for them for a bit longer)

Also, please let us know which devices are active in the recordings, so we can look up datasheets.

We’re collecting these samples so we can work on developing high level protocol analyzers using our own SDK. More example recordings will help us make improvements to the API.

We’ll also be sure to publish any high level analyzers we produce in the process.

Be sure to make the recording using the Alpha software, and save the capture to an *.sal file. Feel free to attach it in a reply to this topic!

No interaction is too small - even if you’re simply reading a few bytes from an I2C EEPROM, that would help a lot.

We would love your help!

Thanks again,
Mark Garrison & the Saleae Team.

[siddacious]

I’ve got lots of I2C sensors and a good amount of SPI as well. I’ve got a CANbus project ready for testing as well so I’ll try and get a capture there too.

I’ll try to get a decent cross-section of protocols over the weekend while I work on my HLA

[markgarrison]

@siddacious

and a good amount of SPI as well. I’ve got a CANbus project ready for testing as well so I’ll try and get a capture there too.

I’ll try to get a decent cross-section of protocols over the weekend while I wo

Thanks, that sounds like it could help a lot!

[P.Jaquiery]

Async and I2C.sal (4.0 MB)

Async serial on D9: PLC Tx.
TUSB422 on I2C pair D5/D4 (SDA/SCL)
HLA running off I2C analyser on D4/D5 as H0: I2C PD
HighLevelAnalyzer.zip (4.7 KB)

(note that the upload didn’t like a .py file so I’ve zipped it.)

[rei_vilo]

Here is the trace of the I²C sensors of the LPSTK-C1352R

• HDC2080 0x41 temperature and humidity
• OPT3001 0x44 ambient light

I²C - HDC2080 OPT3001.sal (14.8 KB)

Edit: added links to data-sheets

[markgarrison]

Thanks @P.Jaquiery and @rei_vilo! These are great!

@P.Jaquiery I see you have two pairs of serial Rx/Tx signals in there. Could you send us captures that show traffic back & forth on RX & TX? One of the big upcoming features of python high level analyzers is to support multiple input analyzers, specifically to support protocols where you would like to process RX and TX data, in order decode things like requests & responses.

[P.Jaquiery]

Hi Mark,

I’m using the serial lines for debug consoles on two different pieces of hardware that are connecting to each other over USB-C. Most of the serial activity is status logging from the two systems with the very occasional manual debug command. But what could be more interesting is looking at the serial data and the I2C data. There is a strong correlation between the serial log data and the I2C activity. In the capture I posted the PLC device sends a logged, but unseen, device capabilities message to the FES device which results in a burst of I2C activity. A meta analyser that could work with PLC Tx traffic and either the I2C traffic, or the I2C PD (HLA) traffic would allow things like response time measurement between the two systems.

Mixing in edge detection on INT_N (the interrupt line related to the I2C) would be really useful too. That would allow interrupt response time to be measured and provide information about system performance.

For this particular system there are 6 USB-C ports on the PLC device with multiple large complicated state machines that interact with each other for each port. On top of that the power for the ports is managed by a supervisor and there is an Ethernet port running IEEE-1588 precision time sync protocol in there somewhere as well. I’m going to be interested in that sort of performance measurement fairly soon!

I’m happy to provide you with more captures of a similar sort. I could drop them in a Google Drive folder and share that, or somewhere else that works for you. I’m kinda anti Dropbox, but could use that if pressed.

Cheers,
Peter

[Jerry]

OK…You ask, I provide…!
Attached is data from a 16-channel comm format translator I’ve been working on.

It receives 1-mbit Manchester encoded HDLC data, decodes it using an HD6409 , Z85230, a dspic33EP running at 140mHz, and then processes the data. For this sample the SPI and Async serial out are the same data…

Channel map:
0 - Manchester encoded HDLC in
1 - data output from Manchester decoder
2 - /NVM (non-valid Manchester) from decoder
3 - RX data input to Z85230 comm chip
4 - RX clock input (from decoder) input to comm chip
5 - Sync pulse when opening/closing flag detected
6 - Error interrupt
7 - The decoder uses 2 identical ‘ping-pong’ buffers, This indicates which one is in use.
8 - Interrupt signal from comm chip to dspic
9 - Receive interrupt read fifo
10 - Receive ‘special condition’ interrupt (finish emptying fifo)
11 - End of Frame pulse
12 - SPI SCK
13 - SPI SDO
14 - SPI /CS
15 - Async serial , 921600-8-n-1

A couple things that I’ve notice would be nice:

1. the ability to capture a screen shot and save it within the program.
2. some way to 'minimize the right hand pane, other than starting a recording, to get a screenshot.
3. Functional Manchester and HDLC decoding…
4. When dealing with ‘framed’ data, some way to put the whole frame on one line instead of individual entries…i.e."Data, 3.598876374,0x01,0x00,0x014,0x013,0x00,0x00,0x87,0x98,{EOF}. Same with ASCII data…new line = CR or LF or both selection?

Keep up the improvements! It’s made a big difference troubleshooting this device.

Regards,
Jerry
jmusselman64@gmail.com

VL200.sal (3.6 MB)

[rei_vilo]

Please find the sample for the SPI Sharp memory display mentioned at the Logic 2.2.16 thread. The Terminal window remains empty.

Sharp128.sal (37.3 KB)

Note: the Chip Select signal is active HIGH!

[markgarrison]

Thanks @P.Jaquiery, feel free to send a google drive link here or via support - https://contact.saleae.com/hc/en-us/requests/new - just mention that it’s a sample for the software team and we’ll get it.

Python support for raw data access in analyzers is a big part of our plans, but it’s quite a ways out. There are a lot of challenges there, performance not the least of them. In the short term, it should be pretty easy to write a C++ analyzer that simply forwards edges into the new FrameV2 format, which can be consumed by python analyzers. Next week we’ll be working on the ability for a python high level analyzer (HLA) to receive data from multiple input analyzers.

Custom python measurements might be another good solution for looking at performance statistics. It won’t integrate with analyzers, and they can only be applied two a single channel at a time, but custom python measurements is an easy way to run some math on top of all the digital transitions over a span of time. We won’t be working on measurements again for a little while, since we have our work cut out for us just with analyzers though.

The more captures we can get the better! Especially if they contain complete transactions, for instance starting the recording before any initialization communication occurs.

Also any description of what we’re looking at would help.

[markgarrison]

Thanks @Jerry!

I’d like to try to get the manchester HDLC data decoding in our software.

Could you send any links to the protocol documentation?

I wrote our Manchester decoder, and it seems to be working properly at 1mbit/sec. However, I don’t know the rest of the details required to understand what’s there.

Also thanks for the feedback:

the ability to capture a screenshot and save it within the program.

Yup, we need to get to that. In the meantime, if you’re on windows 10, you can press Windows Key + Shift + S. Then drag to select a region of the screen to capture. You can then click the notification that appears to save the image, or just paste it into a document.

MacOS I think is command-shift-5, and has a nice easy to use UI.

some way to 'minimize the right hand pane, other than starting a recording, to get a screenshot.

press ‘n’ then ‘q’. Or, just click the icon for the panel that’s currently open to collapse it. All navigation shortcuts can be found in the shortcut help, on the main menu, or by pressing ‘?’ (shift+/) on your keyboard.

Functional Manchester and HDLC decoding…

I’d like to work on that next week. The main known flaw with the manchester analyzer is that it ignores long strings of all zeros or all ones, if the bit state never changes. This is because it’s not possible to differentiate between all zeros or all ones until a bit changes. However, adding a setting to the UI to treat unknown bits as zeros or ones should easily solve that.

I won’t be able to simply merge our Mancester analyzer with our HDLC analyzer, but I would like to try implementing basic HDLC decoding in python, on top of the Manchester analyzer.

When dealing with ‘framed’ data, some way to put the whole frame on one line instead of individual entries…i.e."Data, 3.598876374,0x01,0x00,0x014,0x013,0x00,0x00,0x87,0x98,{EOF}. Same with ASCII data…new line = CR or LF or both selection?

Are you talking about the terminal view or the search results table?

This is the sort of thing that will be very easy to reformat with a little bit of python. One of our example python high level analyzers, called “Text Messages” only does one thing - allows the user to configure the rules by which frames are combined into longer frames. A delimiter can be selected, and a timeout can also be selected to be used as a delimiter. It’s meant to be an example and could quickly be modified to suit one particular application.
That said, this is the sort of thing our software should be able to do out of the box, without custom code.

[Jerry]

Thanks, Mark…fast feedback!

I think I spoke to soon regarding the Manchester decoding. It does appear that is working in the current release, but I can’t use it because the data is also HDLC encoded.
The HDLC analyzer I need is bit synchronous…which is there, but there also needs to be an external clock selection…which the current analyzer doen’t have.

In the data I sent, the HDLC data is line D3 and the clock is line D4.
As you may know, HDLC has an opening and closing flag of 0x7E, and does 0-bit stuffing anytime there’s more than 5 1’s in a row. More than 7 ones is an abort.

Thanks for the screenshot info. I should have known that…I just don’t use it that much.
Also the ‘close sidebar’…I swear I looked through the keyboard commands and didn’t see it…

Jerry

[siddacious]

Here’s a directory with some captures from me debugging a driver for an ICM-20948:
https://drive.google.com/drive/folders/1rgd999NZfxXMLMr5YTBXSi-oQhFGflux

Datasheets for the ICM-20948 and the integrated magnetometer:

DS-000189-ICM-20948-v1.3.pdf

SMDSW.020-2OZ.pdf

and here’s a spreadsheet with the register map. I’m planning to turn this into a json file that I can load into the HLA I’m working on at the moment:

ICM-20948 Register Map

I worked on the CAN project over the weekend, but I got lost down a rabbit hole researching the higher level protocols so I don’t have any captures for now. I’ll share them when I do.

[Collin]

Here’s a little capture of the comm between a Tesla Model S battery module and the master board. As you might imagine, Tesla did not exactly provide a handy protocol specification document for this. So, the only references are open source projects. Luckily, I did write one of those: https://github.com/collin80/TeslaBMS

ModelS_BMS.sal (9.7 KB)

I haven’t taken the time to built a python HLA for this yet. If I remember correctly the various commands and responses are more or less static in length so it should be possible to write some sort of state machine that interprets the data into a higher level output.

The BMS uses an extremely odd bit rate so it’s kind of interesting from that perspective. The async serial decoder seems to be working well and results fill out the table properly.

[siddacious]

@markgarrison these captures(above) also have the terminal formatting quirk someone else mentioned where reads and writes sometimes don’t have newlines. It seems like there are only newlines after read transactions

[chrisbennet]

This is a RS485 protocol capture from this USB to Serial device [1].
capture0.sal (135.2 KB)

[1] https://www.serialcomm.com/datasheets/USB-485C.pdf

[rei_vilo]

Another decoded protocol with an empty terminal.

Here, I²C INA219 Current/Power Monitor and SSD1306 OLED Driver.

I²C with no terminal.sal (969.2 KB)

Since I²C worked for the previous example, is there a limit on the size of the trace?

I checked that Stream to Terminal was duly activated.

[KurtE]

Not sure how much this helps, I captured a Robotis Example sketch for one of their servo libraries, doing a scan through all of the possible Servo IDS, using both Dynamixel Protocol 1 and Protocol 2. I had it setup with some XL430-W… servos.

I setup using the Serial Analyzer at 1MBS. Also I show the results using my old Dynamixel protocol Analyzer (C++…) https://github.com/KurtE/SaleaeDynamixelAnalyzer

Dynamixel_scan.sal (20.5 KB)

[dstahlke]

Can’t wait for the high level analyzers! These would be especially useful for EEPROM, since it can be hard to see what’s going on with the low level decode. It’d be nice if these would allow easily extracting a firmware dump.

24LC32A serial (I2C) eeprom:
24LC32A.sal (36.2 KB)

ATSHA204A crypto chip, MCP4261 I2C digital potentiometer, MCP6S91 I2C programmable gain amplifier:
Multi-SPI.sal (78.4 KB)

[KurtE]

Again not sure how useful this will be.
But with the Teensy processors, I do spend a reasonable amount of time getting display libraries to work on the different boards, especially when a new Teensy is in beta and/or just shipped. Recently been doing a bunch with different displays for the newly released Teensy 4.1 https://www.pjrc.com/store/teensy41.html

Sorry for a plug of their products, but I do the same for these analyzers up on their forums

Any way here is a capture from a T4.1 (beta board) to an ILI9488 display, where I am testing out using a frame buffer that was created in the optional RAM (in this case this board has additional 8mb).

With some (many/most) displays, with SPI, there is another IO pin that is often used on the display DC (Data/Command), that would be interesting to have the SPI analyzer or an HLA capture.

Also note with the T4.x, when I am doing SPI operations, some outputs are a byte at a time, other times, it is a word and in this case others are 24 bits.

The example sketch is doing a continuous DMA screen update of the display, so once it does the initial stuff of telling the screen the area to update and that the last command of 2c (data)… it just continues to output lots of data to the screen 24 bits per pixel, when it gets to bottom of the screen it will start over at the start…

Note: I trimmed the capture down a lot to fit… Probably could reduce farther.

T41_ILI9488.zip (3.6 MB)