This is a RS485 protocol capture from this USB to Serial device [1].
capture0.sal (135.2 KB)
1 Like
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.
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)
1 Like
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)
1 Like
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)
2 Likes
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
1 Like
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)
1 Like
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.
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.
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.
1 Like
The fix has been released in 2.3.0! Thanks again for sending in that capture.
1 Like
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:
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.
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:
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
Hi @huffman!
nice to see I’ve stirred some interest with my HLA and captures.
I’m sorry to say, but I agree that the generator approach doesn’t seem to lead to an elegant solution in this case. That may be I’m not really a Python user and not familiar with yield, but deeply nested code is generally regarded as a code smell. I’d have thought at least the outermost loop could go away if you used “continue” instead of “break” in the first inner loop. 8 yealds scattered through the code doesn’t bode well for understanding either. 
My own HLA is a pretty mixed bag tailored very much for the hardware I’m working on at the moment. In particular, it ignores any TUSB422 registers that I’m not interested in, and decodes non-TUSB422 traffic for I/O expanders that are very project specific. I don’t think there would be any harm in it being in the public domain, but it may not be very useful to anyone else either.
Ha, in hindsight I’m not sure why I didn’t use continue, I can’t see a constraint requiring the nested while. Some of the nesting could have been alleviated by breaking out into other generators, but I hadn’t gotten to that point. In any case, I think it was a worthwhile exercise.
I still need to dig into yours soon! It’s definitely helpful to see HLAs and how other people are writing them.
Yup, worthwhile - I learned about yield.
My own coding style tends to state machines and dispatch tables. My HLA uses dispatch tables heavily, but the state machine component is rather subtle and mainly concerned with register read decoding.
My HLA deals with a lot of special cases to try and show “interesting” information, like which alert flags are newly set or reset, so there is a lot of code there. I’m still adding to it and altering stuff without too much pain so it seems to meet my maintenance goals. Not sure how that would hold for anyone else though!
Ideally with the generator case you would have one generator per state, which I believe Mark’s did. There’s a benefit there to keeping the relevant data for the current state within the current scope, but the awkwardness of using yield to both send and receive frames made it a bust in our opinion.
Looking forward to seeing how you setup all the flags! Are there any features that you think would have been helpful? For instance, we don’t have native support for bitfields, and if you break them out into separate data.* fields, it can create quite a few columns in the data table.
For now I’m most interested in the “bubble” text and I haven’t really explored the data table at all. I’m often comparing logging from the DUT as async serial data with the TUSB422 traffic. The logging tells me about the internal state of the system and something about timing, and the I2C traffic tells me what’s actually happening. There are a whole bunch of interacting state machines that are pretty much direct implementations of the state diagrams given in the “Universal Serial Bus Power Delivery Specification” so gaining insight into how those machines are interacting is fundamental to figuring out what the system is doing. I’m using the logic analyzer as a firmware debugging tool much more than I’m using it to debug the hardware at present.