USB Going Wireless 237
NathanJ writes "Device Forge is running a technical whitepaper on wireless USB. The article states that 'Already there has been some progress with the definition of a WUSB specification with a targeted bandwidth of 480 Mbps. This specification maintains the same usage and architecture as wired USB with a high-speed host-to-device connection.' And that 'the WUSB host can logically connect 127 WUSB devices.' So what am I going to do with my Bluetooth desktop?"
Update Holy Deja vu batman... here is an earlier Slashdot article that I missed from 3 weeks ago. Oops.
Re:Your Bluetooth desktop? (Score:1, Informative)
Re:Your Bluetooth desktop? (Score:3, Informative)
It's really just a marketing phrase.
Re:I'd keep it (Score:2, Informative)
No. This did not happen for longest time. There is a reason for isochronous transfers where bandwidth is important. They have priority over bulk transfers where bandwidth is just secondary.
Of course most of the high bandwidth devices use Bulk transfers because of automatic error correction (ie. retransmission).
Bluetooth is heavily targeted for telephony. (Score:5, Informative)
Bluetooth is heavily targeted toward telephony applications.
One thing that "IP guys" are constantly missing the importance of is the need to deal with timing in streaming applications. (The telephone people missed it too, when they initially went digital, and spent decades fixing it up after the fact. Their latest generation - SONET - is orgznized around clocking. "Synchronous" is even the first word in the acronym.)
Basic idea is that, when you're sending a real-time stream at a constant sample rate, if you have a common timing reference at the transmitter and receiver things are a LOT simpler than if you have to infer the timing of the transmitter at the receiver. Doesn't matter if you propagate it with the signal or both ends get it from a common source by some complicated path - just get them clocked alike to make the endpoints' jobs enormously easier.
Voice signals, for instance, play out fine if the clocks at the two ends are synchronized, but have annoying clicks if not. These clicks can be cleaned up by adding heavy processing - which trashes FAX and high-speed modem signals. But that means adding a DSP (or equivalent computation) for uncompressed signals, or extra DSP work if you already having one doing compression. This takes power, at a premium in portable applications, and extra (or faster) silicon, which can raise costs. And even then the result is usually not as good as if the clocks were synchronized in the first place.
Phone companies synchronize nearly everything in their networks to a common clock, especially the 8,000/second sample rate of the A-to-D conversion of the voice signals, and distribute digitized voice (when uncompressed) as 64 kbit signals (8,000 8-bit samples per second.)
Bluetooth is organized around this. Time is broken up into 16,000 slots per second, with the master and the slaves taking turns - 8,000/second each. (What a conincidence that it's the voice sampling rate, eh?) The master sets the timing. The number of active slaves is limited, but a slave can extend the net to more active devices by becoming the master of a subnet. This makes little sense for net organization, but perfect sense if the slave is propagating timing from the master. Channel allocation within the net includes a fat general-purpose data channel plus three constant-rate bidirectional 64Kbit channels. (I.e. three phone calls.) A slave can participate in two separate nets - and can terminate all three 64K channels if in one net, or two of 'em if one is from each.
What this means is bluetooth is perfect for things like wireless headsets for cellphones. The cellphone provides a clock to the headset to set its sample rate, and the headset sends and plays out uncompressed audio. So the headset requires no DSP, little silicon, and little power. (The Bluetooth modulation scheme also makes for a simple, low-power, DSP-free radio.) The cellphone already has a DSP for compressing audio on its way to/from the net. It can in principle propagate network clocking to the handset, making things better end-to-end. Or it can just use its local clocking to make headset/DSP communication easier.
So Bluetooth makes design of cellphone audio peripherals nice. Cheaper, lower power, longer battery life, lighter weight, compared to any of the other schemes which don't propagate a phone-network or piconet-local timebase accessable beyond the network stack and/or require heavy DSP processing to work at all. Thus it's unlikely cellphones will be moving away from it any time soon - and when they do they'll probably move to something else that also propagates clocking. Since bluetooth can also handle a moderately-fast data link for WAN traffic, you get wireless internet connection throu
Re:Ummm... not quite (Score:3, Informative)
Scanners could easily be made the same way.
WUSB is a total waste; most useful purposes it could serve can already be done either by Bluetooth or by 802.11(a,b,g).
It's based on the disaster that is UWB (Score:2, Informative)
Basically UWB is a nasty piece of work that's being rammed through with corporate pressure and by lobby groups set up by manufacturers. Now that Intel has signed on and indicated it intends to make it ubiquitous, we're pretty much doomed. It seems to have passed certification in the US, but with any luck it won't pass in Europe. It'll hopefully go the way of broadband over powerlines - everyone finally figures out it's just a bunch of snake oil salesmen pedalling faulty goods.