USB LS and FS Analyzer been enhanced?

As was discussed a few times during the Logic 2 software beta cycle, including:

There are times when I try to use the Analyzer to capture, either protocol startups or data.

Today for example would like to capture an MTP file transfer to see if/when a USB data packet is either not sent or something wrong with one or more 64 byte data packet

Problem is with current analyzer there is so much other data, that I lose the tree in the forest.

What I have typically done in the past was to have to save report out to file, then use grep to find all of the lines that cantain data. I usually use the linux greap as to also capture the line before the data line.
Then I need to edit this file to remove a bunch of other stuff…

Would be nice to have a version of capture that does this for us.

Also were HLA hooks setup for this analyzer?

Thanks
Kurt

Hey Kurt, sorry for the trouble with that. Yeah, the USB analyzer can get pretty busy. Unfortunately, our USB analyzer is not supported by HLAs yet. Creating an HLA would have been a viable solution for this. The supported analyzers are listed below.

Can you give me an idea of what kind of data you typically search for? Allowing the ability to search a sequence of bytes could also be a step towards that direction (per the idea post we’re tracking below):

Apolgies we don’t have an immediate solution for this.

Thanks,

I showed an example back in I believe the 2nd posting of the thread:

Where I boiled down 1.9 million line output, to a few 100 lines of useful (to me) information.

That ended up looking something like:

|23.21607064|IN|0x02|0x18|0x48 0x20 0x53 0x00 0x4F 0x00 0x71 0x00 0xA1 0x11 0xC0 0x00 0x81 0x7C 0x81 0x7C 0x08 0x00 0x48 0x00 0x00 0xA0 0x7F 0xFC 0x0E 0x00 0x00 0x00 0x05 0x00 0x81 0x0A 0x7C 0x1E 0x1A 0x00 0x00 0x00 0x00 0x00 0x00 0x09 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00|
|23.21707062|IN|0x02|0x18|0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x00 0xC3 0x7D 0xE1 0x8C|
|23.21807067|IN|0x02|0x18|0x48 0x20 0x53 0x00 0x4F 0x00 0x71 0x00 0xA1 0x11 0xC0 0x00 0x81 0x7C 0x81 0x7C 0x08 0x00 0x4C 0x00 0x00 0xF7 0x80 0xFC 0x0E 0x00 0x00 0x00 0x05 0x00 0x69 0x0A 0x83 0x1E 0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x09 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x80 0x00 0x00 0x00 0x00|

Note: the copy and paste from the other thread sort of changed it slightly… But does show the point.

Sort of boiled down to In/out (which channel) how many bytes, and the data. Sometimes I leave the time stamp other times not.

Thanks again

Kurt

P.S. - Luckily yesterday was able to find where the messages were being lost to without resorting to this. But still would be great to have some solution for the next time

1 Like