
Why USB sucks (2005) - rograndom
http://www.technozeal.com/topic2.html
======
codeulike
This seems odd to me, as a consumer I remember the days before USB was around,
and it _really_ sucked. Maybe USB is less lovely if you are a driver
developer, but thats because its pushing more work away from the consumer and
onto the driver developer. As a consumer, USB has been pretty awesome.

edit: I suppose you could argue that something much better than USB could have
been possible, but thats how it is with technology, the standard that takes
off isn't necessarily the best, its just one thats _good enough_ and gets
traction somehow.

~~~
Amadiro
Developing USB drivers is actually totally fantastically easy nowadays with
libusb(x). You can more-or-less just pretend your USB device is a server you
talk to through a socket. No need to even write a single line of kernel-code,
you can do it all in python in userland, if you so desire.

For many USB devices this is also a totally feasible thing to do, too, because
most USB devices that are not providing some standard interface that the
operating system takes care of (keyboard, mice, controllers, tablets, mass-
storage, ...) just provide some sort of service that typically only one
application would interact with, so just having the driver inside that
application that interacts with it works well.

------
michaelt

      the USB connectors have no locking mechanism. [...] users
      will scream in frustration when they realize their USB
      mouse has been inadvertently unplugged from the back of
      the computer because it wasn't locked into place.
    

Is this really a problem, except for high-vibration industrial applications?

I'd rather have USB than be fiddling around trying to reach thumbscrews on the
back of my computer in the dark under my desk.

~~~
vernie
I don't know about you, but I really crank on my mouse. If your shoulder isn't
moving you're not doing it right.

~~~
6d0debc071
Better for the cord to come out the back of the computer than the front of the
mouse.

Besides, even PS2 connectors will come out if you yank on them hard enough. I
can't remember owning a mouse with a locking cable ^^;

~~~
zokier
I've actually wondered why almost all mice and keyboard come with fixed cables
instead of mini/micro-b connector. I guess it saves couple of cents in part
costs.

~~~
PhasmaFelis
Why would I want my mouse/keyboard cable to be removable? It's completely
useless without it. The only possible effect is to make it easier to lose.

~~~
makomk
The cable tends to get damaged fairly easily.

~~~
XorNot
This has literally never happened to me in like, 10? years of USB use.

------
ISL
Grounding. That's why USB sucks. If you work with precision instrumentation,
USB introduces ground loops and forces unpleasant grounding configurations.

