Hacker News new | ask | show | jobs
by killlameme99 2628 days ago
Haven't read the whole paper, just the first couple pages and some bits here and there, however this appears to give enough high level details to get a good idea of what exactly is happening:

Problem: BLE and WiFi cannot directly communicate with eachother because standard WiFi hardware cannot decode BLE packets (and vice versa).

Solution: Fortunately, WiFi and BLE work in the same band. The issue is they have entirely different bandwidths, methods of multiplexing, data rates, etc. WiFi transmits on a number of 300ish Khz sub-channels with a total bandwidth of 20 Mhz, while BLE just uses a single couple MHz channel. There are other hardware issues but this is a larger one.

The "doppler shift" comes in here because both WiFi and BLE have been made specifically to combat the doppler effect (or other small offsets), and so both enable firmware to control the frequency offset of the carrier with a decent sized bandwidth (about 150 kHz but a lot of different numbers get thrown around, depends on the hardware that's used).

WiFi hardware allows firmware to detect where in it's 20 MHz band a carrier is being detected, and blue tooth allows firmware to adjust the carrier signal's frequency offset. So by modulating the carrier frequency of the BLE data can be bit banged out, and bit banged in by looking at the center frequency of the strong signal being detected on the WiFi end. There's a bunch of complications on top of this because of BLE frequency hopping and other jankiness, but I think this is the just of it.

BLE cannot just look at how much the WiFi signal is shifted to read data from WiFi, because the WiFi signal bandwidth is too large and no matter how shifted it is there's always a strong signal everywhere in the couple MHz wide BLE channel. However, the WiFi preamble just so happens to look slightly different to BLE depending on the frequency shift applied to the WiFi carrier, because different WiFi sub-bands overlap the bluetooth band with depending on WiFi frequency offset. This way, the WiFi can communicate to the BLE device. Again there seem to be a lot of complications here since this is exceedingly janky, but it manages to work. This bit banging process abuses some very specific pieces of the BLE hardware, seems a lot more complicated than the previous one. The paper of course explains this in more detail but much later.

Result: Communication is possible with these changes, however because of how hacky it is, it doesn't have great rates. The paper says 6.5 kbps in interference free and 1.59 kbps in a "crowded" environment. For reference, this is about 10 times slower than dial up (56 kbps). So no, you're probably not going to be streaming on bluetooth with this hack quite yet. This makes sense since you're sending data by modulating the carrier frequency using a method that's not meant to be updated by firmware nearly fast enough to send at a decent data rate.

Sorry if some of the details about WiFi and BLE are wrong, I don't know these protos very well and I'm just going off what I read in the paper and some quick googles.