Why USB sucks (2005)
technozeal.com
technozeal.com
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.
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.
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.
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.
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 ^^;
I think I have more RJ45 cables with broken tabs than ones with the tabs intact. And trying to keep RJ45 in place without the tab is hopeless.
Surely you could build some sort of retaining clip for a usb cable is you had to?
That in turn is hard to qualify and expensive to assemble so it adds cost all round.
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.eaccu-tech.com/usb-3-0-optical-cables/usb-3-optic...
Hm. They may be "for sale", but availability may be slim.
[1] http://www.digikey.com/product-detail/en/B203-101/B203-101-N...
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...
[2] http://www.tripplite.com/shared/techdoc/Owners-Manual/933116...
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.
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!
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.
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 [2] http://arxiv.org/abs/1401.4412
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...
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.)
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.
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.
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).
> 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.
So it's automatic, and it's "plug and play" in a sense, but it's just papering over the "driver disk" problem, not really solving it (i.e., eliminating the need for the custom driver).
And if the company that made the device doesn't feel like updating their drivers... well, you're SOL, probably. Buy a new scanner.
That's kind of an absurd situation. Yes, using USB is a little smoother than it used to be, but why is this the best we can do?
But compare to linux. On windows, the first time you plug a particular model of usb device into a particular port, it takes 20 seconds to "install the driver" (and then it's almost instantaneous on future plugs of the same device into the same port). On linux, it's almost instantaneous, the first time and every time. New device, different port, still instantaneous.
It doesn't really make sense why it would take longer the first time, or need to happen again when plugged into a different port. silly windows...
This, most of all! As a non-driver-developer, this seems completely insane.
http://blogs.msdn.com/b/oldnewthing/archive/2004/11/10/25504...
Of course, autoplay has its own obvious drawbacks.
"Windows Vista with SP1 installs almost 1GB of drivers on the system to support plug and play of devices"
Iirc there was a follow up on how much they removed of this for win 7 but I can't find it now.
The IBM PC looked remarkably primitive in comparison.
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.
Motorola 68K and specialized high quality embedded units? (like amiga): no it will be overprices compared to the cough future price of an evolutive PC. Which final form are below average quality and overpriced embedded devices.
Had you followed the way of the old wise and chosen motorola architecture, you would not have theses problems. :)
I have two Kindle Fires with broken micro USB ports and I've seen two LEGO NXT robotics controllers break USB B ports. Even with DB-9 connectors soldered to boards, I don't remember a lot of breakage. I think it's because those were almost always through-hole and so much today is just surface-mount so it's relying on the pads staying adhered to the board to physically hold a frequently plugged/unplugged port in place. Crazy.
Externally symmetric yet internally asymmetric connectors demonstrate a fundamental incompetence of their designers. It baffles me that multiple people must have approved the USB connector design and we still ended up with the abomination that lives on 'til now.
So, which way does it plug in? Oh, and the USB ports on the front of my computer (tower) are vertical, nor horizontal.
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.
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.
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.
The venerable FT232H claims "data transfer speeds up to 40Mbytes/s":
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.
#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.
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).
When you say the cable wears out, do you mean the plastic-encased wire wears out, the male connector wears out, or the point where the male connector is joined to the wire wears out?
What I have experienced are the connectors on the cable either breaking or ripping off of the cable. This has happened twice with a device I use regularly, with no damage whatsoever to the port.
I don't do high speed data collection per se, and wouldn't know how to do it on a desktop platform even if the issue of synchronizing the ports were licked. So I shove real time functions to an outboard micro that does run in real time.
FTDI has been the best thing since sliced bread for me. It has proven to be remarkably robust and portable in my use.
This is more of a Virtual Serial Port driver issue than an USB issue, right? USB itself always seems pretty good about connect/disconnect events (at least on Linux). However, the FTDI drivers which detect this don't have any way to pass it back to devices reading the COM port (because of RS-232 legacy, as you said).
However, for real USB devices (not FTDI/VCOM), connection event notifications shouldn't really be an issue. Yes, annoying to deal with, but at least you can detect it, unlike with serial...