A phone is a powerful music player. It is also a pocket-sized source of messages, maps, calls, and everything else. I wanted something simpler for a run: an iPod, my AirPods, and music.
The awkward gap in Apple’s ecosystem
The seventh-generation iPod nano was Apple’s last nano: a small, lightweight music player with Bluetooth. AirPods arrived years later. Both products carry Apple’s name, so it feels reasonable to expect them to work together.
On my tested setup, the AirPods Pro 2 paired with the 2012 iPod nano 7, and the earbuds’ stem controls could play, pause, and skip tracks. But no music came through.
That detail mattered. Pairing worked. The control channel worked. The audio stream did not.
This is not evidence that Apple deliberately blocked its earbuds from its own player. It is a compatibility bug in the nano’s Bluetooth audio path, exposed by newer earbuds. The nano is an older product with firmware that Apple no longer develops; the AirPods are newer. The gap is real, but the cause is technical rather than a deliberate product restriction.
Why I wanted to use an iPod for running
Running with a phone is practical when I need navigation or to stay reachable. For an ordinary run, though, carrying it can feel like bringing my whole connected life along just to listen to music.
An iPod gives me a more focused choice. The music is already on the device, and there are no notifications competing for attention. It is a small, distraction-free listening setup—and the nano is light enough to carry comfortably.
The obstacle was that the headphones I already used wirelessly would connect but not play audio. I wanted to understand why and find a way to make the combination useful again.
What was actually broken
Bluetooth audio is more than the initial connection. The nano and earbuds first pair, then establish an A2DP stream for stereo audio. A separate control profile, AVRCP, carries commands such as play, pause, and skip.
In the affected combination, AVRCP commands arrived, but the A2DP stream was rejected or muted by AirPods Pro 2. That split was a useful clue: it pointed away from a general Bluetooth-version mismatch and toward the audio stream itself.
The upstream blueth4w technical explanation traces the issue to the stream’s RTP timestamp. RTP timestamps tell the receiver where audio frames belong on the playback timeline. For the nano’s SBC audio, each frame contains 128 audio samples. The firmware advanced the timestamp by a duration measured in milliseconds instead of by the number of samples. Newer earbuds rely on that timing and stayed silent; some older earbuds appear to tolerate it.
The fix changes the timestamp increment to frames × 128 samples. It leaves the separate pacing calculation alone, so the device’s send timing is not inadvertently changed. This is a narrow correction to the audio stream—not a replacement Bluetooth stack and not a change to the AirPods.
How the fix runs on the nano
The Bluetooth code lives inside the nano’s encrypted firmware. The fix cannot simply be installed as an app or copied into the music folder. The upstream work uses the nano’s boot-time font-loading path to apply a small patch to the running firmware.
At a high level, the modified font contains a crafted glyph based on the nano’s own font. When the firmware renders text during startup, that glyph triggers a memory-write technique originally developed in the iPod research community. The payload writes the corrected timestamp instructions into the Bluetooth audio routine. It runs again after each power-on, so the correction is present before music playback starts.
The key change is small; getting it onto a device safely and repeatably is the harder part. Firmware versions, image packaging, and installation steps matter, and a bad firmware update can leave the device unusable. This is community firmware research, not an Apple-supported update.
Open source makes the fix reachable
The Bluetooth fix and low-level exploit work come from kilo2071’s blueth4w and earlier iPod research, including CUB3D’s ipod_sun. I built NanoPods on top of that shared work: it brings the research into a documented Windows workflow, with scripts to prepare and check the firmware package.
That is one of the strengths of open source. A fix does not have to come from the company that made the original product. One person can investigate the firmware, another can build on earlier exploit research, and someone else can turn those findings into steps that more people can follow. Each contribution has a clear place, and the result can be more useful than any one piece on its own.
AI also changed how quickly I could make progress. I used it as a research and development assistant to help understand unfamiliar firmware concepts, navigate the build and packaging workflow, and iterate on the PowerShell tooling and documentation. That made a small, specific problem easier to break down and move through quickly. The technical discovery and patch are still credited to the people who did that reverse-engineering work; AI helped me work with their findings and make the setup more approachable.
For me, that is a practical example of this moment in open-source software: people can combine existing research, their own motivation, and AI assistance to solve a problem that might otherwise remain too specialized or time-consuming to tackle alone. The important part is keeping the work inspectable—showing what changed, identifying what is tested, and giving credit to the people and projects it depends on.
The repository guides a user through obtaining Apple’s original firmware, building the patched payload in Ubuntu under WSL2, backing up the storage Windows exposes, packaging a custom update image, and installing it with Windows iTunes. The PowerShell helpers check expected inputs and refuse to overwrite existing output files. They do not silently download or redistribute Apple’s firmware or the patched image.
The project also calls out what those checks cannot prove. The storage backup covers only what Windows exposes; full hidden-firmware backup and restoration are not verified. A successful package check is not a guarantee that flashing is risk-free. Keeping the original firmware and a separate copy of music is still important.
What I tested—and what I haven’t
My confirmed setup is specific: a 2012 iPod nano 7, firmware 1.0.4 PC / build 37A40005, formatted as FAT32, paired with AirPods Pro 2 (USB-C edition). The patched build was produced with Ubuntu 24.04 in WSL2 and installed using native Windows iTunes. Audio worked before and after restarting the nano.
That is one successful configuration, not a promise for every nano revision, firmware, or Bluetooth headset. The 2015 revision uses different firmware, and this workflow does not claim to support it. The repository lists the exact tested setup and its limitations so others can make an informed decision.
A small player, made useful again
The goal was not to make the nano modern in every way. It was to keep one thing it already did well—play music—and remove the friction that made my wireless headphones unusable with it.
Now I can head out for a run with the music I chose, physical controls, and no phone in my pocket. NanoPods made that setup reproducible for me—and it is also a reminder that open research, clear documentation, and AI-assisted development can help turn a small personal annoyance into a solution others can inspect and build on.