I've been looking for a USB 2.0 High-Speed (who came up with these names,
where Full Speed is slower than High Speed?) opto-isolator for years.
(Corning's new "3.Optical" cabling looks great, once it makes it to market)

HN have any pointers?

Edit: Looks like 3.Optical cables appeared for sale ten days ago!
[http://www.corning.com/news_center/news_releases/2014/201404...](http://www.corning.com/news_center/news_releases/2014/2014041501.aspx)
, [http://www.eaccu-tech.com/usb-3-0-optical-
cables/usb-3-optic...](http://www.eaccu-tech.com/usb-3-0-optical-
cables/usb-3-optical-cable-a-plug-to-a-receptacle-10-meter/)

Hm. They may be "for sale", but availability may be slim.

~~~
tlb
A USB over twisted-pair extender, like [1] works. They just look like an extra
hub to the USB stack.

[1] [http://www.digikey.com/product-
detail/en/B203-101/B203-101-N...](http://www.digikey.com/product-
detail/en/B203-101/B203-101-ND/4438264)

~~~
mindslight
I don't see any mention of isolation in that datasheet, nevermind an actual
voltage spec. Granted I haven't looked super hard, but any USB isolator I've
seen only ever does full speed. I recall seeing one _chip_ from ADI that was
meant for high speed USB isolation, but that's the closest I've come.

~~~
ISL
Ethernet is transformer-isolated [1]. If you just need to break a DC ground
loop, a CAT-5 connection will do it.

If you look at the Tripp-Lite's installation manual [2], you'll see that the
external power supply is connected to the remote unit.

[1] [http://electronics.stackexchange.com/questions/27756/why-
are...](http://electronics.stackexchange.com/questions/27756/why-are-ethernet-
rj45-sockets-magnetically-coupled)

[2] [http://www.tripplite.com/shared/techdoc/Owners-
Manual/933116...](http://www.tripplite.com/shared/techdoc/Owners-
Manual/933116.pdf)

~~~
mindslight
Yes, but RJ45 and cat5 don't necessarily imply Ethernet.. DC losses on their
own would be high enough to warrant that remote power supply.

~~~
ISL
Agreed. In the absence of a solution like the 30m 3.Optical, we're desperate
enough to try it. We have a working solution using daisy-chained repeaters
(for distance) landing in a powered hub, but it's hardly elegant. People make
nifty USB-->WiFi interconnects too, but the one we tried can't handle full-
bandwidth usage of USB 2.0.

It was a sad day when the opto-isolating ADI development board arrived and we
discovered, to our chagrin, that Full Speed != High Speed. We were so stoked
to have finally found it.

~~~
mindslight
Those terms ("high" vs "full") are especially tricky somehow. Perhaps that ADI
chip I mentioned was the same one, and they tricked me as well. At least I was
just researching to determine how bad I would want an Ethernet port if I got a
PC scope. (I determined the answer was "pretty bad")

I don't know why bona fide high-speed isolators are not a common thing. Maybe
12Mbit ends up being sufficient for 98% of cases? It seems like the only way
is to find a type of product for which they _can 't cheat_, like those optical
3.0 cables or an actual GigE->USB protocol converter.

Then again Tripp-Lite is a big name, and you really would want some isolation
for a 300ft run. Good luck!

~~~
mindslight
Answering my own question, I ran across an EEVblog post where someone pointed
out the problem is the bidirectional data line. OFC that's why you can't just
feed them into a GBIC etc. USB 3 has two unidirectional pairs, and so should
be easier to isolate.

However, don't get your hopes up for those 3.optical cables to do what you'd
like either. USB3 actually just implements 480/12/1.5 by having a parallel
USB2 bus the whole way. There is _no_ conversion between the two, which also
means you can't actually aggregate 480mbit devices with a USB3 hub the way
you'd hope. So who knows if Corning has actually created a full implementation
or also just punted.

~~~
ISL
Corning's specs state "Compatible with USB 3.0 and USB 2.0 devices __" , so
I'm still an optimist. We tried to get one early from them, and nearly did,
but ultimately couldn't. At $100, I'm sure we'll be trying it out when they're
available.

Our applications already function well without isolation [1,2], but I'd love
to know for certain that the last little bit of ADC noise we see is intrinsic
to our readout system and not a little bit of hash on ground.

[1] [http://arxiv.org/abs/1309.4828](http://arxiv.org/abs/1309.4828) [2]
[http://arxiv.org/abs/1401.4412](http://arxiv.org/abs/1401.4412)

~~~
cnvogel
Isolating mains-powered devices sometimes is tricky, for example in one device
of [1] we resorted to specially wound transformers with increased spacing to
minimize capacitive coupling to mains/ground, accepting the resulting higher
losses in the low-voltage power-supplies.

If you want to research if "ground loops" are indeed of concern, try to inject
them artificially (split up protective earth, feed in current from a function
generator) and check the influence on your measurement, then you can quantify
the "ground loop rejection ratio" of your setup. This will also tell you which
frequencies are most susceptible to disturbance in your specific setup.

In your paper, you seem to only have a CCD line camera taking the data, most
likely it will be easier to cut open the grounding here, mount it using
plastic screws and spacers, if not already done. {EDIT:} ...or not feasible
because of the heatsinking...

[1] [http://arxiv.org/abs/1302.6092](http://arxiv.org/abs/1302.6092)

~~~
ISL
Agreed, and we've tried that with other USB DAQ systems. The +5 rail is still
referenced to the inferior ground. You can split that guy out too, and bring
in external power; but then there's the question of the signal lines - to whom
are they referenced, and will they function reliably?

It's so much more satisfying to know that you have truly isolated connections
than to worry about whether you've gotten a complicated system laid out
correctly. I don't trust me to get the details right :).

(As you say, for cleaning up AC from the mains, isolation transformers are
fabulous.)

------
analog31
>>> I note that more than a few chip companies have created USB-to-serial
bridges (with accompanying drivers). This is a sure sign of USB's technical
failure. Which isn't to say that USB won't thrive.

Here's my thought about those chips. I do a lot of simple prototyping,
testing, data acquisition, and so forth. To these ends, I often build my own
little gadgets that combine some sort of microcontroller with some analog
electronics, etc. I wouldn't be insulted if you called me a hobbyist. Still,
the stuff that I make works, and solves problems.

There are "USB microcontrollers" that contain a built-in USB port. Then you
have to wade through each manufacturer's peculiar documentation, and hope that
their demo code does what you need, or prepare to roll your own on both the
embedded and desktop sides.

Or, you hook up a USB-to-serial bridge. There's nothing magic about serial,
except that it only robs you of two pins, and setting it up is 100x easier.
Also, the bridge chip runs independently, making it 100x easier to write real
time code on the microcontroller.

If I went to any other kind of interface, I'd use the same approach of a
"bridge" module plus a microcontroller. There are such modules for virtually
every conceivable interface.

I've had the pleasure of watching my gadgets work on multiple platforms with
no extra effort on my part. I think a platform needs to have at least one
"people's port" and the FTDI chip meets that need nicely.

~~~
cnvogel
Exactly! While some people claim that this robs USB of some of its strength,
surely having a 10 line cross platform python script control your ADC/blink
the LEDs is the ultimate deal breaker for USB2uart.

And even IF your micro comes with built in USB, it's just so convenient to
just let it emulate a cdc compliant serial port working everywhere out of the
box.

Libusb is almost as good on non-windows (which needs some pseudo driver to
allow the library to generically talk to the device)... but then one would
need a serial-terminal substitute to send packets off data to arbitrary
endpoints.

~~~
myrmidon
> Libusb is almost as good on non-windows (which needs some pseudo driver to
> allow the library to generically talk to the device)...

If it's _your_ USB-device, you can add a WCID descriptor [1], and use the
WinUSB/libusb API. No driver installation necessary post Vista (on XP you need
to manually install the WCID driver, but only once).

[1]: [https://github.com/pbatard/libwdi/wiki/WCID-
Devices](https://github.com/pbatard/libwdi/wiki/WCID-Devices)

------
brownbat
Some of the complaints hold true, others just sound bizarre now:

> But for the vast majority of devices, you had better have your driver disk
> handy

Driver disks... yeah, I think I remember those?

My biggest complaint with USB isn't there, the ports can be kind of fragile.
Even without regular swapping (which the design seems to encourage), USB
drives and cords slowly pry them out of position. Forget about the port if
anyone bumps the USB stick or trips over the cord while it's plugged in.

~~~
saganus
Even then, using USB devices WITH drivers beat the hell out of configuring IRQ
and DMAs. I remember the ordeal it was when you wanted to add or change
something and you had conflicting IRQs... pfff..

~~~
jdboyd
When PCI replaced ISA (which was prior to USB taking off), dealing with IRQs
and DMAs was a thing of the past, making that a poor reason to say USB is
superior.

~~~
saganus
Uhmm... I guess you are correct. I indeed remember going from PCI to ISA. Also
to AGP! oh my.. the speed of that thing. But I think the point still stands,
maybe not that much with that specific example, but how about PS/2 keyboard
and mice?

Woops... disconnected the mouse/kb by mistake? off you go rebooting the
computer. I think that does indeed make it a good reason to say USB is
superior.

------
Hydraulix989
[http://i.imgur.com/kYGTLjc.png](http://i.imgur.com/kYGTLjc.png)

~~~
hk__2
I never understood these jokes, I always put the USB key/cable in the good
position. 99% of times you can rely on the USB logo (which has to be at the
top).

~~~
spc476
I'm looking at a USB memory stick right now. On one side is the company name
(Kingston). The other side has the device name (DataTraveler). There is no USB
logo on the thing.

So, which way does it plug in? Oh, and the USB ports on the front of my
computer (tower) are vertical, nor horizontal.

~~~
mirkules
Ever tried reaching in the back of an iMac to plug in a USB drive? I have a
2011 iMac, and to this day I still have NO idea which way the slots are
oriented. I usually just give up, stand up, and angle the entire computer just
so I can plug it in.

------
Glyptodon
The vendor ID device ID issue is/was real. I think there was a story here a
while back about a manufacturer making it so hobbyists could use their ID or
something.

~~~
notthetup
There is a great talk by Ian from Dangerous Prototypes on this from the 2012
Open Hardware Summit.

[http://www.youtube.com/watch?v=1pegVYODsn4](http://www.youtube.com/watch?v=1pegVYODsn4)

------
foohbarbaz
From a developer standpoint. I could get a minimal output via a serial port
with a few lines of assembly on a bare hardware.

USB requires a lot more work and on Windows the API is atrocious. On Linux the
API (libusb) quite a bit nicer, but still a bit of work.

The plug and play part, device naming and unique identifiers are a special
"joy" of USB.

If serial port is sufficiently fast I'll take it any day over USB.

~~~
byuu
I was able to build a serial bridge between an SNES and a PC on a simple
breadboard with stock parts:
[http://i.imgur.com/sPKGvl.jpg](http://i.imgur.com/sPKGvl.jpg) (the output is
from a Teensy that is running as a USB<>serial device, so the PC sees it as
/dev/ttyUSB0 ... the input and passthru connect DB9 to the controller port on
the console, and the switch allows the original controller to work in place of
the comm board.)

The Teensy driver code was around 10KB, and the PC code that opens
/dev/ttyUSB0 was around 15KB.

Have been trying for over a year to implement a true USB version so that we
can take advantage of the full bandwidth capability of the system, which is
2.68MB/s, which only USB high speed can do, and it's been nothing but a
nightmare.

I will be really sad in the future when little toy projects like this are out
of the hands of hobbyists due to costs and complexity. We've already lost that
in the desktop operating system field, where video cards alone are more
complex and undocumented than entire OS kernels these days.

~~~
zokier
You mean connecting to the EXT port at the bottom of SNES? I didn't even know
that it had such thing. Sounds interesting, what are you trying to do?

~~~
byuu
Well, we are currently connecting to the controller port because it's really
easy to connect to those. But of course you can only hammer at those registers
at around 40KB/s.

So yeah, a friend made a PCB and found some female edge connectors we can cut
to size to connect to the EXT port, where we can DMA at 2.68MB/s through using
eight data lines. On the other side of the PCB, we just stuck a custom sized
28-pin IDE header. Easy to do whatever with that: wire to breadboard one-at-a-
time or with an IDE cable.

The hope would be to then have some device that monitors each clock rise, grab
the eight bits on the data bus, and send it to the PC. It can buffer a bit and
have _some_ latency, that's not a big deal.

But even with ICs that can latch the data quickly enough, we don't have enough
bandwidth over serial nor USB1 to send 2.68MB/s of data. It'll have to be
high-speed USB2, and will almost certainly need to be some kind of custom
driver, as I doubt you can do some kind of super baud-rate of 16,000,000+bps.

~~~
zokier
> It'll have to be high-speed USB2, and will almost certainly need to be some
> kind of custom driver, as I doubt you can do some kind of super baud-rate of
> 16,000,000+bps

The venerable FT232H claims "data transfer speeds up to 40Mbytes/s":

[http://www.ftdichip.com/Products/ICs/FT232H.htm](http://www.ftdichip.com/Products/ICs/FT232H.htm)

I'm not sure what is needed to actually accomplish such rates. Might be easier
to do it with USB-enabled MCU. Either way, I wouldn't discount the standard
USB classes too early. I'm "pretty sure" that you should be able to push some
tens of Mbps through USB-CDC class.

------
rbobby
Seems to have forgotten that before USB any strange/unique device required an
interface card. And resolving IRQ conflicts... what a giant pain. Oh and then
they changed the interface bus (ISA, EISA, MCA, VLB, PCI, etc) every few
years.

------
protomyth
Remembering the RS-232 ports and configuring for the devices speed, parity,
etc. makes me think I can overlook a lot of flaws in USB.

------
moron4hire
#1 is just the nature of cables. If you think blutooth is the answer, try
using blutooth for a while.

#2 is actually a really big deal with developing software to interact with
anything USB. Well, I should say anything based on the FTDI chipset. I don't
have any experience with anything else. Which is increasingly the case, given
the modern proliferation of hobbyest hardware projects. There are no
connection status events. RS-232 never developed any because a loss of
connection with a cable that is physically bolted into the computer should be
a catastrophic event.

Oh, I cannot tell you how many hours of my life I'll never get back debugging
connection status issues. And it doesn't necessarily have to be a physical
break in the connection that causes the problem. It could be an every so small
short in the connector that only triggers once in a blue moon when you shift
yourself in your seat and accidentally bump the wire with your chair handle
while also plugging in your headphones.

Luckily, the latest versions of Windows (don't look at me, clients don't seem
to care that they'd save a ton of money using Linux) are pretty robust to USB
connection cycles. It used to be, if you lost a connection before closing the
connection, you wouldn't be able to close the connection. The USB device would
get assigned to the same COM port, which you couldn't open, because you still
had it open. But couldn't close. Because you lost the connection. In the later
days of XP, it often led to having shutting down the program, recycling the
USB connection, and start the program again. In the _early_ days of XP, it
required a whole system reboot.

#3 I don't actually begrudge anymore. It's a situation that occurred due to
evolution. Regular B connectors are too big for small devices, so Mini-B was
developed to accomodate. But it turned out that the design was significantly
flawed, creating a board connector geometry that was not very robust against
repeated pluggings and unpluggings. Micro-B was developed to be significantly
stronger, to support a greater number of cycles (if you look closely, they
aren't just a different shape, the pins are set in the plug completely
differently). Then smartphones turned into micro-microcomputers and people
started to want to plug devices into them. Suddenly, what was strictly a slave
interface before, needed to have the option to become a master interface at
will. USB-OTG was the result, and it's actually a rather clever compromise
that maintains backwards compatibility well.

#4 can be a significant problem when doing any sort of real-time data
collection. It's nearly impossible to connect a variety of sensing devices to
a PC and be able to synchronize the readings of them in time. For the most
part, I take the system timestamp for everything, then generate a best-fit
curve and use _that_ for my calculations. There's just no confidence in the
precision of the time resolution in USB.

#5 isn't USB's fault, it's device manufacturers. Hardware developers are some
of the worst programmers in the world (and yes, they will say the same thing
about programmers and circuit design, but you don't see me designing circuits,
now do you?). Your printer has a really shitty system for installing drivers
because the driver developer can't be arsed to learn how the operating system
works with drivers. And he can't be arsed because his manager is probably
bugging him to "get back to real work".

His list of new problems are largely obviated by FTDI. However, FTDI has its
own problems, both technical and political.

~~~
Peaker
Micro-USB has been terrible, reliability wise. The ports survive pretty well,
but cables wear out at an unacceptable pace.

I buy stocks upon stocks of micro USB cables, and I've switched to wireless
charging, because I simply keep running out of them.

It's not simply me being reckless, my wife's cables wear out, as do my
brother's and various friends.

Also, none of us had any of these issues back with mini-USB (though admittedly
we used those cables much less than we use micro today).

~~~
jackalope
I agree. Micro USB was not an improvement over Mini USB. I've never had a Mini
USB cable go bad, but easily a third or more of Micro USB cables I've owned
are faulty, with barely any stress. Also, Mini USB cables were a huge
improvement over standard USB, because I could orient them by feel alone. I've
lost that ability with Micro USB, where it often takes three tries to plug it
in.

~~~
secabeen
That's all intentional. Mini USB cables were stronger than Mini USB ports. Its
generally better to make the weaker side of a connector the cheap easy-to-
replace cable.

------
SixSigma
The team that wrote the Plan9 Use code remarked "It's not Universal, it's not
Serial and it's not a Bus"

~~~
SixSigma
s/Use/USB/

------
autokad
i was plugging in a usb into the back of my computer and i saw a firewire
port. wow i forgot those existed, i remember they were all the rage and going
to replace usb

~~~
lttlrck
FireWire preceded USB by a couple of years.

