[Noisebridge-discuss] cheap USB Analyzer, or signal integrity tools?

[Michael Prados]

> I use a USB to Ethernet extender on one side, have an Overo's host
> mode port on the other side, and sniff the packets.  Worked fine for
> the simple device I had to figure out how to talk to.

That's an interesting approach.  Do you mean that you have
USB->ethernet->USB, which allows USB packets to be transmitted
essentially unimpeded, but allows you to sniff the ethernet packets
without affecting the through traffic? The Overo is a Gumstix board
acting as an ethernet->USB converter?  Not quite sure I understand how
this fits together, but it sounds like you efficiently used some
components you had readily available to address this problem.  Care to
fill in some details?  I fear part of the issue is that I'm only
peripherally familiar with Gumstix.

-mike


On Mon, Nov 8, 2010 at 10:08 AM, Dr. Jesus <j at hug.gs> wrote:
> On Sun, Nov 7, 2010 at 7:19 PM, Michael Prados <mprados at gmail.com> wrote:
>> Hi All,
>>
>> This has been a topic of increasing interest to me, as USB becomes
>> less of an optional luxury in hardware hacking and more of a
>> necessity, and it's come up again lately in the context of Adafruit's
>> bounty for the Kinect:
>>
>> http://www.adafruit.com/blog/2010/11/05/our-kinect-arrived-today-you-gonna-get-modified/
>>
>> So many devices that I care to use or build have a USB interface, and
>> there are a lot of tools out there for embedded device developers to
>> add this functionality.  That is all well and good when it just works,
>> but frequently the reality is less than ideal.  Here's some scenarios
>> I've had to deal with:
>>
>> * the interface for a USB device is not, or not fully, documented
>> * the interface for a USB device is nominally documented, but doesn't
>> perform exactly as the documentation suggests
>> * environmental noise, connector, or transmission line issues lead to
>> signal integrity problems (not to mention PCB design issues!)
>> * you make a working system, set it up somewhere where it is difficult
>> to maintain, and the USB subsystem stops working. How can you diagnose
>> it remotely, or outside of the lab?
>>
>> Traditionally, for signal integrity issues- essentially physical layer
>> issues, you need a high-bandwidth oscilloscope.  I feel like it is not
>> unreasonable for a hacker to get a hold of a 100 MHz scope, which
>> might suffice for Full Speed USB, but for High Speed USB at 480
>> Mbits/sec, you need a scope at up around 2 GHz or above.  Even a used
>> scope in this range typically runs $5k and up.  And heaven forbid you
>> need to debug a problem outside of the lab- are you going to strap
>> your nice scope to the top of a car, or a helium balloon?
>>
>> What I really fantasize about for the physical layer is a
>> self-diagnosing USB hub.  Imagine if your hub could provide even a
>> rough estimate of the eye size.  Has anyone encountered anything like
>> this?
>>
>> So far as the data layer, this is where the USB Analyzer typically
>> comes in.  It seems to cost about the same as the multi-GHz scopes.
>> For this, it really seems like something running on Linux, perhaps
>> with special hardware, could do the trick.  Anyone encounter something
>> like this?  I've used Windows based USB monitor software before, but
>> I've found this kind of limiting, especially if you can't run this
>> software on the host device.
>>
>> All too frequently, I end up resorting to RS-232 or RS-485 when I have
>> the choice.  This may still be right decision, even in 2010, but I
>> hate to be forced into it by the inaccessibility of good USB debug
>> tools.  Seems like a major barrier to hardware hacking, which is only
>> going to get worse if a next generation technology such as USB 3.0 or
>> Light Peak gains in popularity.
>>
>> Any one have some good solutions to these problems?  I'll probably
>> post elsewhere too, but I figured on giving it a try here first.
>
> I use a USB to Ethernet extender on one side, have an Overo's host
> mode port on the other side, and sniff the packets.  Worked fine for
> the simple device I had to figure out how to talk to.
>



-- 
[REMOVE THIS TEXT BEFORE SENDING AN EMAIL!]