Saleae team - we would love samples of protocol captures!

[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)

[P.Jaquiery]

Sample capture for the software team:

System startup capture file with two I2C channels on different systems each with a HLA analyser decoding TUSB422 traffic and traffic to a MCP23017 I/O expander. There are also two active async serial 912600 baud serial streams giving system status information for the two systems.

One system is a data acquisition system using USB 2 full speed over USB-C with Power Delivery to negotiate 5V at 10W. The other system is in essence a four port 100W per port USB-C hub with a little extra proprietary magic.

The capture shows the cable connect through to completion of power and proprietary alternate mode negotiation over USB-C PD.

Note that the CC2 line actually shows the Manchester encoded PD communication between the devices.

Cheers,
Peter

[KurtE]

Again not sure how interesting this one is. It is a simple capture of communications from Teensy4.1 to a set of Lynxmotion Smart Servos (LSS). In this case working on translating the code from other servos (Dynamixels) to their smart servos. More information on their servos are up at:

https://www.robotshop.com/info/wiki/lynxmotion/view/lynxmotion-smart-servo/

Their servos run using a Full duplex Serial (+5v signals). My Teensy board has TTL level shifters to convert to 5v…

The channel 1 is the TX pin and commands start with # and end with \r

If the command is a query, like is shown in screen show asking Servo 8 for it’s Angular Range:
#8QAR0\r
and In this case Servo 8 responds on Line 0 with the: *8QAR1800\r
which says range is 180 degrees in 10ths of a degree.

I already mentioned in another posting would be nice if terminal mode would handle just have \r as line ending. Not sure if a HAL would work with combining data from both Serial lines.

Edit: Oops forgot to upload the SAL file
LSS_Servos.sal (21.0 KB)

[rani]

Can’t wait for the high level analyzers!

The high-level analyzers are live for quite a while
You can check out our docs here. Please let us know if you need some help with getting started

p.s.
We’ll update the API and improve the docs next week.

[markgarrison]

Thanks @rei_vilo, I’ve been able to reproduce this with your capture on MacOS but not Windows. Quite an odd problem, we should be able to get it fixed soon, should be on our next bug fixing day.

[markgarrison]

Ok, Finally figured out the bug where for some captures, some protocol analyzers would not produce terminal output.

The problem affects MacOS (and probably Linux, will test soon). Basically the front end does not get any terminal data if the back end writes too many bytes to the terminal’s named pipe at once. Not sure why, but it appears to be a problem with the front end named pipe support, because reading works fine from the terminal.

Looks like we have a working fix and it should be in the next release.

[rei_vilo]

@markgarrison Congratulations for identifying the bug, and good luck with fixing it now!

[markgarrison]

The fix has been released in 2.3.0! Thanks again for sending in that capture.

[markgarrison]

Thanks again everyone for submitting sample captures!

8 people submitted captures, and we ended up with samples of I2C, Serial, SPI, and manchester data, with over 15 different devices / protocols.

We’ve been working on 4 different specific extensions to start with - the AK09916 and HDC2080 I2C sensors, the TUSB422 I2C USB Type-C Power Control IC, and the USB PD (BMC) signal.

I’ve been working on the USB PD HLA (Biphase Mark Code), and just published to the marketplace. You can find the source here too: https://github.com/saleae/hla-usb-pd.

In addition to missing most vendor data object decoding and all extended header & data block decoding, it does support quite a lot - all the basics, plus it decodes data objects for all other data types. (source capabilities, sink capabilities, etc).

But there is a big caveat. To use it, you need to find a way to reliably record the USB Type-C CC pin using a digital input. The analog recording I got from @P.Jaquiery would have required a threshold of 0.4 volts to decode properly, which our device does not support. This would likely require the user to record using a digital comparator first. Eventually, we’ll want to add analog to digital conversion in our application to support this. In the meantime, I exported the analog channel, and modified our software’s digital simulation code to read a modified version of the export, to get the data back into the SW as digital.

The github post includes a digital clipping of @P.Jaquiery’s sample capture to demonstration purposes.

Samples:

[P.Jaquiery]

Great work @markgarrison!

When I was first working with the TUSB422 and USB-C PD I found that I could get pretty reliable detection of the data across the CC line using the 1.2V detector (I guess that’s about 0.6V threshold). Using that technique and the Manchester decoding I hand decoded a few packets as a sanity check of what I was seeing on a USB-C PD analyser and because the analyser we are using doesn’t decode some of the cable VDM VDOs. It’s not something I’d want to do a lot of!

A software analyzer that can accept analog data as input could be a solution to the detection problem using a fairly simple threshold detector with a little hysteresis. That would be a cool tool because it could be used for all sorts of non-standard logic levels and simple event detection.

[huffman]

Hi @P.Jaquiery!

You have a more complete TUSB422 HLA, but we’ve been spending more time building HLAs internally so I took a shot at building one for TUSB422 as well. It doesn’t do any bitfield decoding, but does decode the individual i2c subadresses. You can see it here:

saleae/extension-tusb422-usb-typec-pd

Of particular note we were trying different methods of implementing the decoding - this implementation uses a generator function that consumes individual frames and maintains state using local variables. Overall it was a worthwhile exercise, but I think the approach itself was not as straightforward as hoped, and the result is not easy to read (IMO).

I’m sure I’ll circle back at some point and look at the bitfields, but just wanted to share! Thanks for sharing your capture!

Ryan