CAN bus analyzer issue

I’m looking at CAN bus traffic with a Logic Pro 8 and Logic 2.2.10 software.

The CAN data is properly decoded in the signal window, but nothing is shown in the decoded protocols window so I can’t export anything to .txt/.csv, which is what I really need to be able to do at the moment. Data is streamed to the terminal view for CAN but the format makes it not terribly useful. I tried using the Async Serial analyzer and it does show data in the decoded protocols results table and export works. Is this something I can fix or is it on the roadmap to fix for CAN?

  1. You should be able to export CAN results to CSV
  2. We currently support Async Serial, SPI and I2C. We’ll support the rest of the analyzers in about a week.

When I export to a .txt I get an empty file. Thank you for the update!

Sorry about this! Pretty sure the problem is that we stubbed a few of the less commonly used functions in the C++ analyzer SDK, and forgot to go back and implement them once it was working. Unfortunately, I don’t have an ETA on when this will be fixed yet.

I just tested TXT/CSV export of CAN analyzer results in 2.3.0 and the files are still empty. Any time estimate for fixing this? Thanks.

In lieu of a working export, I tried copy & paste of the terminal output to a file but the format isn’t obvious to me. For example, here is one packet:

Standard CAN Identifier: '145'Control Field: '8' bytesData Field Byte: '128'Data Field Byte: !Data Field Byte: '135'Data Field Byte: '233'Data Field Byte: '242'Data Field Byte: '0'Data Field Byte: '0'Data Field Byte: 9CRC value: '27674'ACK

Why is the last data byte not enclosed in quotes? Is this format documented anywhere?

If it’s a printable character it’s printing the actual ASCII character and not the decimal value which is what you’re seeing in single quotes. IMHO that’s a really dumb way to present data. I sure hope that’s not the default, I don’t remember. NEVER should data output be done like that. Either keep it ascii, keep it decimal, or keep it hex. Mixing them is a sure recipe for mix ups. For reference 9 is 0x39 in ascii. So, the actual value there is 57.