| Project | Kenwood KRC-3006 CD Changer Emulator |
| Document type | Design Note |
| Status | Concept / Pre-Design |
| Revision | 0.1 |
| Date | 2026-03-09 |
| Dependency | Core changer protocol must be fully defined first |
This document captures the design intent, architecture, and button mapping strategy for Bluetooth audio integration into the KRC-3006 CD changer emulator project. This feature set is classified as a stretch goal — it does not affect or gate core protocol work and is not intended to move project milestones. Implementation should only begin after the changer protocol is fully defined and the emulator is confirmed stable.
The Raspberry Pi will function simultaneously as a CD changer emulator and a Bluetooth audio sink. The head unit will have no awareness of the Bluetooth layer — it will interact only with the changer protocol as normal. Audio source selection and routing will be handled entirely within the Pi's software stack.
The changer protocol supports up to 10 virtual discs. Disc 1 is reserved for the optional Bluetooth source; its assignment is controlled via the web interface. When Bluetooth is activated, Disc 1 maps to the A2DP/HFP sink. When deactivated, Disc 1 behaves as a normal album/playlist disc.
| Disc | Source | Notes |
|---|---|---|
| 1 | Bluetooth (A2DP / Phone) — Optional | Activated and configured via web interface. Receives A2DP audio, navigation audio, and HFP call audio from paired phone. When deactivated, Disc 1 behaves as a standard album/playlist disc. |
| 2–10 | Albums / Playlists | Mapped to albums or playlists from the local media library. Assigned and managed via the web interface. Standard changer track/disc navigation applies. |
All audio sources are mixed and prioritized in a software routing layer on the Pi before being sent to the I2S DAC and the head unit. The Arduino Nano maintains the changer protocol heartbeat independently of audio routing state.
| Audio Source | Routing Behavior |
|---|---|
| Local Media (BT inactive) | Pi plays from local library. Full changer protocol control active. Normal disc/track navigation. |
| BT Music (A2DP active) | Phone audio streams via A2DP. Pi reports Disc 1 to head unit. Head unit button behavior remapped (see Section 4). |
| Navigation Audio (ducking) | Phone broadcasts audio focus event. Pi ducks local media volume, plays nav audio through DAC, restores volume when direction ends. |
| Incoming Call (HFP) | HFP connection event detected. Pi pauses local media, switches to Disc 1, routes call audio through DAC. Head unit sees normal disc change. |
| Active Call (HFP) | Call audio routed bidirectionally. Microphone input required (see Section 5). Button remapping active for call control. |
The Pi audio router shall implement the following priority hierarchy (highest to lowest):
| Priority | Source | Behavior |
|---|---|---|
| 1 (highest) | HFP Active Call | All other audio muted. Call audio exclusively routed to DAC. |
| 2 | Navigation Ducking | Current source volume reduced ~80%. Nav audio overlaid. Auto-restores on completion. |
| 3 | A2DP Bluetooth Stream | Phone music or other A2DP audio via Disc 1. Interrupts local media (Discs 2–10) while active. |
| 4 (lowest) | Local Media Library | Default playback source when BT is inactive. Albums/playlists on Discs 2–10. |
The KRC-3006 head unit (KRC-3006 OM, p.15) provides the following physical controls available to the changer emulator. In BT/call modes, these controls shall be interpreted contextually by the Pi firmware rather than passed through as standard changer commands.
| Control | Standard Mode (Local Media) | BT Music (Disc 1 / A2DP) | Incoming Call (Ringing) | Active Call (HFP) |
|---|---|---|---|---|
| ① Button 1 | Disc scan | Disc scan / switch to Discs 2–10 | Decline call | End call |
| ② Button 2 | Repeat cycle | Repeat / shuffle toggle | Silence ringer | Mute call toggle |
| ③ Button 3 | Reset / reinitialize | Reset | Reset | Reset |
| ④ Button 4 | Play / Stop | Play / Pause BT stream | Answer call | (held) Trigger voice assistant |
| ⑦ Rotary (turn) | Track forward/back | Track skip (phone-side) | Volume | Volume |
| ⑦ Rotary (press) | Disc search (next disc) | Switch to Disc 1 (BT) | Answer call | End call |
| ⑧ Button 8 | Track scan / Random | (held) Voice assistant | Decline call | (held) Voice assistant |
Note: Button numbers refer to the circled numerals used in the KRC-3006 Owner's Manual (p.15). Mapping assignments are provisional and subject to refinement during implementation.
Full hands-free phone call support (HFP profile) requires a microphone input. The Raspberry Pi does not have a built-in microphone or analog audio input. The following options should be evaluated during implementation:
- Option A: USB microphone or combined USB audio dongle (simplest; adds a USB device)
- Option B: I2S microphone module (e.g., INMP441) — consistent with the I2S DAC already planned for the project (preferred)
- Option C: Bluetooth headset profile (HSP) — routes mic through the phone itself; no additional hardware but limits call control flexibility
Option B is the preferred long-term approach for consistency with the I2S audio architecture. Microphone placement (e.g., sun visor, headliner, A-pillar) will require consideration during vehicle installation.
The following software components are anticipated for this feature. This is not a final design — it is recorded here to inform future architectural decisions.
- BlueZ — Linux Bluetooth stack; handles A2DP sink and HFP agent profiles
- PipeWire — audio server; manages source mixing, ducking, and routing to I2S DAC
- ofono or hsphfpd — HFP telephony daemon for call state management and AT command handling
- Custom Python/C service on Pi — monitors Bluetooth profile events, manages source priority state machine, translates head unit button commands received from Arduino Nano
- Arduino Nano firmware extension — adds button event forwarding to Pi over UART; no changes to changer protocol timing logic
This stretch goal has a hard dependency on the completion of the core project. The following must be satisfied before implementation begins:
- Changer protocol fully defined and documented (all five test phases in TP-KRC3006-01 complete)
- Arduino Nano firmware stable and passing all protocol conformance tests
- Raspberry Pi media playback from local library confirmed working end-to-end
- I2S DAC audio output verified and integrated
The following items are unresolved and noted for future consideration:
- Does the KRC-3006 protocol carry any volume or mute commands that could be leveraged for call ducking?
- Can the rotary encoder (Button 7) be reliably read as a discrete press vs. turn via the changer protocol, or does it require additional hardware?
- What is the preferred microphone mounting location and hardware form factor for the truck installation?
- Should navigation audio ducking be handled at the Pi audio layer, or can Android's audio focus events be relied upon exclusively?
End of document DN-KRC3006-03 Rev 0.1