I worked on the design of wireless USB chips around 2008 - 2010. They worked - you really could get USB 2.0 full rate connections wirelessly and we had some neat demos.
I would say the major problem it had with adoption was that wired USB also provided power. (A lot more people use usb to charge their phone than to sync their phone.)
So great - wireless connectivity... but you still have to plug the device into a cable at some point (or have replaceable batteries), which makes the value proposition a lot less clear.
Beyond that it suffered from the usual adoption chicken-and-egg problem. Laptop manufacturers didn't want to add it because it was an expense that didn't drive sales since there weren't any must-have peripherals that used it, and peripheral manufacturers didn't want to make wireless usb devices since they couldn't be used with a standard laptop (at least not without a WUSB dongle - which raised the cost).
Bluetooth had some early success in cellphones, mostly to support Bluetooth headsets and car radio integration, starting from about 1999. It could do other things, but the wireless headset was the killer app in its early days.
Bluetooth didn’t really hit mainstream until the arrival of chipsets that multiplexed Bluetooth and WiFi on the same radio+antenna. My memory is that happened sometime around 2007-2010.
At that point, the BOM cost to add Bluetooth to a laptop or smart device became essentially zero, why not include it? Modern smartphones with both Bluetooth and Wifi arrived at around the same time (I suspect these combo chipsets were originally developed for handheld devices, and laptops benefited)
And once Bluetooth was mainstream, we saw a steady rise in devices using Bluetooth.
WUSB operates on a completely different set of frequencies and technology and couldn’t share hardware with WiFi. Maybe it could have taken off if there was a killer app, but there never was.
> the wireless headset was the killer app in its early days
Don't forget music piracy.
At least over here, a lot of kids had phones that did Bluetooth, and the primary use case for it was sharing songs they liked with each other. You could use infrared (IRDA) for that, and some people did before Bluetooth was common, but it was much slower.
This was mostly on low-end Nokias, maybe with a bit of Sony Ericsson thrown into the mix. They definitely did not have WiFi, in fact, Nokia even tried to limit internet over Bluetooth for usual carrier monopoly reasons as far as I'm aware, but Bluetooth was definitely there.
For many here, the iPhone not doing file and ringtone sharing over Bluetooth was one of its main limitations, at least early on. It was a social network in its own way, and having a device that couldn't participate in it was no fun.
Wow this unlocked a bunch of memories from middle school where we would send each other the latest songs and games via bluetooth. I remember pirating games for my sony ericsson and sharing them with my friends and we would play these games in class. You could just share and install the .jar files. Good times
By "early days", I was more thinking about the 1999-2005 era, before low-end Nokias even got Bluetooth and the ability to play MP3s.
The wireless headset was the killer app that drove bluetooth adoption within cellphones, driving down costs until eventually the lower-end models receiving it too. While sharing files was possible in the 1999-2005 era (especially with PDAs), most phones were lacking enough flash storage to store anything worthwhile.
While I don't want to say file sharing wasn't a killer app, it does seem to have been limited to just schools during a certain time period.
A time period that I missed out on by a few years. At high school, we did all our file sharing by swapping burned CDs. Then we switched to dragging around laptops and USB hard drives at university (and using the private emule network on the university wired ethernet).
At this point, the decision to add Bluetooth or not is literally just a product decision. If you don't want Bluetooth in your product, you actively have to disable the Bluetooth part of your WiFi chip, because you can't really get a WiFi chip without Bluetooth.
> the wireless headset was the killer app [for Bluetooth] in its early days
But the wireless headset is now a horrifying millstone making Bluetooth look like the world's stupidest trash fire. If you enable your microphone, you lose all audio from anything that doesn't want to use the microphone as the headset switches into "headset" mode and drops anything that wants to use "headphones" mode. There is no reason for there to even be two different modes.
Back when Bluetooth was new, the alternative for wirelessly sharing data between mobile devices like phones was infrared.
IR was exceptionally slow, required line-of-sight and even at the time, felt like a shitty solution. So even though the early implementations of Bluetooth also left a lot to be desired (battery hungry, insecure, and also slow), it was still a massive improvement on what came before.
Wireless USB wasn’t a significant enough improvement to Bluetooth given that BT was already ubiquitous by that point, but also cheap and (by that point) battery efficient now too.
IR with palm devices was super nice - just point to the other device and send, then confirm on the other. No persistent pairing bullshit & you could also use it to control TVs.
That’s how BT originally worked too but it got abused (I touched on this in my original comment when I said BT was insecure). The paring is a security measure to protect people from abuse.
Back when BT was new, I used to get all sorts of random shit pushed onto my phone every Friday night on the drunk train home from London.
I guess that was a lot less of a problem with IRDA as it required line-of-sight, which limited the abuse potential significantly.
Some devices would even establish an IRDA connection automatically as soon as they found anything. I have friends whose laptop names have suddenly appeared on lecture room projectors, as their laptop's IRDA receiver was in direct line of sight of that of the teacher's.
Not that you couldn't do that with Bluetooth, some early BT chipsets gave you a "<device name> wants to connect to you" dialog box any time somebody tried sending something to your device. This could be abused, to great student amusement, to display funny messages on that same projector if the lecturer's laptop had such a chipset.
It was harder to extract a clean signal due to ambient environmental conditions.
You could probably solve those issues with modern tech though. Things have advanced significantly since IR was popular. For example, back then Bluetooth was slow too.
I'm frankly baffled at all these reports of IR being unreliable and slow. It... wasn't. Not for the file sizes of the day. I exchanged plenty of files back in the day, even at 115200bps a picture would be 2-3 seconds tops (pictures were small!). And when devices started supporting 4Mbps, even a large-ish MP3 would go in 5-6 seconds. All without setup or pairing, beautiful. Huge files (like full resolution pictures from an SLR camera) would take a while - but frankly they took almost the same time with a cable! You'd just have to plug their memory card directly into your computer if you were in a hurry.
The only really clunky use case for me was internet access - keeping phone and laptop positioned and aligned for 30 minutes was limiting.
And yes there IS plenty of bandwidth at those frequencies. In fact latest IR standards reach 1Gbps, but it's pretty much extinct. There was an attempt called Li-Fi to use it for as a wireless networking but I don't think it went far.
What I really miss is OBEX (Object Exchange), which worked also over Bluetooth, and which Apple sadly chose not to implement: simplest protocol to just ship a file or a contact vCard over, no setup, just worked - and it's been a standard for 20+ years. Early Android had it too, it was since dropped I think. Sigh.
You’re either misremembering things or talking about an era after Bluetooth had already taken off.
In the days before Bluetooth, transferring MP3s over IR took multiple minutes, even on high end (for the time) handsets.
And the fact that you needed to keep line of sight during the whole process meant your phone couldn’t be used that whole time. Which was a real pain in the arse if you got a text message or phone call while trying to transfer a file.
IR was really more designed for swapping contacts. In fact that’s exactly how BlackBerry (or was it Palm?) marketed IR on their device: a convenient way to swap contact details. But you’re talking about a few KB vs several MBs for an MP3.
The tech has definitely moved on since. But then so has Bluetooth, WiFi and GSM et al too.
These days, professional optical equipment, aka expensive lasers+supporting hardware, can do 10-Gbit over multiple kilometers through the air, so you're right that optical transmission through the air should be able to support higher data rates.
The problem with Irda is that it's old. Technology has significantly advanced since the 90's, when Irda was popular on cellphones, so a modern implementation could do better data rates even accounting for the significant interference from the environment. We barely had wifi back then, and now it'll do a few hundred megabytes per second without breaking a sweat (your ISP might though). All the technology required to do that didn't exist in the 90's. We have Bluetooth now though,
so there's that same bootstrapping problem, where you'd just use Bluetooth, and not spend a bunch of money building a system very few people are asking for, so then there's little demand for a modern high performance Irda system in any devices.
Bluetooth took off before wireless usb did and was allready useful to people when wusb came a long. It was also lower power so you could do peripherals that was smaller and longer lived.
Introducing a new wireless protocol is incredibly difficult. You basically have to have all the countries in the world to give you a chunk of their spectrum.
You have 2 mainstream protocols now, one for low energy, slow data transfers (Bluetooth) and one for fast, but more power hungry devices.
I assume this is the same "problem". Most people (not the HN cohort) don't want to transfer "files", the abstraction of the file is either outdated for them or maybe even unnatural / unknown (younger generation).
They might want to transfer (a better word: share) photos/videos, documents, etc. And for those they use specific apps and "the cloud". No "files" (for the sake of files), and barely any hierarchy of (folders etc).
As long as the entity they want to share magically shows up on the another device or at the other person they want to share with, they are happy. They just skip two levels of abstraction ("this photo is a FILE and I will use USB to transfer it"). Maybe a far fetched analogy but this is why most of the drivers of an automatic don't really think about clutches and how the torque of the engine's output is converted.
At least this is my perception (outside the IT bubble)
Because we can't transfer easily transfer files between devices remotely, we had to get used to do it via apps. And so we didn't developed good, local files browsers (esp. for media) and companies invested in the cloud UI mostly because they could sell the storage and sharing capabilities. That was all unnecessary but we're used to that now to a point where sharing files is weird.
As a power user happily syncthinging all my files between all my devices, I'm sad because files is the easiest thing to share, organize, transfer, etc. I wish iOS supported this kind apps (full storage access!) as we could avoid the many, crazy, Alps specific workarounds just to share some stupid files.
And don't confuse the file itself (say, a pirated movie), the metadata (IMDb IDs) and the apps UI (Kodi!). Files is what we have, we should share files and let anyone pick the browser/apl they like for viewing, organizing…)
Don't get me wrong, I'm totally happy woth files. In fact, I'm sometimes a bit annoyed when certain apps' entities don't map to files either accidentally or to maintain the walled garden on purpose (I'm looking at you Google Photos, and the very cumbersome rclone connector to it).
On the other hand, I don't mind that full storage access is a "pain"; I don't even remember which apps I gave the permission to, and I would certainly be angry if my syncthinged files would be stolen by other app that went vicious.
All that said, as people don't think about their documents/photos/any other stuff in their homes as "filed items in folders", non-tech people also don't think about their digital items as such. And maybe this is alright, if the "file-ification" would have been so successful, better products would have emerged.
I think I disagree with that. This "people don't want files, they want to share photos", to me, is what product people want to believe. The whole thing has been enforced on users and is self-reinforcing: of course if you don't show files to users, they will not know what a file is.
Sure, I may be in a photo gallery and I may want to share a few photos with a friend who may want those photos to be treated as photos (instead of going into a big "Downloads/" folder). But it doesn't mean, at all, that the concept of file has to disappear to the user. In fact the files still very much do exist on the system. Product people just assume users are stupid, IMHO.
And the thing is: this abstraction (not knowing what a file is) doesn't make it faster or more efficient. It just makes the user more dependent on their platform and apps. Look at backups: product people at Google/Apple will tell you "people don't want to backup their files, they want to pay us to make sure that they never lose an image". Conveniently, it means that people are 1) forced to pay them and 2) don't have control over their own files.
Maybe GenZ/alpha now are stuck with these abstractions because they never learned what a file was (for no reason other than being abused by product decisions), but older generations grew up with physical media. "I have a piece of paper, I have a book, I have a CD-ROM, and those are all different kinds of files that can go into different "boxes" that are called folders".
Files and folders are very natural. The reason people don't know about them is because we hide them and force them to pay for literally subpar experience.
One of my great hate pet peeves with all smartphone and cloud apps is the "abstraction" and reliance on search. For me folders is quicker and less error prone, and as a bonus it saves on unneeded bandwidth (to load previews) and computing costs.
Also stop telling me I must use your one off "feature set" of sorting and ordering which either nobody uses or copies differently. The amount of square wheels (for me I must add, ymmv) reinvented is astonishing.
Folders as an abstraction don't really make sense beyond documents, though.
If your music is stored in a folder hierarchy, and can, in principle, be located anywhere, how do you index it to provide a library view? How do you distinguish it from random audio files that just happen to be ID3 tagged, but which you don't want as part of your permanent music collection? How do you efficiently react to deletion events? What happens if you delete an entire artist's worth of music from your music app? Should it delete the files, or only the library entries? If it deletes files, what if (some of) that music was in a folder that didn't contain any other files? Should that folder be gone too, or should you be left with an empty folder or hierarchy? What if the folder also contained a .nfo, is it good UX if it deletes the music and just leaves the .nfo?
If the only tool you have is a computer, everything is a file. If you're a music lover and not a computer enthusiast, you tend to think about albums, artists and playlists, and that's how you want to view your music collection.
Also, they want to use the same "abstraction" for "sharing photos with their friend when they're on holiday in another country" versus "sharing photos with that same friend when they just got back and are literally sitting next to each other."
People don't really internalize that those are two different use cases.
Yes there's Airdrop, but I think most people view it as more of a "discoverability" solution than a file sharing solution. If you met somebody you don't have a number for, "okay just Airdrop this to me" is much easier than doing the whole song and dance of adding them to contacts and sending them an iMessage or finding them on Whats App. Whether the actual file transfer part of Airdrop goes over the internet or over Bluetooth isn't something most people care about, as long as it can discover nearby devices and initiate a transfer to them, it's good enough.
I disagree. I find it condescending when techies say "the average user doesn't make the difference between sharing a file to a device next to them and sharing a file over the Internet".
Everybody, and I mean everybody is capable to understand that to connect their Bluetooth headset to their phone, they do it over Bluetooth. And that to connect to the Internet, they can either go over WiFi (which is "free") or cellular (which is less "free").
> People don't really internalize that those are two different use cases.
We actively keep them ignorant, and then we use their ignorance as a justification. I find it sad.
What if we said "People don't want to drive their car somewhere, they want to go from A to B. We should prevent them from learning how to drive so that they would have to pay for our taxis".
I don't get that. How do you expect to abandon the file layer on your OS? Do you plan on rewriting Windows, macOS, Linux, Android and iOS with a fundamentally new philosophy?
If not, then you're not abandoning the file layer at all. You're just preventing people from benefitting from it.
The file API might not, but all major filesystems implemented some kind off Metadata attributes, IIRC Microsoft was wanting to heavily rely on that for "user space" stuff (e.g. Users leveraging it for semantic information about their files)
Bluetooth FTP was widely supported until ~2009. All Nokia phones and many flip phones had it. iPhone did not, AOSP technically did, but carrier phones often had it disabled, and it slowly disappeared.
Windows 11 still supports it, I think macOS too. Pairing is technically optional.
But that doesn't need new peripherals, I could do that in my home WLAN network if they'd just install standard software for it on the phone (which you can fix by installing it from F-Droid etc.)
There's no formal standard, but I keep seeing this complaint from people who just haven't installed syncthing. At this point it's not inexistence but mere ignorance
This is an UX problem, not a technical problem. You could easily use Wifi to transfer files between devices quite fast, there's just no agreed upon open protocol for it. Afaik that's how AirDrop works.
Airdrop works. Ok, it's platform bound, but I'm sure it could be ported.
It's not such a big thing, though. I hardly use it, and young people don't seem to use it either. The stuff on their phone and laptop seem separate worlds, just like mine are. Might be because they don't know about it, though.
Because we keep them ignorant. We make sure they depend on our apps that they have to pay for. You wouldn't want them to know how to download music/movies without going through our paid streaming platforms, would you?
Hell, copy and paste works between iphone and MacOS if you've got the same icloud logged into both. Airplay is too cumbersome has been supplanted by long hold -> copy; ctrl-v, and the reverse. Works for images as well.
How does it not solve the problem? The data shows up on the other end. The fact that you don't agree with the implementation is a different thing, but it does solve the case.
For small files maybe. As shocking as it may seem, most Dropbox users just have the free version, with very limited space. Same for Google Drive or One Drive.
Dropbox is unavailable to huge populations. also sharing private bits with a cloud service should not be necessary to transfer files locally between devices. at least user level file encryption should become straightforward on a mobile device which it is not today.
That requires having an account on the other machine. What's missing is anonymous scp, where the other side just opens up a directory, and you can copy into it. One can build something like this with rsyncd, but it's not a pretty shell one-liner to get it going and it still requires both devices to be on the same network.
It does seem to be missing a pretty significant era though? There's 802.11ad (2011) / 802.11ay (2021) / wigig.
It's mainly known for video, and is used today for VR headsets. But there's a huge variety of 802.11ad docks out there that also have USB, mostly about a decade old now! Intel's tri-band 17265 (2015) was semi popular in the day as the supporting wifi+wigig+bt host adapter, works with many of these docks. https://www.intel.com/content/www/us/en/products/sku/86451/i...
I've definitely considered buying a dock & wigig mpcie card & test driving this all! Price was way out of reach for me at the time, and I expect the performance caveats (range, speed, latency) are significant, but it could potentially genuinely help me run less cables around the office & the patio, and that would be cool. Afaik though there's no Linux support though, so I haven't tried.
Not UWB focused (but could work over IP capable UWB systems) I'd love to see more usb-ip systems emerge. It works pretty well for DIY (and kind of has for multiple decades now), but productization & standardization of flows feels hopeless, & worse, feels like anyone who knows up is likely to do the wrong thing & make something proprietary or with nasty hooks. https://usbip.sourceforge.net
And not USB specific, but pretty cool that the briefly mentioned 802.15.4 group continues to have some neat & ongoingly advancing 6-9GHz UWB work. IEEE 802.15.4ab is expected semi soon. Spark Microsystems for example recently announced an incredibly low power SR1120 transciever, good for up to 40mbps, capable of very low latency. It'd be lovely to see this used somehow for generic/universal peripheral interconnect. https://www.hackster.io/news/spark-microsystems-unveils-its-...
(author) Funny you should mention, because a couple other people also mentioned this to me after I posted it. Sadly, I don't have any of those devices here, but I added a footnote to the article about them.
Could wireless USB be a case of "if all you have is a hammer, everything looks like a nail"? [1]
I.e. the effort was driven by the USB-IF [2] that happens to be more hardware than software oriented. So they were eager to deliver a solution based around a new chipset that could be adopted immediately by anyone interested.
This failed to account for adoption friction/lag, and the era of ARM-based SBCs and WiFi proliferation which was already dawning (e.g. iPAQ handhelds were available at the time [3]).
So, they ended up with most of their envisioned use-cases [4] being covered either by SBCs, or by Bluetooth. At least in retrospect, standarizing a pure software solution like USB over IP, as an added-value proposition for the USB standard, would have made more sense.
We were a bit late when we discovered wireless USB had been a thing. Still, we managed to find one pair of emitter and receiver that also transmitted HDMI, power the "receiver" side with a battery, in a backpack, and hook it up with another power bank to an Oculus DK1.
Unexpectedly, battery time was never an issue. The WUSB chip in the receiver would overheat long before that and start throttling, leading to jittery head tracking.
Turned out, it was a widespread issue with that WUSB chip.
Maybe the deeper problem with wireless USB was that “Wireless USB” is an appealing word salad rather than a solution a meaningful problem.
I mean a wireless USB hub would eliminate exactly one cable [1] and onboard wireless USB requires the same number of radios as WiFi. [2] But “Wireless USB” still sounds a kinda’ sexy answer to “What are you working on?” [3]
[1] Wirelessly eliminating one USB cable already had its critical solution in a mature dongle dependent wireless mouse market.
[2] For example WiFi printers were already a thing and fit into the evergreen problem of sharing printers and wireless USB wasn’t going to improve online experience.
[3] “Wireless USB” is a great sound bite. Short, sounds like the future, and people will feel like they know what it means. [4]
[4] The article reminded me that indeed at some point in the last five years (or maybe ten, these things run together) I thought “wireless USB would do that” and googling “wireless usb” because surely it must exist but of course it didn’t really and I probably bought a long cable off eBay. But I remember coming up with the thought and googling.
The standard of "wireless USB" was there, but probably as in any standards war, moved too slowly and had less to offer than competing standards. Are we not better off with Wifi and Bluetooth now?
Btw, is there a direct comparison anywhere regarding energy consumption of the competing standards in real situations?
Bluetooth is bad enough that wireless mice/keyboards usually have a USB dongle receiving what I guess is a proprietary RF protocol. Some wireless headphones have that too. And wifi requires too much power.
I don't know why USB dongles are popular for manufacturers (I assume to make their product more plug-and-play friendly), but I don't think they are a better solution than bluetooth. For example, it is common that if another USB device is plugged close to a USB dongle, it can cause interference to it, which results to unstable connection and eg makes a mouse "jump", keystrokes not register etc. Finding the right place for a USB dongle can be a pain. USB dongles with proprietary RF protocols are usually a terrible solution imo. I have never had any similar kind of connectivity issues with a bluetooth mouse or keyboard.
USB dongles are popular because the mouse is paired with the dongle. This comes handy in a number of use-cases (servicing a different computer, hot-desk office, non tech-inclined people).
It is true though that USB interference for wireless dongles is an annoying reality. My Logitech Unifying dongle has issues whenever I copy files over USB. I'm not sure if later revisions or their Bolt dongles have improved on that.
It’s fine for any use of a keyboard or mouse besides a niche in gaming. It also uses less energy than most RF dongles, which results in better battery life (something I could check using a couple of mice that could do both).
The fact that Logitech’s current dongles are just BLE with a fancy encryption scheme tends to indicate that they really want their proprietary hardware, and bandwidth is not the reason.
Bluetooth mice use the HID protocol borrowed from USB, except with Bluetooth as carrier. But HID had not been designed for the possibility that packets could get lost: it sends movements as a relative vector since the previous packet.
I don't know how Logi Bolt works, but Logitech has claimed that it should work better than BLE when the 2.4 GHz band is congested. Also that it would have better security than BLE.
> But HID had not been designed for the possibility that packets could get lost
Doesn't the same problem exist for USB dongles with proprietary RF protocols?
Logi Bolt is a good solution. But ime most other USB dongles are terrible. I have had a lot of bad connection issues with such USB dongles, and never with similar bluetooth devices. USB dongles also use the same 2.4GHz band, and even more they are prone to interference from nearby active USB ports [0]. If you have ever had a "jumping" mouse while transfering big amounts of data through a port neighbouring your mouse's USB dongle, this is likely the reason.
The proprietary protocol can use absolute positions between device/dongle, and then the dongle can translate to relative positions at the edge, by returning the difference since the last poll
Precisely. That is how I would have designed a wireless mouse protocol: using wrapping counters and sending the counter values. The HID protocol does not support an input value that is Absolute/Wrap (although it could be extended to do so, and I think that it should)
I'd think it would also be possible to get around congestion problems by using tricks such as multiple channels and/or interference detection on top of BLE.
But only Logitech knows how Bolt actually works.
They don't mean the absolute real distance between dongle and mouse.
They mean the mouse communicates an absolute position (relative to some arbitrary 0,0 the mouse decides upon) instead of a relative direction.
Dongle can then take latest coord packet and diff it against previous coord packet to get a relative coord to pass via HID to the system.
If the RF packets are lost, some latency occurs but the dongle still has the previous mouse coord and can make a fairly accurate correction once a packet gets thru (get's from A to D, but might skip points B+C).
I mean, you can't type in BitLocker password wirelessly without a dongle. Optical mice sensors aren't so repeatable anyway, so missing a packet or two probably aren't so critical.
Neither Wifi nor Bluetooth are a 1:1 replacement for wireless USB, in that neither allow you to use a standard USB device without a wired path between the device and host.
In theory, Bluetooth ought to be the replacement for most use cases, and would simply require replacing your USB devices with Bluetooth devices. In practice, Bluetooth is still kind of terrible, so I'm tempted to say any alternative timeline where something else won the personal area network war would probably be better.
We still kind of do wireless USB, in that the standard for wireless mouse and keyboards is still not Bluetooth, but a dedicated USB dongle that ships with the device. Such options are available for wireless headsets as well, although Bluetooth seems to winning in that niche.
It used to be the case that BT was terrible, but in the last few years I have increasingly stable device connections. Could it be they simply ironed out the bugs over the years, the standard matured, and also the manufacturers are more compliant? It just works for me, no horror stories. And BT LE is indeed low energy.
Btw, do you have any other suspected reason (politics aside) that wireless USB did not catch on?
The real change is that BT LE isn't just about low energy. That might have actually been the original intention, but in practice it is so good beyond that core area of competence that it has also displaced classic Bluetooth in fields like audio streaming, connections beyond strictly PAN distance and so on. And it will only get better as more remnants of Old Bluetooth are disappearing from devices, that have been retained for backwards compatibility.
> Are we not better off with Wifi and Bluetooth now?
Bluetooth is a nightmare of a standard. Up until very recently even pairing two devices was a non-deterministic operation. Apple went as far as creating their own chip with their own protocol for their headphones just not to have to deal with bluetooth.
Imo, at this point nobody should be designing any wireless protocol that doesn't support full IP networking.
Sure, your Bluetooth headphones only 1:1 connect to your phone... But if they could connect directly to your WiFi router they could keep playing music when your phone goes out of range... Or you could connect them to two phones... Or you could connect them to your TV to get sound from that...
Basically, IP networking still allows direct connections, but also allows far more possibilities.
Same with wireless USB - a wireless USB printer can only print from one host - but a wireless IP printer can be on the network for all to use.
Please do not give me more devices that need to connect to my WiFi for basic functionality. These devices add congestion, attack surface, and give manufacturers access to way more information than I am comfortable with. I already have to fight my washing machine, stove, refrigerator, etc. on this.
The main reason why I love Zigbee is that it doesn't support full IP networking. It's about broadcasting standard messages to all the devices, like a message queue, and that's fantastic for the use case.
No firewalls to worry about, no external access, nothing, just all my devices automatically communicating with all other devices.
I don't want to have to expose any of my devices to the entire internet just to use them. Sure one can firewall and block things manually, but I would prefer things were secure by default.
This directly opposes design principles of secure and correct by construction.
If any of my colleagues would make an overly abstracted solution for a problem and ship it with a dsl to configure it, I would say no, and ask them to solve the problem at hand.
Interesting to read about the (literal) bandwidth limitations on data rates. It's something I've been aware of but not fully understood for a long time. "Why can't you just turn the wave on and off faster", etc...
Instead of talking about the fundamentals like Fourier transforms, Shannon/Nyquist and wave propagation i usually refer to human speech: how increasing the rate of speech (signalling rate) comes with 1) substantial reduction in transmitting distance as the environment affects signal quality and 2) places a higher burden on error correction (interpretation of language) that is independent of the actual ability for the transmitter to create the faster speech.
This post has unlocked the memory of seeing some Intel CEO demoing wireless power and connectivity for laptops.
Basically you "just" put your laptop on your desk and it automatically starts getting power (similar to what phones can do nowadays) as well transmit video to a display (on the same desk).
It's sad that went nowhere, it would have been very cool and something actually useful.
It would be a marginal. Improvement at a huge increase in complexity
Adjacent intention on the same action that leads to a connected computer, eg. I put my laptop on my friend table for storage, and it connects against my intention.
Totally. Many accessories nowadays require bluetooth/wifi where actually they could be connected with a cable: they don't move and they need to be charged.
Connecting over a cable is trivial: you detect the connection and that's it, and the user physically sees the connection between the devices.
Connecting over radio requires pairing, that is very frustrating when it doesn't work. Pairing is annoying so devices try to automatically reconnect, but then if you pair with multiple devices, it brings frustration because it never automatically connects to what the user wants.
Whenever cables are a possible solution, they are superior.
And replace cable pain with ISM congestion pain? Living in a somewhat densely populated area I find myself switch off Wi-Fi on my smartphone because paid LTE is so much more reliable quite often.
Interestingly one of the competing chipsets for Wireless USB lives on today... in the market-leading[1] Spektrum radios for RC vehicle control. Their DSMx protocol is based on the Cypress Semiconductor products, which are still available in the market despite not being recommended for new designs.
[1] But certainly not best. Consensus for "best" goes to the open source ExpressLRS work based on the Semtech LoRa products.
I worked on the design of wireless USB chips around 2008 - 2010. They worked - you really could get USB 2.0 full rate connections wirelessly and we had some neat demos.
I would say the major problem it had with adoption was that wired USB also provided power. (A lot more people use usb to charge their phone than to sync their phone.)
So great - wireless connectivity... but you still have to plug the device into a cable at some point (or have replaceable batteries), which makes the value proposition a lot less clear.
Beyond that it suffered from the usual adoption chicken-and-egg problem. Laptop manufacturers didn't want to add it because it was an expense that didn't drive sales since there weren't any must-have peripherals that used it, and peripheral manufacturers didn't want to make wireless usb devices since they couldn't be used with a standard laptop (at least not without a WUSB dongle - which raised the cost).
Still, very fun stuff to work on.
I don't see why Bluetooth took off and wusb didn't. It must have something to do with marketing.
Bluetooth had some early success in cellphones, mostly to support Bluetooth headsets and car radio integration, starting from about 1999. It could do other things, but the wireless headset was the killer app in its early days.
Bluetooth didn’t really hit mainstream until the arrival of chipsets that multiplexed Bluetooth and WiFi on the same radio+antenna. My memory is that happened sometime around 2007-2010.
At that point, the BOM cost to add Bluetooth to a laptop or smart device became essentially zero, why not include it? Modern smartphones with both Bluetooth and Wifi arrived at around the same time (I suspect these combo chipsets were originally developed for handheld devices, and laptops benefited)
And once Bluetooth was mainstream, we saw a steady rise in devices using Bluetooth.
WUSB operates on a completely different set of frequencies and technology and couldn’t share hardware with WiFi. Maybe it could have taken off if there was a killer app, but there never was.
> the wireless headset was the killer app in its early days
Don't forget music piracy.
At least over here, a lot of kids had phones that did Bluetooth, and the primary use case for it was sharing songs they liked with each other. You could use infrared (IRDA) for that, and some people did before Bluetooth was common, but it was much slower.
This was mostly on low-end Nokias, maybe with a bit of Sony Ericsson thrown into the mix. They definitely did not have WiFi, in fact, Nokia even tried to limit internet over Bluetooth for usual carrier monopoly reasons as far as I'm aware, but Bluetooth was definitely there.
For many here, the iPhone not doing file and ringtone sharing over Bluetooth was one of its main limitations, at least early on. It was a social network in its own way, and having a device that couldn't participate in it was no fun.
Wow this unlocked a bunch of memories from middle school where we would send each other the latest songs and games via bluetooth. I remember pirating games for my sony ericsson and sharing them with my friends and we would play these games in class. You could just share and install the .jar files. Good times
By "early days", I was more thinking about the 1999-2005 era, before low-end Nokias even got Bluetooth and the ability to play MP3s.
The wireless headset was the killer app that drove bluetooth adoption within cellphones, driving down costs until eventually the lower-end models receiving it too. While sharing files was possible in the 1999-2005 era (especially with PDAs), most phones were lacking enough flash storage to store anything worthwhile.
While I don't want to say file sharing wasn't a killer app, it does seem to have been limited to just schools during a certain time period.
A time period that I missed out on by a few years. At high school, we did all our file sharing by swapping burned CDs. Then we switched to dragging around laptops and USB hard drives at university (and using the private emule network on the university wired ethernet).
> Don't forget music piracy.
What you describe is file sharing, not necessarily piracy :-). Just nitpicking, I understand what you mean of course!
At this point, the decision to add Bluetooth or not is literally just a product decision. If you don't want Bluetooth in your product, you actively have to disable the Bluetooth part of your WiFi chip, because you can't really get a WiFi chip without Bluetooth.
> the wireless headset was the killer app [for Bluetooth] in its early days
But the wireless headset is now a horrifying millstone making Bluetooth look like the world's stupidest trash fire. If you enable your microphone, you lose all audio from anything that doesn't want to use the microphone as the headset switches into "headset" mode and drops anything that wants to use "headphones" mode. There is no reason for there to even be two different modes.
Why is this still happening?
Back when Bluetooth was new, the alternative for wirelessly sharing data between mobile devices like phones was infrared.
IR was exceptionally slow, required line-of-sight and even at the time, felt like a shitty solution. So even though the early implementations of Bluetooth also left a lot to be desired (battery hungry, insecure, and also slow), it was still a massive improvement on what came before.
Wireless USB wasn’t a significant enough improvement to Bluetooth given that BT was already ubiquitous by that point, but also cheap and (by that point) battery efficient now too.
IR with palm devices was super nice - just point to the other device and send, then confirm on the other. No persistent pairing bullshit & you could also use it to control TVs.
That’s how BT originally worked too but it got abused (I touched on this in my original comment when I said BT was insecure). The paring is a security measure to protect people from abuse.
Back when BT was new, I used to get all sorts of random shit pushed onto my phone every Friday night on the drunk train home from London.
I guess that was a lot less of a problem with IRDA as it required line-of-sight, which limited the abuse potential significantly.
Some devices would even establish an IRDA connection automatically as soon as they found anything. I have friends whose laptop names have suddenly appeared on lecture room projectors, as their laptop's IRDA receiver was in direct line of sight of that of the teacher's.
Not that you couldn't do that with Bluetooth, some early BT chipsets gave you a "<device name> wants to connect to you" dialog box any time somebody tried sending something to your device. This could be abused, to great student amusement, to display funny messages on that same projector if the lecturer's laptop had such a chipset.
I wonder why IR is slow. Shouldn’t there be plenty of bandwidth available at those frequencies?
It was harder to extract a clean signal due to ambient environmental conditions.
You could probably solve those issues with modern tech though. Things have advanced significantly since IR was popular. For example, back then Bluetooth was slow too.
Not through a tiny photodiode + amp on a spare UART RX, if not repurposed TV remote phototransistor. They can be slow.
I'm frankly baffled at all these reports of IR being unreliable and slow. It... wasn't. Not for the file sizes of the day. I exchanged plenty of files back in the day, even at 115200bps a picture would be 2-3 seconds tops (pictures were small!). And when devices started supporting 4Mbps, even a large-ish MP3 would go in 5-6 seconds. All without setup or pairing, beautiful. Huge files (like full resolution pictures from an SLR camera) would take a while - but frankly they took almost the same time with a cable! You'd just have to plug their memory card directly into your computer if you were in a hurry.
The only really clunky use case for me was internet access - keeping phone and laptop positioned and aligned for 30 minutes was limiting.
And yes there IS plenty of bandwidth at those frequencies. In fact latest IR standards reach 1Gbps, but it's pretty much extinct. There was an attempt called Li-Fi to use it for as a wireless networking but I don't think it went far.
What I really miss is OBEX (Object Exchange), which worked also over Bluetooth, and which Apple sadly chose not to implement: simplest protocol to just ship a file or a contact vCard over, no setup, just worked - and it's been a standard for 20+ years. Early Android had it too, it was since dropped I think. Sigh.
You’re either misremembering things or talking about an era after Bluetooth had already taken off.
In the days before Bluetooth, transferring MP3s over IR took multiple minutes, even on high end (for the time) handsets.
And the fact that you needed to keep line of sight during the whole process meant your phone couldn’t be used that whole time. Which was a real pain in the arse if you got a text message or phone call while trying to transfer a file.
IR was really more designed for swapping contacts. In fact that’s exactly how BlackBerry (or was it Palm?) marketed IR on their device: a convenient way to swap contact details. But you’re talking about a few KB vs several MBs for an MP3.
The tech has definitely moved on since. But then so has Bluetooth, WiFi and GSM et al too.
It would take me like 30 minutes to transfer 1MB.
You were pretty unlucky. The basic bitrate was 9.6kbps but much higher speeds were common.
Mostly just SNR issues.
These days, professional optical equipment, aka expensive lasers+supporting hardware, can do 10-Gbit over multiple kilometers through the air, so you're right that optical transmission through the air should be able to support higher data rates.
The problem with Irda is that it's old. Technology has significantly advanced since the 90's, when Irda was popular on cellphones, so a modern implementation could do better data rates even accounting for the significant interference from the environment. We barely had wifi back then, and now it'll do a few hundred megabytes per second without breaking a sweat (your ISP might though). All the technology required to do that didn't exist in the 90's. We have Bluetooth now though, so there's that same bootstrapping problem, where you'd just use Bluetooth, and not spend a bunch of money building a system very few people are asking for, so then there's little demand for a modern high performance Irda system in any devices.
Bluetooth took off before wireless usb did and was allready useful to people when wusb came a long. It was also lower power so you could do peripherals that was smaller and longer lived.
Largest phone manufacturers of the time (Ericsson and Nokia) supporting and developing it surely helped.
Introducing a new wireless protocol is incredibly difficult. You basically have to have all the countries in the world to give you a chunk of their spectrum.
You have 2 mainstream protocols now, one for low energy, slow data transfers (Bluetooth) and one for fast, but more power hungry devices.
I don't see the usecase for UWB.
yes-and-no.
In my opinion, this was the timing and usefulness of Bluetooth in an era when only Nokia ruled the world. Moreover, there are many other reasons too.
> which makes the value proposition a lot less clear.
Wirelessly transferring files between a phone and a computer seems like a big use case. Still no easy standard way of doing it.
I assume this is the same "problem". Most people (not the HN cohort) don't want to transfer "files", the abstraction of the file is either outdated for them or maybe even unnatural / unknown (younger generation).
They might want to transfer (a better word: share) photos/videos, documents, etc. And for those they use specific apps and "the cloud". No "files" (for the sake of files), and barely any hierarchy of (folders etc).
As long as the entity they want to share magically shows up on the another device or at the other person they want to share with, they are happy. They just skip two levels of abstraction ("this photo is a FILE and I will use USB to transfer it"). Maybe a far fetched analogy but this is why most of the drivers of an automatic don't really think about clutches and how the torque of the engine's output is converted.
At least this is my perception (outside the IT bubble)
I believe in the opposite.
Because we can't transfer easily transfer files between devices remotely, we had to get used to do it via apps. And so we didn't developed good, local files browsers (esp. for media) and companies invested in the cloud UI mostly because they could sell the storage and sharing capabilities. That was all unnecessary but we're used to that now to a point where sharing files is weird.
As a power user happily syncthinging all my files between all my devices, I'm sad because files is the easiest thing to share, organize, transfer, etc. I wish iOS supported this kind apps (full storage access!) as we could avoid the many, crazy, Alps specific workarounds just to share some stupid files.
And don't confuse the file itself (say, a pirated movie), the metadata (IMDb IDs) and the apps UI (Kodi!). Files is what we have, we should share files and let anyone pick the browser/apl they like for viewing, organizing…)
Don't get me wrong, I'm totally happy woth files. In fact, I'm sometimes a bit annoyed when certain apps' entities don't map to files either accidentally or to maintain the walled garden on purpose (I'm looking at you Google Photos, and the very cumbersome rclone connector to it).
On the other hand, I don't mind that full storage access is a "pain"; I don't even remember which apps I gave the permission to, and I would certainly be angry if my syncthinged files would be stolen by other app that went vicious.
All that said, as people don't think about their documents/photos/any other stuff in their homes as "filed items in folders", non-tech people also don't think about their digital items as such. And maybe this is alright, if the "file-ification" would have been so successful, better products would have emerged.
I think I disagree with that. This "people don't want files, they want to share photos", to me, is what product people want to believe. The whole thing has been enforced on users and is self-reinforcing: of course if you don't show files to users, they will not know what a file is.
Sure, I may be in a photo gallery and I may want to share a few photos with a friend who may want those photos to be treated as photos (instead of going into a big "Downloads/" folder). But it doesn't mean, at all, that the concept of file has to disappear to the user. In fact the files still very much do exist on the system. Product people just assume users are stupid, IMHO.
And the thing is: this abstraction (not knowing what a file is) doesn't make it faster or more efficient. It just makes the user more dependent on their platform and apps. Look at backups: product people at Google/Apple will tell you "people don't want to backup their files, they want to pay us to make sure that they never lose an image". Conveniently, it means that people are 1) forced to pay them and 2) don't have control over their own files.
Maybe GenZ/alpha now are stuck with these abstractions because they never learned what a file was (for no reason other than being abused by product decisions), but older generations grew up with physical media. "I have a piece of paper, I have a book, I have a CD-ROM, and those are all different kinds of files that can go into different "boxes" that are called folders".
Files and folders are very natural. The reason people don't know about them is because we hide them and force them to pay for literally subpar experience.
> and barely any hierarchy of (folders etc).
One of my great hate pet peeves with all smartphone and cloud apps is the "abstraction" and reliance on search. For me folders is quicker and less error prone, and as a bonus it saves on unneeded bandwidth (to load previews) and computing costs.
Also stop telling me I must use your one off "feature set" of sorting and ordering which either nobody uses or copies differently. The amount of square wheels (for me I must add, ymmv) reinvented is astonishing.
Folders as an abstraction don't really make sense beyond documents, though.
If your music is stored in a folder hierarchy, and can, in principle, be located anywhere, how do you index it to provide a library view? How do you distinguish it from random audio files that just happen to be ID3 tagged, but which you don't want as part of your permanent music collection? How do you efficiently react to deletion events? What happens if you delete an entire artist's worth of music from your music app? Should it delete the files, or only the library entries? If it deletes files, what if (some of) that music was in a folder that didn't contain any other files? Should that folder be gone too, or should you be left with an empty folder or hierarchy? What if the folder also contained a .nfo, is it good UX if it deletes the music and just leaves the .nfo?
If the only tool you have is a computer, everything is a file. If you're a music lover and not a computer enthusiast, you tend to think about albums, artists and playlists, and that's how you want to view your music collection.
Also, they want to use the same "abstraction" for "sharing photos with their friend when they're on holiday in another country" versus "sharing photos with that same friend when they just got back and are literally sitting next to each other."
People don't really internalize that those are two different use cases.
Yes there's Airdrop, but I think most people view it as more of a "discoverability" solution than a file sharing solution. If you met somebody you don't have a number for, "okay just Airdrop this to me" is much easier than doing the whole song and dance of adding them to contacts and sending them an iMessage or finding them on Whats App. Whether the actual file transfer part of Airdrop goes over the internet or over Bluetooth isn't something most people care about, as long as it can discover nearby devices and initiate a transfer to them, it's good enough.
I disagree. I find it condescending when techies say "the average user doesn't make the difference between sharing a file to a device next to them and sharing a file over the Internet".
Everybody, and I mean everybody is capable to understand that to connect their Bluetooth headset to their phone, they do it over Bluetooth. And that to connect to the Internet, they can either go over WiFi (which is "free") or cellular (which is less "free").
> People don't really internalize that those are two different use cases.
We actively keep them ignorant, and then we use their ignorance as a justification. I find it sad.
What if we said "People don't want to drive their car somewhere, they want to go from A to B. We should prevent them from learning how to drive so that they would have to pay for our taxis".
I want to add something to this: abandoning the fire layer allows for richer custom flows (which to many are arguably worse)
For example the file API does not allow a clean, uniform, and reliable way to associate a resource with some metadata
I don't get that. How do you expect to abandon the file layer on your OS? Do you plan on rewriting Windows, macOS, Linux, Android and iOS with a fundamentally new philosophy?
If not, then you're not abandoning the file layer at all. You're just preventing people from benefitting from it.
The file API might not, but all major filesystems implemented some kind off Metadata attributes, IIRC Microsoft was wanting to heavily rely on that for "user space" stuff (e.g. Users leveraging it for semantic information about their files)
Bluetooth FTP was widely supported until ~2009. All Nokia phones and many flip phones had it. iPhone did not, AOSP technically did, but carrier phones often had it disabled, and it slowly disappeared.
Windows 11 still supports it, I think macOS too. Pairing is technically optional.
But that doesn't need new peripherals, I could do that in my home WLAN network if they'd just install standard software for it on the phone (which you can fix by installing it from F-Droid etc.)
There's no formal standard, but I keep seeing this complaint from people who just haven't installed syncthing. At this point it's not inexistence but mere ignorance
It's not only about your personal devices. Sometimes you want to exchange files between a friend phone's and your computer.
This is an UX problem, not a technical problem. You could easily use Wifi to transfer files between devices quite fast, there's just no agreed upon open protocol for it. Afaik that's how AirDrop works.
Airdrop works. Ok, it's platform bound, but I'm sure it could be ported.
It's not such a big thing, though. I hardly use it, and young people don't seem to use it either. The stuff on their phone and laptop seem separate worlds, just like mine are. Might be because they don't know about it, though.
Because we keep them ignorant. We make sure they depend on our apps that they have to pay for. You wouldn't want them to know how to download music/movies without going through our paid streaming platforms, would you?
Hell, copy and paste works between iphone and MacOS if you've got the same icloud logged into both. Airplay is too cumbersome has been supplanted by long hold -> copy; ctrl-v, and the reverse. Works for images as well.
Imo cloud storage like Dropbox has 95% solved this use case for years, which is why alternative solutions haven't popped up.
Needing to upload files to third party servers just to get them onto your personal computer doesn't solve the case. It just injects a middleman.
How does it not solve the problem? The data shows up on the other end. The fact that you don't agree with the implementation is a different thing, but it does solve the case.
> How does it not solve the problem?
It "solves" it but in a way that's ten times slower and fundamentally unreliable.
For small files maybe. As shocking as it may seem, most Dropbox users just have the free version, with very limited space. Same for Google Drive or One Drive.
And only works when you’re connected to the internet.
Dropbox is unavailable to huge populations. also sharing private bits with a cloud service should not be necessary to transfer files locally between devices. at least user level file encryption should become straightforward on a mobile device which it is not today.
There are websites using WebRTC for p2p transfer.
scp works well for me.
That requires having an account on the other machine. What's missing is anonymous scp, where the other side just opens up a directory, and you can copy into it. One can build something like this with rsyncd, but it's not a pretty shell one-liner to get it going and it still requires both devices to be on the same network.
This was so cool to go over.
It does seem to be missing a pretty significant era though? There's 802.11ad (2011) / 802.11ay (2021) / wigig.
It's mainly known for video, and is used today for VR headsets. But there's a huge variety of 802.11ad docks out there that also have USB, mostly about a decade old now! Intel's tri-band 17265 (2015) was semi popular in the day as the supporting wifi+wigig+bt host adapter, works with many of these docks. https://www.intel.com/content/www/us/en/products/sku/86451/i...
I've definitely considered buying a dock & wigig mpcie card & test driving this all! Price was way out of reach for me at the time, and I expect the performance caveats (range, speed, latency) are significant, but it could potentially genuinely help me run less cables around the office & the patio, and that would be cool. Afaik though there's no Linux support though, so I haven't tried.
Not UWB focused (but could work over IP capable UWB systems) I'd love to see more usb-ip systems emerge. It works pretty well for DIY (and kind of has for multiple decades now), but productization & standardization of flows feels hopeless, & worse, feels like anyone who knows up is likely to do the wrong thing & make something proprietary or with nasty hooks. https://usbip.sourceforge.net
And not USB specific, but pretty cool that the briefly mentioned 802.15.4 group continues to have some neat & ongoingly advancing 6-9GHz UWB work. IEEE 802.15.4ab is expected semi soon. Spark Microsystems for example recently announced an incredibly low power SR1120 transciever, good for up to 40mbps, capable of very low latency. It'd be lovely to see this used somehow for generic/universal peripheral interconnect. https://www.hackster.io/news/spark-microsystems-unveils-its-...
(author) Funny you should mention, because a couple other people also mentioned this to me after I posted it. Sadly, I don't have any of those devices here, but I added a footnote to the article about them.
Could wireless USB be a case of "if all you have is a hammer, everything looks like a nail"? [1]
I.e. the effort was driven by the USB-IF [2] that happens to be more hardware than software oriented. So they were eager to deliver a solution based around a new chipset that could be adopted immediately by anyone interested.
This failed to account for adoption friction/lag, and the era of ARM-based SBCs and WiFi proliferation which was already dawning (e.g. iPAQ handhelds were available at the time [3]).
So, they ended up with most of their envisioned use-cases [4] being covered either by SBCs, or by Bluetooth. At least in retrospect, standarizing a pure software solution like USB over IP, as an added-value proposition for the USB standard, would have made more sense.
[1] https://en.wikipedia.org/wiki/Law_of_the_instrument#Abraham_...
[2] https://www.usb.org/about
[3] https://en.wikipedia.org/wiki/IPAQ
[4] https://en.wikipedia.org/wiki/Wireless_USB#Uses
We were a bit late when we discovered wireless USB had been a thing. Still, we managed to find one pair of emitter and receiver that also transmitted HDMI, power the "receiver" side with a battery, in a backpack, and hook it up with another power bank to an Oculus DK1.
Unexpectedly, battery time was never an issue. The WUSB chip in the receiver would overheat long before that and start throttling, leading to jittery head tracking.
Turned out, it was a widespread issue with that WUSB chip.
Didn't help you had to flip the signal up-down-up to get it working.
Maybe the deeper problem with wireless USB was that “Wireless USB” is an appealing word salad rather than a solution a meaningful problem.
I mean a wireless USB hub would eliminate exactly one cable [1] and onboard wireless USB requires the same number of radios as WiFi. [2] But “Wireless USB” still sounds a kinda’ sexy answer to “What are you working on?” [3]
[1] Wirelessly eliminating one USB cable already had its critical solution in a mature dongle dependent wireless mouse market.
[2] For example WiFi printers were already a thing and fit into the evergreen problem of sharing printers and wireless USB wasn’t going to improve online experience.
[3] “Wireless USB” is a great sound bite. Short, sounds like the future, and people will feel like they know what it means. [4]
[4] The article reminded me that indeed at some point in the last five years (or maybe ten, these things run together) I thought “wireless USB would do that” and googling “wireless usb” because surely it must exist but of course it didn’t really and I probably bought a long cable off eBay. But I remember coming up with the thought and googling.
In certain cases, plug-and-play interfaces outperform wireless mediums.
The standard of "wireless USB" was there, but probably as in any standards war, moved too slowly and had less to offer than competing standards. Are we not better off with Wifi and Bluetooth now?
Btw, is there a direct comparison anywhere regarding energy consumption of the competing standards in real situations?
Bluetooth is bad enough that wireless mice/keyboards usually have a USB dongle receiving what I guess is a proprietary RF protocol. Some wireless headphones have that too. And wifi requires too much power.
I don't know why USB dongles are popular for manufacturers (I assume to make their product more plug-and-play friendly), but I don't think they are a better solution than bluetooth. For example, it is common that if another USB device is plugged close to a USB dongle, it can cause interference to it, which results to unstable connection and eg makes a mouse "jump", keystrokes not register etc. Finding the right place for a USB dongle can be a pain. USB dongles with proprietary RF protocols are usually a terrible solution imo. I have never had any similar kind of connectivity issues with a bluetooth mouse or keyboard.
USB dongles are popular because the mouse is paired with the dongle. This comes handy in a number of use-cases (servicing a different computer, hot-desk office, non tech-inclined people).
It is true though that USB interference for wireless dongles is an annoying reality. My Logitech Unifying dongle has issues whenever I copy files over USB. I'm not sure if later revisions or their Bolt dongles have improved on that.
Bluetooth's latency is just too slow for a mouse. Heck, Bluetooth is too slow for audio, too, but most people seem to be complacent to latency.
It’s fine for any use of a keyboard or mouse besides a niche in gaming. It also uses less energy than most RF dongles, which results in better battery life (something I could check using a couple of mice that could do both).
The fact that Logitech’s current dongles are just BLE with a fancy encryption scheme tends to indicate that they really want their proprietary hardware, and bandwidth is not the reason.
Bluetooth isn't too bad, Logitech Bolt is based on BLE and it's just fine. Bigger problem is integration into x86/x86_64 platform.
Bluetooth mice use the HID protocol borrowed from USB, except with Bluetooth as carrier. But HID had not been designed for the possibility that packets could get lost: it sends movements as a relative vector since the previous packet.
I don't know how Logi Bolt works, but Logitech has claimed that it should work better than BLE when the 2.4 GHz band is congested. Also that it would have better security than BLE.
Bolt can't be better than BLE because it is BLE. Same with Apple gear which pairs so seemlessly.
It's just that they control both sides of the signal so can better optimize the connection.
> But HID had not been designed for the possibility that packets could get lost
Doesn't the same problem exist for USB dongles with proprietary RF protocols?
Logi Bolt is a good solution. But ime most other USB dongles are terrible. I have had a lot of bad connection issues with such USB dongles, and never with similar bluetooth devices. USB dongles also use the same 2.4GHz band, and even more they are prone to interference from nearby active USB ports [0]. If you have ever had a "jumping" mouse while transfering big amounts of data through a port neighbouring your mouse's USB dongle, this is likely the reason.
[0] https://www.usb.org/sites/default/files/327216.pdf
The proprietary protocol can use absolute positions between device/dongle, and then the dongle can translate to relative positions at the edge, by returning the difference since the last poll
Precisely. That is how I would have designed a wireless mouse protocol: using wrapping counters and sending the counter values. The HID protocol does not support an input value that is Absolute/Wrap (although it could be extended to do so, and I think that it should)
I'd think it would also be possible to get around congestion problems by using tricks such as multiple channels and/or interference detection on top of BLE. But only Logitech knows how Bolt actually works.
Is position estimation from the signal that accurate for that?
They don't mean the absolute real distance between dongle and mouse.
They mean the mouse communicates an absolute position (relative to some arbitrary 0,0 the mouse decides upon) instead of a relative direction.
Dongle can then take latest coord packet and diff it against previous coord packet to get a relative coord to pass via HID to the system.
If the RF packets are lost, some latency occurs but the dongle still has the previous mouse coord and can make a fairly accurate correction once a packet gets thru (get's from A to D, but might skip points B+C).
I mean, you can't type in BitLocker password wirelessly without a dongle. Optical mice sensors aren't so repeatable anyway, so missing a packet or two probably aren't so critical.
Neither Wifi nor Bluetooth are a 1:1 replacement for wireless USB, in that neither allow you to use a standard USB device without a wired path between the device and host.
In theory, Bluetooth ought to be the replacement for most use cases, and would simply require replacing your USB devices with Bluetooth devices. In practice, Bluetooth is still kind of terrible, so I'm tempted to say any alternative timeline where something else won the personal area network war would probably be better.
We still kind of do wireless USB, in that the standard for wireless mouse and keyboards is still not Bluetooth, but a dedicated USB dongle that ships with the device. Such options are available for wireless headsets as well, although Bluetooth seems to winning in that niche.
It used to be the case that BT was terrible, but in the last few years I have increasingly stable device connections. Could it be they simply ironed out the bugs over the years, the standard matured, and also the manufacturers are more compliant? It just works for me, no horror stories. And BT LE is indeed low energy.
Btw, do you have any other suspected reason (politics aside) that wireless USB did not catch on?
The real change is that BT LE isn't just about low energy. That might have actually been the original intention, but in practice it is so good beyond that core area of competence that it has also displaced classic Bluetooth in fields like audio streaming, connections beyond strictly PAN distance and so on. And it will only get better as more remnants of Old Bluetooth are disappearing from devices, that have been retained for backwards compatibility.
Better off with Bluetooth is something I never thought anyone would say.
> Are we not better off with Wifi and Bluetooth now?
Bluetooth is a nightmare of a standard. Up until very recently even pairing two devices was a non-deterministic operation. Apple went as far as creating their own chip with their own protocol for their headphones just not to have to deal with bluetooth.
Imo, at this point nobody should be designing any wireless protocol that doesn't support full IP networking.
Sure, your Bluetooth headphones only 1:1 connect to your phone... But if they could connect directly to your WiFi router they could keep playing music when your phone goes out of range... Or you could connect them to two phones... Or you could connect them to your TV to get sound from that...
Basically, IP networking still allows direct connections, but also allows far more possibilities.
Same with wireless USB - a wireless USB printer can only print from one host - but a wireless IP printer can be on the network for all to use.
Please do not give me more devices that need to connect to my WiFi for basic functionality. These devices add congestion, attack surface, and give manufacturers access to way more information than I am comfortable with. I already have to fight my washing machine, stove, refrigerator, etc. on this.
>Basically, IP networking still allows direct connections, but also allows far more possibilities.
> allows far more possibilities.
>> attack surface, and give manufacturers access to way more information than I am comfortable with
When your device is on your WiFi you cannot be completely sure what it does (unless you monitor the traffic).
As opposed to a USB device which requires you to install an opaque driver, which could also phone home? That’s hardly a win as far as security goes.
And requires more configuration! Sure let me just type a netmask into my headphones by tapping the volume buttons.
Hey, is your root password still bazz1l?
I've got a cat named Emacs, but he's not allowed to be a root password.
The main reason why I love Zigbee is that it doesn't support full IP networking. It's about broadcasting standard messages to all the devices, like a message queue, and that's fantastic for the use case.
No firewalls to worry about, no external access, nothing, just all my devices automatically communicating with all other devices.
I don't want to have to expose any of my devices to the entire internet just to use them. Sure one can firewall and block things manually, but I would prefer things were secure by default.
The protocol should allow it, even if the implementation perhaps limits users to the local network or some other more sensible security policy.
This directly opposes design principles of secure and correct by construction.
If any of my colleagues would make an overly abstracted solution for a problem and ship it with a dsl to configure it, I would say no, and ask them to solve the problem at hand.
The implementation needs to be controllable and simple enough for basic users then. If something is possible, companies will abuse it.
If the protocol allows it, products using the protocol will require it.
You're not going to get low power consumption with IP. That's a problem for small battery powered devices.
You will as long as the protocol is designed to be power efficient.
I agree though that existing WiFi networks are hard to connect to from devices where battery life needs to be measured in months.
Bluetooth had networking already in the early days (PAN).
Still there on android phones.
It's so terribly slow it's almost unusable, but does seem to be substantiality more power efficient than running a WiFi hotspot all the time.
Interesting to read about the (literal) bandwidth limitations on data rates. It's something I've been aware of but not fully understood for a long time. "Why can't you just turn the wave on and off faster", etc...
Instead of talking about the fundamentals like Fourier transforms, Shannon/Nyquist and wave propagation i usually refer to human speech: how increasing the rate of speech (signalling rate) comes with 1) substantial reduction in transmitting distance as the environment affects signal quality and 2) places a higher burden on error correction (interpretation of language) that is independent of the actual ability for the transmitter to create the faster speech.
This post has unlocked the memory of seeing some Intel CEO demoing wireless power and connectivity for laptops.
Basically you "just" put your laptop on your desk and it automatically starts getting power (similar to what phones can do nowadays) as well transmit video to a display (on the same desk).
It's sad that went nowhere, it would have been very cool and something actually useful.
> it would have been very cool and something actually useful.
Less efficient, just for "cool". I think it's better to stick with cables.
Yep!
It would be a marginal. Improvement at a huge increase in complexity
Adjacent intention on the same action that leads to a connected computer, eg. I put my laptop on my friend table for storage, and it connects against my intention.
Totally. Many accessories nowadays require bluetooth/wifi where actually they could be connected with a cable: they don't move and they need to be charged.
Connecting over a cable is trivial: you detect the connection and that's it, and the user physically sees the connection between the devices.
Connecting over radio requires pairing, that is very frustrating when it doesn't work. Pairing is annoying so devices try to automatically reconnect, but then if you pair with multiple devices, it brings frustration because it never automatically connects to what the user wants.
Whenever cables are a possible solution, they are superior.
That's one thing, but what happened to wireless HDMI? That would save a lot of cable pain in literally all households out there too.
And replace cable pain with ISM congestion pain? Living in a somewhat densely populated area I find myself switch off Wi-Fi on my smartphone because paid LTE is so much more reliable quite often.
It exists if you pay for a pair of dongles and are ok with bandwidth compormises.
Interestingly one of the competing chipsets for Wireless USB lives on today... in the market-leading[1] Spektrum radios for RC vehicle control. Their DSMx protocol is based on the Cypress Semiconductor products, which are still available in the market despite not being recommended for new designs.
[1] But certainly not best. Consensus for "best" goes to the open source ExpressLRS work based on the Semtech LoRa products.
Impressive. It sounds to be a thorough summary of Wirth's work.
Awesome. Now do WiMax.
In the coming age of AI we can do our own communications protocols and leave behind the horrible bt and wifi implementations. Right? :D