Zune BT Console: Difference between revisions
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
All the cool kids know, “Zune is where its at”, but the whole Bluetooth thing is the next level. This collision of paradigms must be reconciled. My choice was to respect the integrity of the Zune ecosystem while bringing in the new hot topic. So I collected my options and evaluated them as follows: | All the cool kids know, “Zune is where its at”, but the whole Bluetooth thing is the next level. This collision of paradigms must be reconciled. My choice was to respect the integrity of the Zune ecosystem while bringing in the new hot topic. So I collected my options and evaluated them as follows: | ||
=Whys and Wherefores= | |||
There are already Zune mods/hacks for adding Bluetooth. Most are permutations on putting a commercial BT transmitter inside the Zune. These work, but I have a BT speaker with volume, play/pause and skip buttons. These functions can not “inform” the Zune to do anything through a common audio input only BT transmitter. The functions for the button do exist on the Zune and are incorporated in the IR remotes for Zune docks. This mean that a Zune in a dock, connected to a BT transmitter and in line of sight of the dock remote can perform the functions. But I don’t want to keep a remote and line of sight to perform what the speaker already has buttons for as well as headphones with similar buttons. | |||
My spin on the build is to use a BT transmitter that can trap the button functions and relay them to the Zune, via the dock. This means that if I emulate a dock remote based on the AVCRP signals trapped by the BT transmitter then mission accomplished. | |||
My first idea was to use the KCX_BT_Emitter and monitor the serial communications line for the signals and react appropriately. But the KCX doesn’t always show the signals on the serial line. After multiple ways of resetting the module, initializing the connection, and other strategies, it was not consistent. | |||
Next was to use an ESP32 and look for the signal. I found a library that already did what I wanted. I needed to make adjustments for my hardware choices. When I posted about my project, the author discussed some changes and update suggestions. | |||
Now I had the ability to send audio to BT devices and trap the signals from the buttons, I needed to supply directions to the dock. This would be done by emulating a dock remote. This method did not require any hardware changes to the Zune ecosystem hardware. It also allows functioning across the 3 generations of Zune docks and players. | |||
I realize that without the ESP32, this is simply using a BT transmitter and an IR LED bright enough to be seen through walls. And yet, this is a solution with self imposed restraints that allowed me to delve into BT and Zunes. I guess I just had an opportunity to learn and I took it. | |||
Revision as of 10:34, 9 September 2025

Introduction, Problem Statement and the Twist
The LVL1 Hackerspace in Louisville Kentucky has seen many mp3 players, cell phones and streaming services. But when I, Director of Legal Evil Emeritus, indulge in the Hack-a-Thons, I bring a Zune. And although there are many invasive hacks in wild, I thought I would attempt BT without damaging a device and adding the AVRCP functionality that the common BT fob does not add to the experience. To that end, this is my story/hack, and I am sticking to it.
The Story, Probably Apocryphal
All the cool kids know, “Zune is where its at”, but the whole Bluetooth thing is the next level. This collision of paradigms must be reconciled. My choice was to respect the integrity of the Zune ecosystem while bringing in the new hot topic. So I collected my options and evaluated them as follows:
Whys and Wherefores
There are already Zune mods/hacks for adding Bluetooth. Most are permutations on putting a commercial BT transmitter inside the Zune. These work, but I have a BT speaker with volume, play/pause and skip buttons. These functions can not “inform” the Zune to do anything through a common audio input only BT transmitter. The functions for the button do exist on the Zune and are incorporated in the IR remotes for Zune docks. This mean that a Zune in a dock, connected to a BT transmitter and in line of sight of the dock remote can perform the functions. But I don’t want to keep a remote and line of sight to perform what the speaker already has buttons for as well as headphones with similar buttons.
My spin on the build is to use a BT transmitter that can trap the button functions and relay them to the Zune, via the dock. This means that if I emulate a dock remote based on the AVCRP signals trapped by the BT transmitter then mission accomplished.
My first idea was to use the KCX_BT_Emitter and monitor the serial communications line for the signals and react appropriately. But the KCX doesn’t always show the signals on the serial line. After multiple ways of resetting the module, initializing the connection, and other strategies, it was not consistent.
Next was to use an ESP32 and look for the signal. I found a library that already did what I wanted. I needed to make adjustments for my hardware choices. When I posted about my project, the author discussed some changes and update suggestions.
Now I had the ability to send audio to BT devices and trap the signals from the buttons, I needed to supply directions to the dock. This would be done by emulating a dock remote. This method did not require any hardware changes to the Zune ecosystem hardware. It also allows functioning across the 3 generations of Zune docks and players.
I realize that without the ESP32, this is simply using a BT transmitter and an IR LED bright enough to be seen through walls. And yet, this is a solution with self imposed restraints that allowed me to delve into BT and Zunes. I guess I just had an opportunity to learn and I took it.