4 ms·

Let me be perfectly blunt. This idea won't work, because Bluetooth is an atrocious protocol. If it would work, a native app would have successfully implemented

Let me be perfectly blunt. This idea won't work, because Bluetooth is an atrocious protocol. If it would work, a native app would have successfully implemented it, and taken the world by storm. The problem isn't accessibility to JavaScript developers. The problem is a crummy radio protocol. Putting it inside Firefox doesn't solve bad design issues.

diggan 8y ago
Thank you, that's valid criticism. While bandwidth for Bluetooth is not great, it'll work for small amount of information exchange and at the very least discovery of other methods for communication like ad-hoc wifi. I'd be happy to hear about more details why Bluetooth is crummy as well.
- crankylinuxuser 8y ago
  1. You need exact timing between devices for the freq hopping to get to the right freq If for some reason the OFDM ack isn't gotten, then neither side can understand the timings to actually communicate. So you end up with non-pairing hell. This especially happens between different "specs" of BT. 2. Raises noise floor for whole BT carveout If they had 2 control channels, and then moved the comms to an agreed upon channel, this would never be an issue. Look at how Simplex ham radio works - do announce on a channel, and move elsewhere when agreed upon. But whatever you do, don't just blanket the whole channel (or all of 2m) for 'reasons'. And heavier bandwidth BT can take over multiple channels. This isn't easy, but nowhere near as difficult/stupid as what it is now. 3. Multiple incompatible BT specs BT used to be a IEEE spec. Not any more. And there's more than 7 or so major versions. Oh, and many are incompatible with each other. What's that XKCD about "Standards"? :( 4. arcane pairing sequences Again, pairing is crazy complex. I'll have to post the actual IQ data and show a comparison between FM (88MHz-108MHz), 2m amateur radio (144MHz-148MHz), analog TV, 802.11BGN wifi, and what BT looks like in various states. To sum it up, "They're doing it wrong".
  - baybal2 8y ago
    Actually, from 1.0 and on, bt specwriters did everything to balance the complexity of implementing bt in silicon with protocol's performance. Fragile OFDM? Any other rock solid narrowband interference mitigation techniques that are not electronically complex? No dedicated control channel? Remember, BT just like wifi implies operation along non-cooperative 3rd parties.
crankylinuxuser 8y ago
> This idea won't work, because Bluetooth is an atrocious protocol. I would agree. I was at our hackerspace last night working with a SDR transceiver ADALM-Pluto and tuned in to the 2.4 802.11bgn spectrum. Its a clean swath of radio for comms. Its easy to establish a connection. And the bandwidth graph is cleanly edged. Then I look at the Bluetooth part of 2.4GHz... Holy crap. Each device frequency hops like a rabid rabbit. And when you look for a device, over the radio it looks like its just dumping beacons everywhere in the hopes that something responds. Just viewing a device with bt connected, and looking for a device makes it clear that their scheme of BT is -bad-. Its a bad protocol, bad detection strategy, and bad usage of spectrum (yay raise noise floor for everyone).

diggan 8y ago

Thank you, that's valid criticism. While bandwidth for Bluetooth is not great, it'll work for small amount of information exchange and at the very least discovery of other methods for communication like ad-hoc wifi. I'd be happy to hear about more details why Bluetooth is crummy as well.

crankylinuxuser 8y ago
1. You need exact timing between devices for the freq hopping to get to the right freq If for some reason the OFDM ack isn't gotten, then neither side can understand the timings to actually communicate. So you end up with non-pairing hell. This especially happens between different "specs" of BT. 2. Raises noise floor for whole BT carveout If they had 2 control channels, and then moved the comms to an agreed upon channel, this would never be an issue. Look at how Simplex ham radio works - do announce on a channel, and move elsewhere when agreed upon. But whatever you do, don't just blanket the whole channel (or all of 2m) for 'reasons'. And heavier bandwidth BT can take over multiple channels. This isn't easy, but nowhere near as difficult/stupid as what it is now. 3. Multiple incompatible BT specs BT used to be a IEEE spec. Not any more. And there's more than 7 or so major versions. Oh, and many are incompatible with each other. What's that XKCD about "Standards"? :( 4. arcane pairing sequences Again, pairing is crazy complex. I'll have to post the actual IQ data and show a comparison between FM (88MHz-108MHz), 2m amateur radio (144MHz-148MHz), analog TV, 802.11BGN wifi, and what BT looks like in various states. To sum it up, "They're doing it wrong".
- baybal2 8y ago
  Actually, from 1.0 and on, bt specwriters did everything to balance the complexity of implementing bt in silicon with protocol's performance. Fragile OFDM? Any other rock solid narrowband interference mitigation techniques that are not electronically complex? No dedicated control channel? Remember, BT just like wifi implies operation along non-cooperative 3rd parties.

crankylinuxuser 8y ago

> This idea won't work, because Bluetooth is an atrocious protocol. I would agree. I was at our hackerspace last night working with a SDR transceiver ADALM-Pluto and tuned in to the 2.4 802.11bgn spectrum. Its a clean swath of radio for comms. Its easy to establish a connection. And the bandwidth graph is cleanly edged. Then I look at the Bluetooth part of 2.4GHz... Holy crap. Each device frequency hops like a rabid rabbit. And when you look for a device, over the radio it looks like its just dumping beacons everywhere in the hopes that something responds. Just viewing a device with bt connected, and looking for a device makes it clear that their scheme of BT is -bad-. Its a bad protocol, bad detection strategy, and bad usage of spectrum (yay raise noise floor for everyone).