The Tech Blog

Bluetooth Core 7.0 was released earlier this month, and its biggest headline was High Data Throughput (HDT). Bluetooth LE can now reach 7.5 Mb/s instead of 2 Mb/s, almost 4x faster at the PHY level. I was curious how they achieved this without widening the existing channels. Let’s discuss.

The familiar LE 2M radio uses GFSK, encoding one bit in each symbol. HDT uses π/4-QPSK, 8PSK and 16QAM to carry two, three or four bits per symbol. It adds forward error correction to recover from some radio errors. All five HDT rates, 2, 3, 4, 6 and 7.5 Mb/s, use 2 million symbols per second.

The faster radio still needs efficient packets. Conventional BLE data packets carry up to 251 bytes of payload. HDT introduces a format supporting up to 8,175 bytes per payload. It can combine up to four payloads in one packet, split them into blocks and selectively retransmit blocks damaged by interference.

There is a subtle radio problem with longer packets. As you move, reflected signals change, and the receiver’s phase estimate can drift. HDT’s long-packet format inserts training sequences within a transmission so the receiver can update its estimates. Its control header uses robust coding and indicates the data rate, which can change on each packet.

So what does the 7.5 Mb/s claim mean in practice? Nordic tested two prototype chips transferring a 2 MB file. HDT7.5 took about 4 s, compared with 12 s on conventional LE 2M. Actual throughput was around 3.8 Mb/s, because of the usual headers & acknowledgements overheads.

I see this helping with smartwatch data sync, firmware updates, smart glasses and future high-resolution audio. HDT keeps compatibility with existing BLE links, but the faster modes need new hardware. Even Bluetooth 7.0 devices are not guaranteed to support HDT, and the top two HDT rates are optional. So it might be a while before things really move.

I am rarely blown away by tech demos online, but Colsto’s OSINT experiment made me want to share this. . He located a blurry security-camera video of trees to within roughly 100 m using faint aircraft noise in the background.

So, OSINT stands for Open-Source Intelligence, which is analysis of publicly available information. Here, it starts with the Doppler effect. As a propeller aircraft approaches and moves away, its tonal sound changes pitch. On a spectrogram, which plots frequency against time, this produces a curved trace. Its shape depends on aircraft speed and how close it passed the microphone.

The idea is to work backwards. Known flight tracks let you predict curves at candidate microphone locations and compare them with the audio. A 3km sound path takes around 9s at 343m/s. Ground elevation, altitude, turns and changes of speed all affect the timing and shape.

Colsto found two aircraft signatures 920s apart. Searching historical US flight data, he discarded places where speed, distance or timing did not match. Silence between events removed places where other flights should have been heard. Matching both curves identified one site, verified in Street View.

Colsto hasn’t released his original code, although independent implementations have already appeared. The approach can be reproduced, but its reliability on random recordings remains unproven.

Now imagine a city like Mumbai, where the airport in the city handles roughly 950 flights daily. More flights offer more clues, but jets, traffic and reflections from buildings complicate the signal. Technically any long enough random recording will allow you to pinpoint a location. I can see how this technology could be misused, but the engineering behind it is genuinely mind-blowing. Please search online to watch the whole video if you have the time. It’s very good.