How a Viking King Ended Up in Your Earbuds

Bluetooth: From Runic Initials to 1600 Hops Per Second

Harald Bluetooth Gormsson

The Radio: 79 Channels and a Lot of Jumping

The Piconet: One Clock to Rule Them

Pairing and Bonding: The Handshake

Legacy Pairing (Bluetooth 2.0 and earlier)

Secure Simple Pairing (Bluetooth 2.1+)

Two Stacks, One Name: Classic vs BLE

BLE Advertising: Shouting Into the Void

GATT: The API Layer

Profiles: Why Your Car Can't Display Album Art

The Audio Codec Situation

Why Bluetooth Audio Has Latency

Coexistence: Sharing the 2.4 GHz Band

The Part That Gets Me

Further Reading Reading time: ~15 minutes You paired your headphones this morning. Your phone found them, you tapped "connect," and music started playing. That felt like nothing happened. But between that tap and the first beat of audio, your phone and your headphones agreed on an encryption key, negotiated a codec, established a frequency-hopping pattern across 79 radio channels, and started jumping between those channels 1,600 times per second -- all in a band shared with your WiFi router, your microwave, and every other wireless device in the building. The protocol that makes this work is named after a Viking king who's been dead for a thousand years. That's not a joke. It's one of the best naming stories in the history of technology. In the mid-900s AD, Denmark was a mess. Warring tribes, fractured loyalties, no unified rule. Into this stepped Harald Gormsson, who became King of Denmark around 958 AD and later King of Norway. He's remembered for two things: unifying the warring Danish tribes under a single kingdom, and converting the Danes to Christianity. His nickname was "Bluetooth" -- most likely from a conspicuously dead tooth that had turned dark blue, though some historians argue it derives from the Old Norse blatand meaning "dark chieftain." Harald's real legacy was political unification. He took factions that refused to talk to each other and brought them under one protocol. One kingdom. One set of rules. Fast-forward about a thousand years to 1997. Intel engineer Jim Kardach was at a bar in Toronto with Sven Mattisson from Ericsson, and they were wrestling with a problem: IBM, Ericsson, Nokia, Toshiba, and Intel all had competing short-range wireless standards. Each company wanted their own protocol to win. Nobody was budging. Kardach had been reading Frans G. Bengtsson's historical novel The Long Ships -- a book about Vikings and the reign of Harald Bluetooth. The parallel was too perfect. Harald unified warring Scandinavian tribes. This new protocol needed to unify warring tech companies. Kardach proposed "Bluetooth" as a temporary codename while the consortium figured out a real name. The consortium was called the Bluetooth Special Interest Group (SIG). They considered names like "RadioWire" and "PAN" (Personal Area Network). Focus groups were run. Marketing decks were produced. But by the time the final name was due, nothing had cleared trademark searches. "Bluetooth" had already stuck in the press and in internal documentation. The placeholder became the name. And the logo? It's not an abstract design. It's a bind rune -- two runes from the Younger Futhark alphabet merged into a single glyph. ᚼ (Hagall, Harald's H) and ᛒ (Bjarkan, his B), overlaid on each other. Harald's initials, in the alphabet of his own era, sitting on billions of devices a millennium later. A 10th-century Viking king named the protocol in your pocket. Every time you see that angular logo on a speaker or a pair of earbuds, you're looking at runic initials from before the Norman Conquest of England. If like me you went to school in England, you've already met his family — you just don't know it. Harald Bluetooth's son was Sweyn Forkbeard, who invaded England and was crowned king on Christmas Day 1013. Sweyn's son was Cnut the Great — the king every English school kid learns about, and a simple misspelling away from class laughter.1 Cnut ruled England, Denmark, and Norway simultaneously — the North Sea Empire, the largest domain in northern Europe. The man who named your wireless protocol is the grandfather of the most powerful Viking king who ever sat on the English throne. Harald himself never invaded England — he was busy unifying Denmark and making the Danes Christian. But his dynasty did. The Jelling Stone he erected — "Denmark's baptismal certificate," still standing in Jutland — declared that he "won for himself all of Denmark and Norway and made the Danes Christian." His grandson won England too. If you watched the TV show Vikings hoping to spot him, you were about 80 years too late — the show ends around 878 AD, and Harald didn't reign until 958. Vikings: Valhalla starts in 1002, about 16 years after he died. He fell right into the gap between both shows. The Viking age had a lot of Haralds; this is the one that matters for your earbuds. I think about this every time I pair my headphones. I can't help it. Bluetooth operates in the 2.4 GHz ISM band -- the same unlicensed slice of radio spectrum used by WiFi, baby monitors, cordless phones, and microwave ovens. This band is crowded. Catastrophically crowded. The reason Bluetooth works at all in this environment is a technique borrowed from military radio: frequency hopping spread spectrum (FHSS). The 2.4 GHz band is divided into 79 channels, each 1 MHz wide, spanning from 2.402 GHz to 2.480 GHz. A Bluetooth connection doesn't sit on one channel. It hops between all 79 channels in a pseudo-random sequence, changing frequency 1,600 times per second. That's a new channel every 625 microseconds. Why does this help? Because interference is usually narrowband. Your microwave blasts a few MHz of the 2.4 GHz band with noise. A WiFi router parks on a 20 MHz or 40 MHz chunk. But if your Bluetooth connection is only on any given frequency for 625 microseconds before jumping elsewhere, a microwave blast on channel 34 only corrupts 1 out of 79 hops. The other 78 get through clean. The protocol retransmits the missed packet on the next visit to a clean channel. You never notice. The hopping sequence is determined by the master device's clock and address. Both devices in a connection know the sequence. To an outside observer without the sequence, the signal looks like noise spread across the entire band -- which is the entire point. FHSS was originally developed for military communications precisely because it makes signals hard to intercept or jam. It's the same pattern as the internet itself — ARPANET was a military network designed to survive partial destruction, and now you use its descendant to order takeout. Military technology has a habit of ending up in your living room. Bluetooth Low Energy (BLE) does things differently -- it uses only 40 channels, each 2 MHz wide, and hops at a different rate. But the principle is identical: don't sit still, don't get jammed. When Bluetooth devices connect, they form a piconet -- a tiny ad-hoc network with one device running the show. The device that initiates the connection becomes the central device (historically called "master" -- the Bluetooth SIG updated the terminology in 2020). The device that accepts becomes the peripheral (formerly "slave"). The central's clock becomes the reference clock for the entire piconet. All frequency hopping is synchronized to it. A single piconet supports up to 7 active peripherals. That's not arbitrary -- peripheral addresses are 3 bits, giving you 8 slots, one of which is the central. Additional devices can be "parked" -- they stay synchronized to the piconet clock but can't send or receive data until unparked. Up to 255 devices can park on a single piconet. What happens when a device needs to be in two piconets at once? Your phone connected to your car stereo and your smartwatch, for instance? It participates in a scatternet -- overlapping piconets where a device acts as peripheral in one and central in another, time-slicing its radio between the two. This is why audio sometimes stutters briefly when your smartwatch gets a notification while you're streaming music to your car. The phone's radio just timesliced away from your A2DP stream for a moment to handle the watch's piconet. Before two devices can talk, they need to establish trust. This is pairing -- the initial key exchange. Once paired, the keys are stored so reconnection is instant. That storage is called bonding. The pairing process has evolved across Bluetooth versions, but the core problem is always the same: two devices that have never met need to agree on a shared secret over a radio link that anyone nearby can listen to. Both devices display or require a PIN code. You type the same PIN on both sides (or one side has a fixed PIN, like "0000" for simple devices). The PIN seeds the key generation. This is crude. A 4-digit PIN has only 10,000 possible values. An attacker recording the pairing exchange can brute-force it in seconds. SSP introduced four models: "Just Works" exists because headphones don't have screens or keyboards. There's no way to display a confirmation number on a $30 pair of earbuds. The trade-off is deliberate: slightly lower security in exchange for the pairing experience not requiring a device with a display. For most consumer audio, this is the right call. For medical devices or payment terminals, it's absolutely not -- which is why those use Numeric Comparison or OOB. Classic Bluetooth and Bluetooth Low Energy (BLE) are fundamentally different protocol stacks that happen to share a name, a radio band, and a logo. Classic Bluetooth (formally "BR/EDR" -- Basic Rate/Enhanced Data Rate) was designed for continuous data streams. Audio. File transfer. Serial port emulation. It keeps a persistent connection, and its power consumption reflects that. Bluetooth Low Energy (BLE, originally marketed as "Bluetooth Smart") was introduced in the Bluetooth 4.0 specification in 2010. It was designed from scratch for a different use case: devices that send tiny amounts of data infrequently and need to run on a coin cell battery for years. Fitness trackers. Temperature sensors. AirTags. The two stacks are so different that early Bluetooth 4.0 chips came in three varieties: Classic-only, BLE-only, and "dual-mode" chips that supported both. Your phone has a dual-mode chip. Your AirTag has a BLE-only chip. The fact that they both say "Bluetooth" on the box is a branding decision, not a technical statement. One of the most elegant things about BLE is that devices can broadcast data without ever pairing. A BLE device in advertising mode sends out small broadcast packets -- up to 31 bytes of data -- on three dedicated advertising channels (37, 38, and 39, deliberately spread across the band to avoid single-frequency interference). These packets go out at a configurable interval, anywhere from every 20 milliseconds to every 10.24 seconds. This is how your AirTag works. It never pairs with the phones that relay its location. It broadcasts a rotating identifier on advertising channels. Every iPhone in range passively picks up these advertisements as part of normal BLE scanning, encrypts the location with Apple's key, and relays it to the Find My network. The AirTag's battery lasts a year because it does almost nothing except advertise a few bytes every couple of seconds. This is also how Bluetooth beacons work in retail stores, museums, and airports. The beacon doesn't know or care who's listening. It advertises a UUID, and any app configured to listen for that UUID can react. The beacon is stateless. The intelligence lives on the receiver side. The advertising data is structured: each field has a type and a value. Common types include the device name, service UUIDs, manufacturer-specific data, and TX power level (which receivers use to estimate distance based on signal strength). Bluetooth 5.0 extended advertising to allow much larger payloads -- up to 255 bytes in the extended format -- enabling richer broadcasts without requiring a connection. When a BLE device does establish a connection (as opposed to passively advertising), the data exchange follows a structured protocol called GATT -- the Generic Attribute Profile. If you've ever worked with a BLE device programmatically, GATT is the API you talked to. GATT organizes data into a hierarchy: A BLE heart rate monitor exposes a Heart Rate Service. Inside that service is a Heart Rate Measurement characteristic that a connected phone can read or subscribe to for notifications. When the value changes, the peripheral pushes an update to the central without the central having to poll. The beauty of GATT is standardization. The Bluetooth SIG has defined hundreds of standard service and characteristic UUIDs. Any heart rate monitor from any manufacturer uses the same UUIDs for the same data. Your running app doesn't need a driver for each brand of chest strap -- it looks for service 0x180D and reads characteristic 0x2A37. The interoperability is baked into the protocol. Back in Classic Bluetooth territory, the concept of profiles defines what devices can actually do with their connection. A profile is a specification for a particular use case. The ones you interact with daily: That last one is why your car stereo might not display album art from your phone. AVRCP has multiple versions. Version 1.0 only supports play/pause/skip. Version 1.3 added track metadata (title, artist, album). Version 1.6 added album art. If your car's Bluetooth module implements AVRCP 1.3 and your phone sends 1.6 features, the car doesn't understand the album art data. Both sides negotiate down to the highest mutually supported version. This is the profile negotiation problem in miniature. Every "why doesn't X work with Y" Bluetooth complaint usually traces back to mismatched profile versions, not a fundamental incompatibility. When you stream music over A2DP, the audio must be compressed to fit through Bluetooth's bandwidth constraints. The codec doing that compression has a massive impact on what you hear. SBC (Sub-Band Codec) is the mandatory baseline. Every A2DP device must support it. It was designed in the early 2000s for the computational constraints of the era. It works. It's also noticeably worse than the source material at its default settings. SBC at the standard bitrate of 328 kbps sounds muddy in the highs and lacks spatial detail. It's the reason "Bluetooth audio sounds bad" became conventional wisdom in the 2010s. AAC is Apple's preferred codec. iPhones use AAC for Bluetooth audio by default. It sounds substantially better than SBC at the same bitrate, but its quality depends on the encoder implementation — and Android's AAC encoder has historically been worse than Apple's, making AAC-over-Bluetooth inconsistent across platforms. This is the kernel of truth behind every Apple user's claim that their audio sounds better than Android — but it's the encoder, not the platform. Pair high-end earbuds that support aptX or LDAC with an Android phone and the codec difference evaporates. The Bose QuietComfort Ultras on my desk don't care what Apple thinks about AAC. aptX is Qualcomm's proprietary codec family. aptX Classic targets "CD-like quality." aptX HD pushes to 24-bit/48kHz. aptX Adaptive dynamically adjusts bitrate based on connection quality. All require Qualcomm licensing and hardware support on both ends. LDAC is Sony's codec. It can push up to 990 kbps -- nearly three times SBC's standard rate. At its best, it approaches lossless quality over Bluetooth. At its worst (in congested RF environments), it drops to 330 kbps and falls back to SBC-like quality. LDAC is open-sourced and available in Android's AOSP. LC3 (Low Complexity Communication Codec) is the new standard, part of the Bluetooth 5.2 LE Audio specification. LC3 achieves better subjective quality than SBC at half the bitrate. The Bluetooth SIG's own listening tests showed that subjects preferred LC3 at 160 kbps over SBC at 345 kbps. LC3 is mandatory for LE Audio devices, which means it will eventually become the universal baseline, replacing SBC's 20-year reign. The latency you notice when watching video with Bluetooth headphones -- lips moving before words arrive -- comes from multiple sources stacking up. The audio codec needs a buffer of samples to compress. SBC's frame size is 128 samples. At 44.1 kHz, that's about 2.9 milliseconds per frame. But the codec usually batches multiple frames before transmission. The Bluetooth baseband adds its own buffering. Classic Bluetooth's connection interval is typically 7.5 milliseconds, meaning data can only be sent at those intervals. The data then crosses the radio link, gets received, buffered, decoded, and sent to the DAC. Total end-to-end latency for SBC over Classic Bluetooth is typically 150-250 milliseconds. That's noticeable for video. Some phones compensate by delaying the video to match. Some don't. aptX Low Latency claims under 40 ms, but both sides need to support it. LE Audio changes the game. LC3 was designed for lower latency from the start. LE Audio's isochronous channels provide guaranteed timing (unlike Classic Bluetooth's retransmission-based reliability). The target for LE Audio is 20-30 milliseconds end-to-end -- below the threshold where most people perceive audio-visual desynchronization. LE Audio also brings Auracast -- broadcast audio where one source can stream to unlimited receivers simultaneously. Think public venue announcements, silent disco, hearing aid loops. One transmitter, every listener. Bluetooth and WiFi both live in the 2.4 GHz ISM band. They are neighbors who didn't choose each other. The fact that they coexist at all is a small engineering miracle. WiFi (802.11b/g/n in 2.4 GHz) uses wide channels -- 20 MHz or 40 MHz. A single WiFi channel covers 20 to 40 of Bluetooth's 79 narrowband channels. WiFi transmits at higher power (up to 100 mW vs Bluetooth's typical 1-2.5 mW). By rights, WiFi should obliterate Bluetooth. It doesn't, because of Adaptive Frequency Hopping (AFH). Introduced in Bluetooth 1.2, AFH lets a Bluetooth connection detect which channels are occupied by WiFi or other interference and remove them from the hopping sequence. If channels 20-40 are blasted by a WiFi router, the Bluetooth piconet hops across the remaining 59 channels instead. The hop rate stays the same -- 1,600 per second -- but the pattern avoids the known-bad frequencies. On devices that have both a WiFi and Bluetooth radio (which is every phone, laptop, and tablet), a more sophisticated mechanism kicks in: coexistence signaling. The WiFi and Bluetooth controllers share a physical wire or a bus connection. When the WiFi radio is about to transmit, it signals the Bluetooth controller, which can defer its own transmission by a fraction of a millisecond. And vice versa. This is why your phone's WiFi and Bluetooth don't constantly interfere with each other even though the antennas are millimeters apart. The 5 GHz and 6 GHz WiFi bands (802.11ac/ax) don't overlap with Bluetooth at all. If your WiFi network runs exclusively on 5 GHz, there's zero contention. This is the simplest fix for the person who Googles "Bluetooth interference WiFi" -- move your WiFi to 5 GHz and the two protocols never see each other. I keep coming back to the naming. In 1997, Jim Kardach was reading a novel about a Viking king who unified Scandinavian tribes. He was sitting across from engineers whose companies couldn't agree on a wireless standard. He saw the parallel and threw out a name as a placeholder. That placeholder outlived every serious marketing attempt to replace it. It outlived IBM's exit from the consortium. It outlived the original standard it was created for -- Classic Bluetooth is slowly being superseded by BLE and LE Audio, but the name persists. The runic bind-rune logo persists. Harald Bluetooth Gormsson, dead for over a thousand years, has his initials on more devices than any human in history. Harald unified tribes. Bluetooth unifies devices. The metaphor was perfect in 1997, and it's even more perfect now that the protocol connects 5 billion devices annually. I wonder what he'd make of it. A 10th-century king who couldn't read Latin, who ruled a country smaller than South Carolina, whose greatest technological achievement was a runestone — and his initials are on 5 billion devices. His name is spoken more often now than it was during his own reign. Not by subjects or chroniclers, but by people saying "turn on Bluetooth" while fumbling with their car stereo. He'd probably understand the unification part. Getting Ericsson and Nokia and Intel to agree on a protocol isn't so different from getting Jutland and Zealand to stop fighting. Both require convincing proud, territorial powers that the shared standard serves them better than the private one. Both require someone stubborn enough to hold the table together until the deal is done. The frequency hopping, the piconets, the GATT profiles — he wouldn't understand any of it. But the politics? A king who unified warring tribes would recognise a standards body instantly. Same game. Same stakes. Smaller swords. Similar beards. Not bad for a placeholder. I'm writing a book about what makes developers irreplaceable in the age of AI. Join the early access list → Naz Quadri pairs his headphones every morning and thinks about a Viking king every single time. He blogs at nazquadri.dev. Rabbit holes all the way down 🐇🕳️. The one who (supposedly) tried to command the tide to prove to his flattering courtiers that even kings can't control the sea. Cnut wasn't trying to prove he had power over the sea. He was proving the opposite — demonstrating to sycophantic courtiers that royal power has limits. The story is usually told backwards. A thousand years of getting the point wrong. Sounds like a naming committee. ↩ Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Numeric Comparison: both devices display a 6-digit number, you confirm they match. Uses Elliptic Curve Diffie-Hellman (ECDH) for the key exchange. Secure against passive eavesdropping and man-in-the-middle attacks. - Passkey Entry: one device displays a number, you type it on the other. For devices where one side has a keyboard but no display. - Out of Band (OOB): the pairing information is exchanged via a different channel -- NFC tap, QR code scan. Secure because the attacker would need to compromise both channels. - Just Works: ECDH key exchange with no user confirmation. Protects against passive eavesdropping but not against active man-in-the-middle attacks. - Profile: a collection of services that define a use case (e.g., "Heart Rate Profile") - Service: a group of related data points, identified by a UUID (e.g., "Heart Rate Service" = 0x180D) - Characteristic: an individual data value within a service (e.g., "Heart Rate Measurement" = 0x2A37) - Descriptor: metadata about a characteristic (e.g., units, valid range, notification settings) - A2DP (Advanced Audio Distribution Profile): stereo audio streaming. This is what your headphones use for music. - HFP (Hands-Free Profile): phone calls. Mono audio, microphone, call control. This is why call audio sounds worse than music -- it's a different profile with a different codec at a lower bandwidth. - HID (Human Interface Device): keyboards, mice, game controllers. Uses the same report format as USB HID, which is why Bluetooth keyboards can send the same scan codes. - SPP (Serial Port Profile): emulates an RS-232 serial port. Beloved by embedded engineers. Gives you a simple bidirectional byte stream between two devices. - AVRCP (Audio/Video Remote Control Profile): play, pause, skip, volume. And -- in newer versions -- track metadata like title, artist, and album art. - Bluetooth Core Specification — the full spec from the Bluetooth SIG. Start with Volume 1 (Architecture & Terminology Overview) before diving into the radio or L2CAP layers. - The Long Ships — the Frans G. Bengtsson novel that Jim Kardach was reading when he proposed "Bluetooth" as a placeholder name. A Viking adventure that's far better than it has any right to be. - Nordic Semiconductor DevZone — BLE Tutorial — Nordic makes the chips inside most BLE peripherals. Their tutorial walks through advertising, connections, GATT profiles, and power optimization with real hardware examples. - Wireshark Bluetooth Capture Setup — how to sniff Bluetooth traffic with Wireshark. Requires a compatible sniffer dongle, but seeing actual HCI packets demystifies the protocol faster than any spec chapter. - Bluetooth LE Audio and the LC3 Codec — the Bluetooth SIG's overview of LE Audio, including the LC3 codec that replaces SBC. Lower bitrate, better quality, and the foundation for Auracast broadcast audio. - The one who (supposedly) tried to command the tide to prove to his flattering courtiers that even kings can't control the sea. Cnut wasn't trying to prove he had power over the sea. He was proving the opposite — demonstrating to sycophantic courtiers that royal power has limits. The story is usually told backwards. A thousand years of getting the point wrong. Sounds like a naming committee. ↩