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.
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).
It may be worth articulating the Bluetooth headset specifically as the one-ear little clip headset executives and IT staff seemed to use to answer calls.
Remember companies like jawbone?
I vaguely remember a cultural stereotype of bmw drivers driving aggressively and wearing Bluetooth headsets. [edit: this is the clip https://youtu.be/UqfAMvXpSw4?t=25 from top gear of jeremy clarkson wearing a bluetooth headset in sunglasses in a bmw, supposedly from topgear season 10, episode 10]
Yes... there is a very interesting generational thing going on here.
Bluetooth headsets were very popular among a certain market segment (business people who made a lot of phone calls), but saw very little adoption outside of that. At that time, you often had to buy an expensive business grade phone to get bluetooth functionality.
Then once Bluetooth was common in cheaper phones, we see a completely different market segment (students at schools) rapidly adopting bluetooth for a completely different usecase (file sharing). It's hard to find two market segments that are more isolated from each other.
I don't think file sharing could have ever driven bluetooth to mass adoption on its own, partly because companies always overlook what school students are doing with technology. But mostly because the file sharing usecase required mass deployment of the technology before it could take off.
When I was in high school, I had a palm PDA with IrDA that could do file sharing. But did I ever use it for file sharing? No, because nobody else had devices with IrDA. IrDA never hit the market saturation it needed to be actually useful, so there never was much demand for it (despite the hardware being really cheap, especially compared to a dedicated bluetooth radio)
Bluetooth headsets worked as a killer app in those early days, because a single BMW driver could buy both a high-end phone with bluetooth and a headset from the cellphone store and get the complete experience. It worked without market saturation.
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
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.
All of the BT+wifi chips I’ve worked with require active initialization of each feature; you have to signal the chip (over i2c or SPI or whatever) with what kind of BT operations you want.
No BT stack in your product, no BT radio initialization, no BT/wifi multiplexing. At least in the (admittedly limited) chips I’ve worked with.
> 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.
It is happening because it works the way that is most useful to most people. The number of people who want to use bluetooth earbuds with a different microphone is line noise in the consumer market.
Implementing special requirements is always inconvenient for users because no B2C wants to risk bad the-microphone-didn’t-work reviews, customer returns, and support tickets.
Nevermind coordinating with arbitrary USB microphone latency…I’ve got one with 250ms of it.
> It is happening because it works the way that is most useful to most people. The number of people who want to use bluetooth earbuds with a different microphone is line noise in the consumer market.
I don't think you have any idea what you're saying. The scenario I'm describing is when you want to use a bluetooth headset that includes a microphone. Using a different microphone is how you solve the problem.
I have never had a microphone problem with a bluetooth headset. They all always just work until something mechanical breaks through use.
If I had an issue, wired headphones seem a simpler solution than changing the bluetooth standard and more likely to work than wishing manufacturers changed their devices.
So, the standard defines behavior that is obviously pathological, actively working against the needs of all users. But because it's already codified, it's a bad idea to change it?
it happens because bluetooth profile for audio+microphone uses different codecs and has less bandwidth, due to being used for realtime communication.
the bluetooth audio streaming profile enables more codecs, but only playback, and allows significantly higher latency that you wouldnt accept on a call
My personal bluetooth ear clips do something much worse than adding latency - if they're not currently playing something, and a sound is supposed to come through, they omit the beginning of the sound while they get ready to become active or whatever it is they're doing.
Just delaying the sound and playing all of it would be a big improvement.
(Though that would fail badly for watching videos. That's something that uses 'headphones' mode anyway - why is latency OK there? It isn't.
My ear clips do add some latency, a noticeable amount, when I'm watching a video with mpv, and I adjust that by altering the A/V sync setting. They don't do the same thing when I'm watching something on youtube. I'd like to know what's going on there.)
The absolute madness that is Bluetooth pairing between cars and cellphones is wild. If I get into my car and it decides to randomly pair with my wife's phone (who is inside the house) and I drive off, the whole infotainment system is locks up and dies until I get to my destination and turn off the car.
Mine connects and starts playing silently, and you need to press play and pause on the headunit to make it make sound. Every two months or so it fails to connect to the phone and needs a complete forget and repair to happen. Toyota unit and iphone.
My partner's hearing aid connects (via some radio protocol) to a device that then connects via bluetooth. Unfortunately, it presents itself as a headset, which causes... problems. For Android, they have to use an app from the play store that presents itself as an audio device and then sends that to the 'headset'.
Except for the "headphone" versus "headset" mode dichotomy that is inherent to Bluetooth, all those other issues are due to stupid product decisions that most OSes do to themselves independently on the same way.
If you use Linux + KDE, you can still use any microphone or headphone, many at the same time, or in whatever mode you want.
It used to work on kde/plasma 5 at some point. And after a minor version update it stopped working.
Now the mic of my headset doesn't work because KDE insists that only the high quality sound output without mic is available. The mic + low quality output is gone from the settings.
Lucky for me this update also brought proper handling of the stereo positioned noise cancelling microphones on my thinkpad. So now I can actually enjoy the luxury of built-in microphones that work. Until the day it wont I guess.
I am using pipe wire. The option to select the handset mode is gone! I can only select the various output codecs with my increasing quality. But not the mic & output mode. It's gone from the list...
> If you use Linux + KDE, you can still use any microphone or headphone, many at the same time, or in whatever mode you want.
This doesn't really seem to respond to the problem. The problem is that I'd like to use a single bluetooth device that includes earpieces and a microphone. That doesn't work, because of the headphone-headset mode dichotomy. As I replied to another comment, using multiple devices would be a solution to the problem. It wouldn't be an example of the problem that I want solved.
Bluetooth is apparently incapable of simply delivering an audio stream to the earpieces while accepting one from the microphone. This is a baffling design. The assumption appears to be that there will never be more than one source of audio for output. But that's crazy.
The ironic thing is the Bluetooth ignored it's audio use as much as possible for as long as possible. They wanted it to be used for tracking shoppers in stores...
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.
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.
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.
At 9600bps. Almost every device supported 115200 - that would cut it down to to 72 seconds. And as I mentioned - pictures were often small (20-30kbytes) back in the day - that's barely 1-2 seconds at 115200. And the later 4Mbps speeds would move that megabyte in 2 seconds flat.
My guess is just that Bluetooth and Wi-Fi came first, and when wireless USB entered the party, there wasn't a real need for it, as most of its use cases were already covered by Bluetooth and Wi-Fi.
It maybe could have worked with better marketing, but convincing potential customers to change something that works (somewhat, BT wasn't without issues) is hard. That's why we are keeping abominations like cigarette lighter sockets in cars even though they often can't even light cigarettes anymore. It is already well established and it works well enough as a power outlet.
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.
In my opinion, for computers, wireless mouse (and eventually keyboards) was one of the killer app that showed pushed for Bluetooth to be common in computers and laptops. "Not needing a dongle" was a huge added value compared to the private radio protocol of manufacturers
Maybe the low-power feature of Bluetooth helped it, such as with the Bluetooth LE (Low Energy) spec that with the way "services" and "characteristics" are defined that it allows for extremely low power consumption when no read-operation is done and thus the Bluetooth radio power can be minimized. Also, the 2.4 GHz band of Bluetooth is inherently less power consuming than the higher frequency band of Wireless USB.
But I guess the other problems may have been due to as the OP article brings up about it being in a different frequency communication band. Bluetooth on the other hand shares the same frequency band as Wi-Fi (2.4 GHz (which is also the OG Wi-Fi frequency band)). Thus for PC and mobile device OEMs, it is one less antenna to integrate. Furthermore, the higher frequency of the band would have made through-walls and further-distance communication less reliable. In this context, one of the few cool applications of wireless USB would've been a wireless keyboard or mouse (but this is coming from someone who is working on an OEM computer keyboard and mouse).
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.
And as far as I know, Wi-Fi and Bluetooth didn't have frequency given to them. They instead used frequencies that were already available for unlicensed use.
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 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.
Were you born with the knowledge that a video takes more space than a photo that takes more space than a text?
Or is it rather that you consider yourself one of the few people smart enough to memorise it? I find that very condescending.
I don't believe that one needs 3 postdocs to understand it. In fact, I do happen to have explained it quite a few times, and I don't remember anyone not understanding it.
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.
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.
The worst is photos, because the search abstraction really breaks there. On modern iPhones, it's still a pain in the ass to organize photos in such a way where you can come back later and find them. I'm still in the "scroll through the timeline until you spot it" phase.
Machine Learning is making this better, but ideally albums or folders wouldn't be such a pain in the ass to actually use in day-to-day life.
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.
You index it with btrees just like everything else. You distinguish it by configuring which folders to watch. You react to events with inotify. You don't give your music app write permission to your library. It only needs to write its indexes and playlists. All of your other questions become irrelevant; you delete the files you mean to delete with your file manager. In practice, music is small and storage is cheap, so deleting seems like a weird use-case for an application dedicated to music. I still have files that have been migrating across computers for 25 years.
Your player scans your library and indexes/sorts it however you'd like. I think this is how basically every player with a library function works? Like jellyfin loads my library in the same structure I've had it for 20 years, and it gives me various ways to view by name, artist, release date, rating, etc. and builds search indexes. I just point it to the roots of my libraries.
I said it needs a place to write playlists (or write access to your playlist folder(s)).
I wouldn't do it this way, but there can be more than one folder containing the same file (hardlinks).
> Your player scans your library and indexes/sorts it however you'd like.
Which means the concepts of files and folders becomes immaterial. If a music player is only interfacing with a database of music metadata it doesn't matter how the bytes on disk are organized.
There's a reason there's been 30+ years of file systems trying to tack on database functionality (BeFS, WinFS, etc) or over the top metadata indexing (Spotlight, Lucene, etc) to file systems. The files and folders abstraction is not sufficient for non-technical users in many cases.
The music player isn't the only thing interfacing with those files. Backups do. Network file shares do. Pendrives, dedicated music players, and children's toys that can load music do. The player changes over the years (winamp, VLC, amarok, clementine, jellyfin, etc.). Sometimes "apps" go wonky and the only way to fix them is to "clear user data", which is opaque, and you'd rather control that/be more selective.
I don't really care how the player stores its metadata (the secondary indexes it makes after the scan), but I don't want it mucking with the original data, which I've had and will continue to have far longer than the player. Files in a known format (e.g. .flac) offer a standard, common interface for storing that data that's easy to organize and exchange across computers.
Google drive also shows what a world where people don't use folders looks like: I can never find documents at work without a link even when I have an idea of what I'm trying to search for. Folders at least push the user to do some organization. GDrive happily encourages you to do none.
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)
Seems to me we very rapidly arrive at records or entities.
We see both these days in databases.
Entities show up in CAD and simulation. Records show up in business tools of various kinds.
All require a schema and serious dependencies flow from there.
In CAD, for example, the database schema can change quite dramatically from version to version of the same software tool. And all this makes writing plug in tools or anything really painful.
And forget exchanging native data between systems. STEP exists for that, and O God help you on a bigger project involving any old data
The thing about files is they are basically EASY.
And easy, when looking at where we are going, matters. A lot.
Files can exist on pretty much anything. Paper tape, mag tape, all sorts of media, up to advanced storage tech.
Databases are a different story.
I am not convinced we are anywhere rear being ready for that huge leap.
And I would normally say "forward" but on this?
Nope!
It would be a huge mess requiring we toss just about everything we have in use today
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.
It does and I managed it recently. It was painful.
I had to pair, or at least I think I did. Was fetching a file. off a flip phone. Doing these things without "file" gets weird quick.
I also seem to recall an awesome Bluetooth control panel applet I used a few times in Windows XP.
At the time I had a pretty spiffy Moto flip phone. It could be the computer keyboard, handle audio play and record and more.
Pretty sure that all came from the phone driver. I do recall also using the computer in reverse the same way when the display was badly damaged. I could make phone calls, dialing with the computer and in general use the phone taped to the back of my laptop screen.
aw. it hurts my brain to think about those days somehow. An awesome panel must be BlueSoleil. There were Microsoft XP SP2 stack that were stable but featureless, Toshiba stack with (IIRC)SCMS-T DRM support, WIDCOMM stack that show up on search now but I had no experience with - apparently tied to specific dongles, and the IVT BlueSoleil stack with the orange sun floating against dark blue background.
BlueSoleil was by far the most feature complete, and, as far as my interests back then were concerned, required for Wiimote on Windows. It was (not really)available as trialware but interoperability wasn't guaranteed so you would have had to pull dongle lottery until you hit a product with reasonably stable build of BlueSoleil if you had in mind a specific task to do in Bluetooth.
Fun times... things do feel less robust these days. Software was much better tested back then.
Yeah that seems familiar. One night on business travel, I decided to just play with the setup and really thought highly of it all.
Then some years passed, I got a Blackberry Curve, then a Note 4 and by the time I looked back at Bluetooth. I HATED IT. Still do, though I am grudgingly working through basics, phone call, play audio, etc and the whole time looking at my still wire capable hardware thinking "not yet"
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.
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.
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.)
Transferring files between a phone and a computer was a real use case, but since wireless usb was "exactly like regular usb but no wires" it wasn't any easier to set up file transfer than regular usb (harder, actually, since you had to do the wireless bonding), and wired usb would charge your phone battery while the files transferred whereas wireless usb would drain it.
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
Which is also way way easier to do than all the existing solutions: create a folder on the computer, add the computer to the phone, share the folder with the phone. Anything you want to share goes in the folder.
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.
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.
What I responded to was "wirelessly transferring files between a phone and a computer", assuming that I am the user at both ends of the transfer.
If I want to share something with someone else, there's a "File Sharing" section in phone's settings that enables anonymous WebDAV sharing, and it works fine too. There's Bluetooth OBEX too, but that one's fiddly.
> They worked - you really could get USB 2.0 full rate connections wirelessly and we had some neat demos.
TFA mentions that contemporary users of these things didn't get anywhere near Hi-Speed USB speeds. The author's present-day testing agrees with these reports, finding that at least one device's maximum performance was just barely better than USB FullSpeed.
If you were seeing 480Mbit performance with the hardware you were doing demos with, what went wrong between the demo table and the finished product?
The product in the article I think it said came from 2006? Not based on the chips I worked on, anyway.
Just like early wifi, there were several companies working on wireless usb chips at the time, and performance could vary a lot depending on who's product you bought, and when.
The "ripcord 2" chips (mentioned) definitely could do 480Mbps at short range. I worked on the design of the next generation after that (equal performance,
but lower-cost/lower-power-consumption), which never made it to the commercial market.
"What happened" was the combination of the product/ market mismatch I mentioned above (like, the wireless laptop dock was cool for a demo, but it didn't charge your laptop battery like a regular wired dock would, so it wasn't actually practical for daily use) so we didn't have enough revenue to self- sustain, and the "great recession" meant investment dried up and we eventually just ran out of money.
Staccato merged with a different wireless usb startup to try to delay the inevitable, and then tried to "pivot" to something profoundly stupid and I bailed at that point. (They did an internal demo of the new "product". It was maybe the worst tech demo I've ever seen. I was out 2 weeks later. I think the company dragged on for maybe another year.)
I think it could. If wireless charging docks has been common at the time, the upgrade to "now your wireless charger can do data sync too" is a straightforward improvement.
Unfortunately, at the time there was only one phone that had wireless charging built in (Palm Pre). I know our sales and marketing did try to engage with them on getting wireless usb into "the next version" of the Pre, but nothing came of it. I don't know the details.
At this point wifi is ubiquitous enough that a new version of wireless usb would have a hard time competing with it though.
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.
Yes, it will move the hot air, but typically the temperature of the chip is substantially higher than the ambient air inside the enclosure (be it a backpack or a laptop shell or anything else.) Furthermore, even if the backpack is 100% sealed, by raising its temperature you significantly increase the amount of heat that the backpack rejects.
A quick Google says that the Oculus DK1 used ~3W, and you can easily find a fan that uses a fraction of a watt to move a reasonable amount of air, so this would probably have worked out.
Fans reduce sensible heat because humans have evaporative cooling.
A backpack is pretty much a closed system and chips use convective cooling.
Adding a fan won’t create a positivee pressure gradient between the backpack and outside world but will add 3 or more watts of heat to the closed system.
Did you even read my comment? I have designed cooling systems professionally and I can assure you that is how things work :) Not trying to be rude, but your comment is incorrect in several ways.
I'll make this very simple: The hot chip is warmer than the ambient air because the rate of heat transfer from the chip to the air is low. A fan will increase the rate of heat transfer, thus decreasing the temperature of the chip and increasing the temperature of the air in the backpack. It will also increase the rate of heat transfer from the backpack air to the backpack, which will increase the rate of heat transfer from the backpack to the environment.
Notably, the fan would help even if the backpack was a magic closed system (which it is not; put a 100W computer and a 1kWh battery into it, open ten hours later, and you will not have anywhere near 1kWh of heat.) But why would it help in a closed system? Because the chip does not care about the total energy in the system, the chip cares about the peak chip temperature. The chip will always be the hottest thing in the backpack, but the delta in temperature between the chip and the air can be quite large. Indeed, in practice, for "natural convection" (no fan), this dT between the chip and the air is considerable. When you add a fan ("forced convection") you shrink that dT substantially.
Same thing for fans in a desktop case, a laptop case, or on a graphics card. They cool down the CPU / GPU / desk to case even when said computer is in a closed room.
Hadn’t thought of it this way, but it’s kind of obvious when you think of it. Would most likely have helped.
Thank you. I learned something fundamental from your comment that I did not know prior. Well, maybe I did, but how I think about it makes it harder to reason about.
Whatever, it is easier to see for me now. Lol
Seeing the benefit of the fan in terms of increased heat transfer to everything the air touches is easy. Full stop.
Heat is a fascinating thing. I can really recommend trying to visualize it and "playing around" with it in your daily life to get a stronger intuition for things. Pay attention to the thermal conductivity of the things around you and how that "feels": aluminum or copper extremely high, other metals high, plastics and woods low, fabrics and foams very low. Notice how evaporating water is very powerful at cooling things down, and how condensing water can warm things up. Notice how a small hot object cools slowly but a larger one can reject the same amount of heat very fast. Inspect the back of your fridge, or the inside of an A/C, and understand what's going on and where the energy is.
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.
Interestingly, the 2017 Essential Phone used wireless USB for the data communication to its magnetically-attached/powered modular accessories. (Of which the only released one was a 360° camera.)
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.
To the aithor : careful, on one picture at least you blacked out the human-readable PIN of a device, but forgot to black out the corresponding barcode right below
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.
> Connecting over radio requires pairing, that is very frustrating when it doesn't work.
Everything's frustrating when it doesn't work.
> Connecting over radio requires pairing
This is a solved problem, plagued by technology fragmentation. You could very well save the necessary information for discovery and pairing onto an NFC tag and use that to access the network (further authentication might happen, if configured).
This is basically never done on WiFi because you cannot assume a client host has a NFC reader (let alone proper code handling the tag and the information).
But it's done in the world of bluetooth: some big-name headsets (Sony IIRC) can do bluetooth connection negotiation via NFC. You activate the feature (dedicated button), tap your phone and off you go. No pin, no pairing annoyances.
My point being that it cannot be frustrating if it doesn't exist.
> This is a solved problem
Tell that to my airpods that connect to the wrong device (so I need to manually go connect to them most of the time) and to my phone that doesn't automatically connect to my airpods when it is already connected to my watch.
Granted, I want wireless between my phone, watch and headset. But I wouldn't call it a solved problem.
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.
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.
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).
What happens with that "absolute position relative to some arbitrary 0,0 picked by the mouse" when the user picks the mouse up off the table/pad/etc. and repositions it (i.e., they hit the edge of the pad and now "re-center" to continue moving left (or right) on screen). The mouse loses its 0,0 point reference as soon as it is picked up.
It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer.
That's not how mouse input works though, right? If I move my mouse cursor to 10,10, and then pick up the mouse and set it down somewhere else, it's still at coordinates 10,10. You don't need the mouse's physical absolute position, but just the cursor position (which is the sum of all the relative movements)
My reply was referring to @tehbeard's suggestion that the mouse could be modified to send absolute coordinates instead, and I was pointing out a reason why that modification would not work out so well.
> It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer.
And those "how I would have designed a wireless mouse protocol" guys are back at the square one.
That sounds like a software problem to me, not one that requires a hardware solution. There is nothing in what you describe that cannot be performed through bluetooth packets.
I am not sure which dongles make these corrections, but my experience with dongles is worse than bluetooth. Typically, a mouse is very close to the bluetooth antenna of a computer, and I have not really experienced any sort of connection issues due to missing packages etc. In contrast, I have had tons of issues with usb dongles due to usb interference.
No, mice sensors are far from being SoTA linear encoders. They return approximate instantaneous movements somehow when read request is received. Mouse controller chips(USB or RF or Bluetooth) pack and report up the movements, that's it.
(psa: none of Chinese ADNS-2610 clones have the raw pixel output debug command. Maybe security implications or maybe something else, either way, mouse-as-microscope hacks don't work on sensors extracted from e-wastes)
In all the years I've used wireless dongled mice, I've never had an issue. And all my stuff is bottom of the barrel unbranded from eBay or Amazon.
Bluetooth mice and keyboards always have trouble pairing, or there's input lag, or sometimes I can't use them to wake the computer. And if you ever want to hold a startup key...
Nintendo Wii Remote used almost completely bare standard HID over Bluetooth Classic and it just worked flawlessly. It needed Wiimote aware apps and special procedures for use with non-Wii devices but it had none such problems(I've had those too) in gaming. It could wake up consoles too.
The problem is in 5W1Hs between combinations of (Windows, PC, Bluetooth), not the protocol. How should pairing keys be retained, etc.
Yeah the cross-platform situation makes things hard, but in a way it's the protocol's fault if it's hard to agree on things.
Also, I really remember Wiimotes failing to pair a lot of the time, but it was so long ago that I could be wrong. All I know for sure is last time I was at someone's house and they wanted to play Switch, it took like 10 minutes to get the controllers set up, but most of that was bad UI.
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.
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.
Some things are difficult to do with a Bluetooth keyboard: you cannot do anything before the OS is booted, such as changing BIOS settings, installing an OS, or choosing a GRUB boot entry. There are workarounds (buying a Bluetooth adapter that can act as a HID proxy) but for me this is enough of a reason to not want to rely on Bluetooth.
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.
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.
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.
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.
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.
The downside is that need hub and its app to talk from phone to device. Matter using IP means phone can talk directly to device. Thread is separate network and needs bridge, but that can be simpler and generic. Thread/Matter use uncountable IPv6 space.
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.
Which is interesting that nobody has made USB over IP. That over WiFi would be useful for high speed. That over Thread might replace low level Bluetooth.
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.
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).
It may be worth articulating the Bluetooth headset specifically as the one-ear little clip headset executives and IT staff seemed to use to answer calls.
Remember companies like jawbone?
I vaguely remember a cultural stereotype of bmw drivers driving aggressively and wearing Bluetooth headsets. [edit: this is the clip https://youtu.be/UqfAMvXpSw4?t=25 from top gear of jeremy clarkson wearing a bluetooth headset in sunglasses in a bmw, supposedly from topgear season 10, episode 10]
Yes... there is a very interesting generational thing going on here.
Bluetooth headsets were very popular among a certain market segment (business people who made a lot of phone calls), but saw very little adoption outside of that. At that time, you often had to buy an expensive business grade phone to get bluetooth functionality.
Then once Bluetooth was common in cheaper phones, we see a completely different market segment (students at schools) rapidly adopting bluetooth for a completely different usecase (file sharing). It's hard to find two market segments that are more isolated from each other.
I don't think file sharing could have ever driven bluetooth to mass adoption on its own, partly because companies always overlook what school students are doing with technology. But mostly because the file sharing usecase required mass deployment of the technology before it could take off.
When I was in high school, I had a palm PDA with IrDA that could do file sharing. But did I ever use it for file sharing? No, because nobody else had devices with IrDA. IrDA never hit the market saturation it needed to be actually useful, so there never was much demand for it (despite the hardware being really cheap, especially compared to a dedicated bluetooth radio)
Bluetooth headsets worked as a killer app in those early days, because a single BMW driver could buy both a high-end phone with bluetooth and a headset from the cellphone store and get the complete experience. It worked without market saturation.
Jabra! In all seriousness the blackberry Bluetooth earpiece was the killer app (hardware / device).
BlackBerry HS-655 Bluetooth Headset
Worked perfectly paired with a bb.
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
> 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.
All of the BT+wifi chips I’ve worked with require active initialization of each feature; you have to signal the chip (over i2c or SPI or whatever) with what kind of BT operations you want.
No BT stack in your product, no BT radio initialization, no BT/wifi multiplexing. At least in the (admittedly limited) chips I’ve worked with.
> 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?
It is happening because it works the way that is most useful to most people. The number of people who want to use bluetooth earbuds with a different microphone is line noise in the consumer market.
Implementing special requirements is always inconvenient for users because no B2C wants to risk bad the-microphone-didn’t-work reviews, customer returns, and support tickets.
Nevermind coordinating with arbitrary USB microphone latency…I’ve got one with 250ms of it.
> It is happening because it works the way that is most useful to most people. The number of people who want to use bluetooth earbuds with a different microphone is line noise in the consumer market.
I don't think you have any idea what you're saying. The scenario I'm describing is when you want to use a bluetooth headset that includes a microphone. Using a different microphone is how you solve the problem.
I have never had a microphone problem with a bluetooth headset. They all always just work until something mechanical breaks through use.
If I had an issue, wired headphones seem a simpler solution than changing the bluetooth standard and more likely to work than wishing manufacturers changed their devices.
So, the standard defines behavior that is obviously pathological, actively working against the needs of all users. But because it's already codified, it's a bad idea to change it?
Works for my needs.
If it didn't, I'd use wires.
Or something else.
it happens because bluetooth profile for audio+microphone uses different codecs and has less bandwidth, due to being used for realtime communication.
the bluetooth audio streaming profile enables more codecs, but only playback, and allows significantly higher latency that you wouldnt accept on a call
> and allows significantly higher latency that you wouldnt accept on a call
That latency is also a millstone. We can do much better, but the standard lags and implementations lag even more.
My personal bluetooth ear clips do something much worse than adding latency - if they're not currently playing something, and a sound is supposed to come through, they omit the beginning of the sound while they get ready to become active or whatever it is they're doing.
Just delaying the sound and playing all of it would be a big improvement.
(Though that would fail badly for watching videos. That's something that uses 'headphones' mode anyway - why is latency OK there? It isn't.
My ear clips do add some latency, a noticeable amount, when I'm watching a video with mpv, and I adjust that by altering the A/V sync setting. They don't do the same thing when I'm watching something on youtube. I'd like to know what's going on there.)
well you wont get any argument from me that things could be significantly better.
> why is latency OK there? It isn't.
well.. if you listen to music, you probably dont care too much, but if you're talking to someone, you do.
whats much worse is also that latency is not constant.
The absolute madness that is Bluetooth pairing between cars and cellphones is wild. If I get into my car and it decides to randomly pair with my wife's phone (who is inside the house) and I drive off, the whole infotainment system is locks up and dies until I get to my destination and turn off the car.
What car do you drive? Then I make sure to not buy it
Mine connects and starts playing silently, and you need to press play and pause on the headunit to make it make sound. Every two months or so it fails to connect to the phone and needs a complete forget and repair to happen. Toyota unit and iphone.
My partner's hearing aid connects (via some radio protocol) to a device that then connects via bluetooth. Unfortunately, it presents itself as a headset, which causes... problems. For Android, they have to use an app from the play store that presents itself as an audio device and then sends that to the 'headset'.
Except for the "headphone" versus "headset" mode dichotomy that is inherent to Bluetooth, all those other issues are due to stupid product decisions that most OSes do to themselves independently on the same way.
If you use Linux + KDE, you can still use any microphone or headphone, many at the same time, or in whatever mode you want.
Linux + KDE user here.
It used to work on kde/plasma 5 at some point. And after a minor version update it stopped working.
Now the mic of my headset doesn't work because KDE insists that only the high quality sound output without mic is available. The mic + low quality output is gone from the settings.
Lucky for me this update also brought proper handling of the stereo positioned noise cancelling microphones on my thinkpad. So now I can actually enjoy the luxury of built-in microphones that work. Until the day it wont I guess.
if you use pipewire it works fine both in plasma 5 and 6.
but the audio quality in the sound + mic profile is very poor, the codec is only meant for speech
I am using pipe wire. The option to select the handset mode is gone! I can only select the various output codecs with my increasing quality. But not the mic & output mode. It's gone from the list...
Wow brings back memories when this used to be a problem on gnome like five years ago.
> If you use Linux + KDE, you can still use any microphone or headphone, many at the same time, or in whatever mode you want.
This doesn't really seem to respond to the problem. The problem is that I'd like to use a single bluetooth device that includes earpieces and a microphone. That doesn't work, because of the headphone-headset mode dichotomy. As I replied to another comment, using multiple devices would be a solution to the problem. It wouldn't be an example of the problem that I want solved.
Bluetooth is apparently incapable of simply delivering an audio stream to the earpieces while accepting one from the microphone. This is a baffling design. The assumption appears to be that there will never be more than one source of audio for output. But that's crazy.
obligatory xkcd: https://xkcd.com/2055/
Except this isn't a problem of trying to manage multiple connections. Bluetooth can't even handle maintaining a single connection between two devices.
Bluetooth was the main way to transfer music from dumbphone to a dumbphone
The ironic thing is the Bluetooth ignored it's audio use as much as possible for as long as possible. They wanted it to be used for tracking shoppers in stores...
how to use a phone in car without headset / bluetooth to talk legally?
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?
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.
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.
At 9600bps. Almost every device supported 115200 - that would cut it down to to 72 seconds. And as I mentioned - pictures were often small (20-30kbytes) back in the day - that's barely 1-2 seconds at 115200. And the later 4Mbps speeds would move that megabyte in 2 seconds flat.
You were pretty unlucky. The basic bitrate was 9.6kbps but much higher speeds were common.
Mostly just SNR issues.
My guess is just that Bluetooth and Wi-Fi came first, and when wireless USB entered the party, there wasn't a real need for it, as most of its use cases were already covered by Bluetooth and Wi-Fi.
It maybe could have worked with better marketing, but convincing potential customers to change something that works (somewhat, BT wasn't without issues) is hard. That's why we are keeping abominations like cigarette lighter sockets in cars even though they often can't even light cigarettes anymore. It is already well established and it works well enough as a power outlet.
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.
In my opinion, for computers, wireless mouse (and eventually keyboards) was one of the killer app that showed pushed for Bluetooth to be common in computers and laptops. "Not needing a dongle" was a huge added value compared to the private radio protocol of manufacturers
Largest phone manufacturers of the time (Ericsson and Nokia) supporting and developing it surely helped.
Maybe the low-power feature of Bluetooth helped it, such as with the Bluetooth LE (Low Energy) spec that with the way "services" and "characteristics" are defined that it allows for extremely low power consumption when no read-operation is done and thus the Bluetooth radio power can be minimized. Also, the 2.4 GHz band of Bluetooth is inherently less power consuming than the higher frequency band of Wireless USB.
But I guess the other problems may have been due to as the OP article brings up about it being in a different frequency communication band. Bluetooth on the other hand shares the same frequency band as Wi-Fi (2.4 GHz (which is also the OG Wi-Fi frequency band)). Thus for PC and mobile device OEMs, it is one less antenna to integrate. Furthermore, the higher frequency of the band would have made through-walls and further-distance communication less reliable. In this context, one of the few cool applications of wireless USB would've been a wireless keyboard or mouse (but this is coming from someone who is working on an OEM computer keyboard and mouse).
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.
And as far as I know, Wi-Fi and Bluetooth didn't have frequency given to them. They instead used frequencies that were already available for unlicensed use.
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.
Bluetooth took off because it was easiest path to do wireless headsets when handsfree driving laws passed.
> 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 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.
Folder / Directory
I most frequently use the latter, directory when I am talking files and filesystems.
Most people return that with "folder", and I am sure that has to with my learning about these things happening where "directory" was the norm.
I have been educating people about files when I bump into ones that do not know much. The abuses are real and growing. Nice comment.
> is what product people want to believe
It's quite clear what you never had to explain why 'only looking at a pictures/photos on the Internet' wasted the mobile traffic.
Were you born with the knowledge that a video takes more space than a photo that takes more space than a text?
Or is it rather that you consider yourself one of the few people smart enough to memorise it? I find that very condescending.
I don't believe that one needs 3 postdocs to understand it. In fact, I do happen to have explained it quite a few times, and I don't remember anyone not understanding it.
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.
> 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.
The worst is photos, because the search abstraction really breaks there. On modern iPhones, it's still a pain in the ass to organize photos in such a way where you can come back later and find them. I'm still in the "scroll through the timeline until you spot it" phase.
Machine Learning is making this better, but ideally albums or folders wouldn't be such a pain in the ass to actually use in day-to-day life.
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.
You index it with btrees just like everything else. You distinguish it by configuring which folders to watch. You react to events with inotify. You don't give your music app write permission to your library. It only needs to write its indexes and playlists. All of your other questions become irrelevant; you delete the files you mean to delete with your file manager. In practice, music is small and storage is cheap, so deleting seems like a weird use-case for an application dedicated to music. I still have files that have been migrating across computers for 25 years.
What if I want to look at a list of composers, but the folder structure is by artist?
What about playlists?
The limitation of the folder is that there’s only one.
Your player scans your library and indexes/sorts it however you'd like. I think this is how basically every player with a library function works? Like jellyfin loads my library in the same structure I've had it for 20 years, and it gives me various ways to view by name, artist, release date, rating, etc. and builds search indexes. I just point it to the roots of my libraries.
I said it needs a place to write playlists (or write access to your playlist folder(s)).
I wouldn't do it this way, but there can be more than one folder containing the same file (hardlinks).
> Your player scans your library and indexes/sorts it however you'd like.
Which means the concepts of files and folders becomes immaterial. If a music player is only interfacing with a database of music metadata it doesn't matter how the bytes on disk are organized.
There's a reason there's been 30+ years of file systems trying to tack on database functionality (BeFS, WinFS, etc) or over the top metadata indexing (Spotlight, Lucene, etc) to file systems. The files and folders abstraction is not sufficient for non-technical users in many cases.
The music player isn't the only thing interfacing with those files. Backups do. Network file shares do. Pendrives, dedicated music players, and children's toys that can load music do. The player changes over the years (winamp, VLC, amarok, clementine, jellyfin, etc.). Sometimes "apps" go wonky and the only way to fix them is to "clear user data", which is opaque, and you'd rather control that/be more selective.
I don't really care how the player stores its metadata (the secondary indexes it makes after the scan), but I don't want it mucking with the original data, which I've had and will continue to have far longer than the player. Files in a known format (e.g. .flac) offer a standard, common interface for storing that data that's easy to organize and exchange across computers.
Google drive also shows what a world where people don't use folders looks like: I can never find documents at work without a link even when I have an idea of what I'm trying to search for. Folders at least push the user to do some organization. GDrive happily encourages you to do none.
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)
If we don't have files, then what?
Seems to me we very rapidly arrive at records or entities.
We see both these days in databases.
Entities show up in CAD and simulation. Records show up in business tools of various kinds.
All require a schema and serious dependencies flow from there.
In CAD, for example, the database schema can change quite dramatically from version to version of the same software tool. And all this makes writing plug in tools or anything really painful.
And forget exchanging native data between systems. STEP exists for that, and O God help you on a bigger project involving any old data
The thing about files is they are basically EASY.
And easy, when looking at where we are going, matters. A lot.
Files can exist on pretty much anything. Paper tape, mag tape, all sorts of media, up to advanced storage tech.
Databases are a different story.
I am not convinced we are anywhere rear being ready for that huge leap.
And I would normally say "forward" but on this?
Nope!
It would be a huge mess requiring we toss just about everything we have in use today
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.
It does and I managed it recently. It was painful.
I had to pair, or at least I think I did. Was fetching a file. off a flip phone. Doing these things without "file" gets weird quick.
I also seem to recall an awesome Bluetooth control panel applet I used a few times in Windows XP.
At the time I had a pretty spiffy Moto flip phone. It could be the computer keyboard, handle audio play and record and more.
Pretty sure that all came from the phone driver. I do recall also using the computer in reverse the same way when the display was badly damaged. I could make phone calls, dialing with the computer and in general use the phone taped to the back of my laptop screen.
Today, it is simpler, and far less robust.
aw. it hurts my brain to think about those days somehow. An awesome panel must be BlueSoleil. There were Microsoft XP SP2 stack that were stable but featureless, Toshiba stack with (IIRC)SCMS-T DRM support, WIDCOMM stack that show up on search now but I had no experience with - apparently tied to specific dongles, and the IVT BlueSoleil stack with the orange sun floating against dark blue background.
BlueSoleil was by far the most feature complete, and, as far as my interests back then were concerned, required for Wiimote on Windows. It was (not really)available as trialware but interoperability wasn't guaranteed so you would have had to pull dongle lottery until you hit a product with reasonably stable build of BlueSoleil if you had in mind a specific task to do in Bluetooth.
Fun times... things do feel less robust these days. Software was much better tested back then.
Yeah that seems familiar. One night on business travel, I decided to just play with the setup and really thought highly of it all.
Then some years passed, I got a Blackberry Curve, then a Note 4 and by the time I looked back at Bluetooth. I HATED IT. Still do, though I am grudgingly working through basics, phone call, play audio, etc and the whole time looking at my still wire capable hardware thinking "not yet"
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.
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.
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.)
Transferring files between a phone and a computer was a real use case, but since wireless usb was "exactly like regular usb but no wires" it wasn't any easier to set up file transfer than regular usb (harder, actually, since you had to do the wireless bonding), and wired usb would charge your phone battery while the files transferred whereas wireless usb would drain it.
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.
Which is also way way easier to do than all the existing solutions: create a folder on the computer, add the computer to the phone, share the folder with the phone. Anything you want to share goes in the folder.
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.
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.
What I responded to was "wirelessly transferring files between a phone and a computer", assuming that I am the user at both ends of the transfer.
If I want to share something with someone else, there's a "File Sharing" section in phone's settings that enables anonymous WebDAV sharing, and it works fine too. There's Bluetooth OBEX too, but that one's fiddly.
> They worked - you really could get USB 2.0 full rate connections wirelessly and we had some neat demos.
TFA mentions that contemporary users of these things didn't get anywhere near Hi-Speed USB speeds. The author's present-day testing agrees with these reports, finding that at least one device's maximum performance was just barely better than USB FullSpeed.
If you were seeing 480Mbit performance with the hardware you were doing demos with, what went wrong between the demo table and the finished product?
The product in the article I think it said came from 2006? Not based on the chips I worked on, anyway.
Just like early wifi, there were several companies working on wireless usb chips at the time, and performance could vary a lot depending on who's product you bought, and when.
Here's an article about us I found from 2008.
https://www.eetimes.com/staccato-communications-ultra-wideba...
The "ripcord 2" chips (mentioned) definitely could do 480Mbps at short range. I worked on the design of the next generation after that (equal performance, but lower-cost/lower-power-consumption), which never made it to the commercial market.
"What happened" was the combination of the product/ market mismatch I mentioned above (like, the wireless laptop dock was cool for a demo, but it didn't charge your laptop battery like a regular wired dock would, so it wasn't actually practical for daily use) so we didn't have enough revenue to self- sustain, and the "great recession" meant investment dried up and we eventually just ran out of money.
Staccato merged with a different wireless usb startup to try to delay the inevitable, and then tried to "pivot" to something profoundly stupid and I bailed at that point. (They did an internal demo of the new "product". It was maybe the worst tech demo I've ever seen. I was out 2 weeks later. I think the company dragged on for maybe another year.)
Ah. Nothing went wrong between the demo table and the finished product; the author is working with Mk. 1 products.
Thanks much for the additional detailed background information. Sorry to hear about the slow demise of your former employer.
> but you still have to plug the device into a cable at some point
That may explain why I can't find a 5 Gbps wireless USB extender for my work web cam.
https://hardwarerecs.stackexchange.com/questions/18983/wirel...
But today we can have wireless charge too, would that change things?
I think it could. If wireless charging docks has been common at the time, the upgrade to "now your wireless charger can do data sync too" is a straightforward improvement.
Unfortunately, at the time there was only one phone that had wireless charging built in (Palm Pre). I know our sales and marketing did try to engage with them on getting wireless usb into "the next version" of the Pre, but nothing came of it. I don't know the details.
At this point wifi is ubiquitous enough that a new version of wireless usb would have a hard time competing with it though.
USB over QI wireless would be great.
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.
Great post, but it's a bit disorienting. As I said in another post here:
> This is like a transmission from an alternate universe where the mice I used for decades didn't exist.
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
I have a similar pet peeve with Miracast, though sources say over ethernet support was added to later Windows versions.
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.
Seems like you could spend a smidgen of that battery power on a fan, no?
We later replaced the backpack with a home-made open mesh grid onto which the receiver was strapped.
But that just bought us a bit more run time without actually solving anything.
From what I’d gathered at the time, it was a common issue with products that relied on that specific chip, and I doubt most shared our use case.
[I am not a physicist]
Wouldn’t a fan in a backpack just move hot air including the heat of its motor?
Yes, it will move the hot air, but typically the temperature of the chip is substantially higher than the ambient air inside the enclosure (be it a backpack or a laptop shell or anything else.) Furthermore, even if the backpack is 100% sealed, by raising its temperature you significantly increase the amount of heat that the backpack rejects.
A quick Google says that the Oculus DK1 used ~3W, and you can easily find a fan that uses a fraction of a watt to move a reasonable amount of air, so this would probably have worked out.
Fans reduce sensible heat because humans have evaporative cooling.
A backpack is pretty much a closed system and chips use convective cooling.
Adding a fan won’t create a positivee pressure gradient between the backpack and outside world but will add 3 or more watts of heat to the closed system.
Did you even read my comment? I have designed cooling systems professionally and I can assure you that is how things work :) Not trying to be rude, but your comment is incorrect in several ways.
I'll make this very simple: The hot chip is warmer than the ambient air because the rate of heat transfer from the chip to the air is low. A fan will increase the rate of heat transfer, thus decreasing the temperature of the chip and increasing the temperature of the air in the backpack. It will also increase the rate of heat transfer from the backpack air to the backpack, which will increase the rate of heat transfer from the backpack to the environment.
Notably, the fan would help even if the backpack was a magic closed system (which it is not; put a 100W computer and a 1kWh battery into it, open ten hours later, and you will not have anywhere near 1kWh of heat.) But why would it help in a closed system? Because the chip does not care about the total energy in the system, the chip cares about the peak chip temperature. The chip will always be the hottest thing in the backpack, but the delta in temperature between the chip and the air can be quite large. Indeed, in practice, for "natural convection" (no fan), this dT between the chip and the air is considerable. When you add a fan ("forced convection") you shrink that dT substantially.
Very interesting, thanks!
Same thing for fans in a desktop case, a laptop case, or on a graphics card. They cool down the CPU / GPU / desk to case even when said computer is in a closed room.
Hadn’t thought of it this way, but it’s kind of obvious when you think of it. Would most likely have helped.
Thank you. I learned something fundamental from your comment that I did not know prior. Well, maybe I did, but how I think about it makes it harder to reason about.
Whatever, it is easier to see for me now. Lol
Seeing the benefit of the fan in terms of increased heat transfer to everything the air touches is easy. Full stop.
You're very welcome!
Heat is a fascinating thing. I can really recommend trying to visualize it and "playing around" with it in your daily life to get a stronger intuition for things. Pay attention to the thermal conductivity of the things around you and how that "feels": aluminum or copper extremely high, other metals high, plastics and woods low, fabrics and foams very low. Notice how evaporating water is very powerful at cooling things down, and how condensing water can warm things up. Notice how a small hot object cools slowly but a larger one can reject the same amount of heat very fast. Inspect the back of your fridge, or the inside of an A/C, and understand what's going on and where the energy is.
Well, your comment is timely. I am part of a project about to embark on some highly specialized thermal simulation.
I will be doing exactly what you suggested to me here.
Didn't help you had to flip the signal up-down-up to get it working.
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.
Interestingly, the 2017 Essential Phone used wireless USB for the data communication to its magnetically-attached/powered modular accessories. (Of which the only released one was a 360° camera.)
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.
To the aithor : careful, on one picture at least you blacked out the human-readable PIN of a device, but forgot to black out the corresponding barcode right below
That’s the MAC address barcode
...the MAC address barcode was below the MAC address, the PIN barcode was below the PIN.
They fixed it now.
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.
> Connecting over radio requires pairing, that is very frustrating when it doesn't work.
Everything's frustrating when it doesn't work.
> Connecting over radio requires pairing
This is a solved problem, plagued by technology fragmentation. You could very well save the necessary information for discovery and pairing onto an NFC tag and use that to access the network (further authentication might happen, if configured).
This is basically never done on WiFi because you cannot assume a client host has a NFC reader (let alone proper code handling the tag and the information).
But it's done in the world of bluetooth: some big-name headsets (Sony IIRC) can do bluetooth connection negotiation via NFC. You activate the feature (dedicated button), tap your phone and off you go. No pin, no pairing annoyances.
> Everything's frustrating when it doesn't work.
My point being that it cannot be frustrating if it doesn't exist.
> This is a solved problem
Tell that to my airpods that connect to the wrong device (so I need to manually go connect to them most of the time) and to my phone that doesn't automatically connect to my airpods when it is already connected to my watch.
Granted, I want wireless between my phone, watch and headset. But I wouldn't call it a solved problem.
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.
Slightly off-topic, but I'm totally in favor of letting HDMI die the slow and agonizing death it's supposed to die.
https://arstechnica.com/gadgets/2024/02/hdmi-forum-to-amd-no...
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.
Because once you have more than a handful running at once (say an apartment building) the interference causes them all to fail
This is like a transmission from an alternate universe where the mice I used for decades didn't exist.
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.
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.
> 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).
What happens with that "absolute position relative to some arbitrary 0,0 picked by the mouse" when the user picks the mouse up off the table/pad/etc. and repositions it (i.e., they hit the edge of the pad and now "re-center" to continue moving left (or right) on screen). The mouse loses its 0,0 point reference as soon as it is picked up.
It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer.
That's not how mouse input works though, right? If I move my mouse cursor to 10,10, and then pick up the mouse and set it down somewhere else, it's still at coordinates 10,10. You don't need the mouse's physical absolute position, but just the cursor position (which is the sum of all the relative movements)
> That's not how mouse input works though, right?
No, mouse input data does not work that way.
My reply was referring to @tehbeard's suggestion that the mouse could be modified to send absolute coordinates instead, and I was pointing out a reason why that modification would not work out so well.
> It could send a "reset 0,0" packet of some form in this case, but now reception of that packet becomes critical to continuing to properly communicate motion to the attached computer.
And those "how I would have designed a wireless mouse protocol" guys are back at the square one.
That sounds like a software problem to me, not one that requires a hardware solution. There is nothing in what you describe that cannot be performed through bluetooth packets.
I am not sure which dongles make these corrections, but my experience with dongles is worse than bluetooth. Typically, a mouse is very close to the bluetooth antenna of a computer, and I have not really experienced any sort of connection issues due to missing packages etc. In contrast, I have had tons of issues with usb dongles due to usb interference.
No, mice sensors are far from being SoTA linear encoders. They return approximate instantaneous movements somehow when read request is received. Mouse controller chips(USB or RF or Bluetooth) pack and report up the movements, that's it.
(psa: none of Chinese ADNS-2610 clones have the raw pixel output debug command. Maybe security implications or maybe something else, either way, mouse-as-microscope hacks don't work on sensors extracted from e-wastes)
In all the years I've used wireless dongled mice, I've never had an issue. And all my stuff is bottom of the barrel unbranded from eBay or Amazon.
Bluetooth mice and keyboards always have trouble pairing, or there's input lag, or sometimes I can't use them to wake the computer. And if you ever want to hold a startup key...
Nintendo Wii Remote used almost completely bare standard HID over Bluetooth Classic and it just worked flawlessly. It needed Wiimote aware apps and special procedures for use with non-Wii devices but it had none such problems(I've had those too) in gaming. It could wake up consoles too.
The problem is in 5W1Hs between combinations of (Windows, PC, Bluetooth), not the protocol. How should pairing keys be retained, etc.
Yeah the cross-platform situation makes things hard, but in a way it's the protocol's fault if it's hard to agree on things.
Also, I really remember Wiimotes failing to pair a lot of the time, but it was so long ago that I could be wrong. All I know for sure is last time I was at someone's house and they wanted to play Switch, it took like 10 minutes to get the controllers set up, but most of that was bad UI.
Clarification, the dongled mice are cheapo, the Bluetooth mice are expensive and still bad.
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.
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.
I mean, they aren't putting raw HID packets on the air, they're encapsulated within another protocol that does handle reliable retransmission.
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.
Some things are difficult to do with a Bluetooth keyboard: you cannot do anything before the OS is booted, such as changing BIOS settings, installing an OS, or choosing a GRUB boot entry. There are workarounds (buying a Bluetooth adapter that can act as a HID proxy) but for me this is enough of a reason to not want to rely on Bluetooth.
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.
The dongles are common because they predate widespread availability of bluetooth equipped laptops and desktops by about a decade…00’s versus 10’s.
Dongles are also plug and play (no pairing dance) and more readily support multiple devices on the same computer.
Bluetooth has gotten better over the years but it doesn’t provide a meaningfully better alternative for the it-aint-broke consumer mouse market.
I bought a new mouse recently and intentionally got a dongle one, not that it was hard to find. It's just better.
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.
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.
Bluetooth is so terrible that you can't even use headphones with high quality audio while also using their microphone. In 2025. It's pathetic.
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.
In certain cases, plug-and-play interfaces outperform wireless mediums.
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.
The downside is that need hub and its app to talk from phone to device. Matter using IP means phone can talk directly to device. Thread is separate network and needs bridge, but that can be simpler and generic. Thread/Matter use uncountable IPv6 space.
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.
Thread is low power like Zigbee even though it is IPv6 over the same radio. Implementing IP stack takes very little these days.
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.
Which is interesting that nobody has made USB over IP. That over WiFi would be useful for high speed. That over Thread might replace low level Bluetooth.
I personally don't think this comment would be so outrageously wrong. I for one thought about making a Wi-Fi headphone for couple times.
"depending on executive and blood alcohol level" is such a good throwaway joke
Wireless USB died before it could fulfill its destiny: hydrophone → RF → USB
I bought wirelessharddisk.com hoping it would be a thing.
Impressive. It sounds to be a thorough summary of Wirth's work.
Awesome. Now do WiMax.
[flagged]
In the coming age of AI we can do our own communications protocols and leave behind the horrible bt and wifi implementations. Right? :D