Analyzer software is unusable when Link Under Test is Ubuntu 10.04 Linux. I haven't tested other Linux distributions but the main reason for this software is so that I can analyze data for Linux, Mac, and Windows. Windows and Mac work as expected. The Analyzer software becomes slow and unusable when testing my Linux system. The client is Windows Vista.

Please zip up the temp.usb file and email it to support at international test instruments dot com. We'll then take a look at what's in the trace.

The first usb file is only 3.5MB but the second with actual IN/OUT data is over 500MB after capturing for less than a minute. Is this an expected size? I had to max compress in order to get it to a size that I can email. The email is on its way, thank you for the quick response.

The first file you sent (temp.usb) contains complete garbage but the second (temp2.usb) contains valid information. Your setup appears to be incorrect since you are capturing lots of traffic to a device on a different cable segment connected to the upstream host controller. The host controller will send downstream packets to all ports/cables connected to the host controller, not only to the downstream cable your particular target device resides on. This is why you are not seeing upstream packets for devices 4 and 5. Device 15 resides downstream from the 1480A unit so you'll see both downstream and upstream packets.

Make sure no other devices are connected to the same host controller as your device under test to avoid extra/invalid data in the trace. If this is not possible, you can filter out the unwanted traffic by using the 'Filter Protocol Items' dialog. In this case (temp2.usb) enter 4,5 in the 'Device IDs' text box. What's left is a bunch of NAKed IN Transactions and the SOFs.

Linux appears not to use PING packets to find out when IN data is available but will rather instead do an IN Transaction every ms. This is what causes your trace to be some 590MB. A trace so large will take time to parse out so this is not a defect with the software but rather due to lots of NAKed IN Transactions.

The trace parsing can further be improved by checking the 'Hide NAKed IN Transactions" checkbox in the Filter Protocol Items dialog. Also check the 'Hide Start of Frame Packets' to reveal the interesting information in your trace. What remains is your device #15 connection and successfully ACKed IN /OUT Transactions containing 64 bytes. Please see below screen shot.

In short, you'll need lots of memory and disk space to parse out this file. We will look into whether we can optimize the parsing to speed things up.

I have a device responding nak on a flood of IN transactions. Because it are that many the protocol parser has problems parsing all these nak's. You can hide them but the parser still needs to parse them. It would be nice to have the posibility not to save these nak's to the resulting *.usb file...

Currently, there is no hardware filtering of packets. We will look into whether this can be added in a future version of the software. This is not trivial since it requires changes to both the FPGA logic as well as the application software that does not break the parsing logic of the software.

Thanks.