Ask HN: Replacing USB3 with slim Power-over-Ethernet, too crazy?

1 points by andrewflnr ↗ HN
I'm not an expert in USB3 implementation details, but it seems to be a nightmare, even if you can afford to buy the spec. Meanwhile, power-over-ethernet has existed for a while. It seems like all we would need is slightly different connectors to fit into slim devices like phones, and PoE capable cables could fill the data-and-charging roles of USB3, with less weird proprietary nonsense, almost none except for the connector itself, which could conceivably (definitely in my fantasy world) be an open-source design. The software and most of the other hardware pretty much already exists, right? Connecting your phone to your computer is just networking, like plugging in an Ethernet adapter.

I'm sure it can't actually be as simple as just CADing up some new connectors, but is there a reason besides inertia this couldn't be done and be effective? Say, by a startup willing to abandon a bit of precedent to get a less-proprietary connector?

6 comments

[ 2.5 ms ] story [ 22.5 ms ] thread
Some counter-points:

ad-hoc networking (addressing, names, ...) is kind of a pain still, especially cross-platform.

Affordable Ethernet is slow compared to modern USB-standards.

For many things USB does there isn't one "that's the equivalent networking protocol".

Modern USB does a lot of alternate stuff over the same connector, which makes it a lot more complicated, but also useful.

All that means it seems unlikely for this to happen and a bigger hurdle than "abandaon a bit of precedent". Given computers already have Ethernet today: how many peripherals with USB do you see where there is just one Ethernet-based option somewhere on the market, and what does that cost in comparison? What's needed to adopt them?

To take some examples: we have storage devices with Ethernet. We have cameras with Ethernet. How do they fare with USB-based ones in your comparison?

I think the experience around ad-hoc networking is fixable and should be fixed. But yeah, harder than I hoped for sure. :)
Using ethernet for the data part will need new specifications because Ethernet defines so little. For example, right now, I can plug in any random USB keyboard or camera into my computer and it'd just work in under a second, no special drivers needed. With Ethernet, someone needs to define a spec -- I don't know of any standardized "input device over ethernet" protocols for example.

Additionally, ethernet transport is pretty basic -- for example, there are no specs for Ethernet hubs which provide "device present" signal, or which can forward "sleep mode" state to/from devices as USB does.

The power delivery part will need to be reworked. Plain standardized POE promises 15W, while USB3 can get up to 240W. Plus 48V is pretty high and needs high-voltage converters, which will be hard to do in portable devices.

The PHY will need to be updated -- the copper-based ones rely on transformers for safety, but those are pretty big and hard to fit into portable devices. Also, I am not sure how power-efficient Ethernet cards are, but I bet they draw more power than USB ones. All this error correction logic to support long distances cannot be free.

So it's not like Ethernet-based stack will have less "weird proprietary nonsense". Once you get it to provide feature parity to current USB, it would be as complex, if not more.

"Dumb" serial cables have been able to transport local and networked data for more than half a century. I don't think such a feat is that difficult to accomplish with Ethernet. I don't everything needs a protocol to "just work".
I know it may sound strange if you are used to modern consumer electronics, but in order to do anything with those "dumb" serial cables you definitely needed protocols. They never "just worked", it was up to the user to properly set up them up and the level of difficulty depended on the type of device. A lot of times this was non-trivial.

For mouse, the most common choices were Microsoft vs Logitech, and later there were the "scroll wheel" variants. Less common drivers also existed, especially for touch screen devices. Windows had the device discovery wizard which would try to discover the mouse by sending data specific for each mouse type and seeing if right response came back, but it only worked for the common protocols.

For networking, the most common choices were SLIP and PPP. If you were doing dial-up, you also had a modem driver to worry about, as well as a way to switch to "internet mode" (nether SLIP nor PPP had a way to ask for username/password for example.. so there was generally a "script" of some sort to authenticate)

For serial terminals, the basic text was easy, as long as you get your serial port speed and flow control right. But the moment you want something slightly advanced, like clearing the screen or having TUI (text-based user interface), you had to make sure you got terminal type (protocol) correct. Nowadays, it's most likely would be VT102, but in the past I have seen VT52 and Kermit. There were also BS key setting and codepage which needed to be set up separately in order for things to work.

For all other devices, there were basically no hope, unless you had a manufacturer-provided driver. For example, I own a serial printer, and it does not support sending any complex data back to the computer at all, all there is is a single "error" line. The PC has no chance to auto-detect the device at all. (Funny effect of this: if I were to connect it to the old Windows PC and run device discovery, it'd print some junk as Windows tries to probe it as mouse, modem etc.. )

Now some time after, PS/2 came out, and it had standard protocols for mice and keyboards -- which made it widely popular, as there was no need for manual configuration.

And finally when USB appeared, it supported many more "device classes", including things like network cards, video cameras, and joysticks; and other devices at least had a standard protocol to announce their type (VID:PID pair), so that OS could automatically pull up the right network driver.

Ah, those all sound like fair points. In retrospect I definitely underestimated the software effort required, even if I couldn't be expected to predict the EE issues.