From broken hardware to music and calls in the car

01 Read this first

In the previous post I explained what this project is and why I built it. In this guide I explain how I did it, in fifteen steps from the first checks to music and calls in the car.

The measurements come from my hardware and my car. Another car may give different results. That is why I started with measurements and recordings before transmitting messages or making further connections.

The software is on GitHub: github.com/crimeofheart/giulietta-blue-me.

Listening first

I could not find published CAN information for the Giulietta 940. I started from fmntf/fiatcan for the Fiat Doblò 263 and karolkrupa/alfa-blue-me for the Alfa 159. But they describe other cars and differ on many message identifiers. I compared the messages with recordings from my own car. Each message in the software's tables has a reference to its recording, and the transmit gate only allows messages supported by those recordings.

A fresh install is listen-only, in two layers: the CAN controller is in listen-only mode, and the application's list of frames it may send is empty. Wired to a live car it receives and decodes, and cannot transmit. Transmitting is switched on in step 12, by a command, and switched off by the same command.

Why the usual approach is unavailable

At the start, I did not have a working module to record, and the car was configured without Blue&Me. So I recorded the car twice: first as it was, then after telling the Body Computer to expect a Blue&Me module. Comparing those recordings with blueandme-diff showed what the car was looking for (step 10). Later, the broken module's remaining traffic gave me more frame IDs, as I describe in the post.

02 Bench build steps 1–6

Step 1 — Identify your MCP2515 module

Two facts to establish before anything is wired.

a) Crystal frequency

I started with the crystal marking on the CAN board: 8.000 means 8 MHz, 16.000 means 16 MHz. A well-lit close-up helps if the marking is hard to read. This value has to be right in the installer; otherwise the bus will look silent later, even with the wiring correct.

b) Terminating resistor

With nothing connected, measure resistance between the CAN-H and CAN-L screw terminals with a multimeter.

• ~120 Ω → there is a terminator on the board. Remove it. On the common blue MCP2515+TJA1050 board it sits directly between the two terminals, silkscreened 120R and marked 121. Desolder it, or lift one leg.
• Tens of kΩ → no terminator. This is the pass, and it is not an open circuit: the TJA1050's own differential input resistance stays across the pins permanently, roughly 20–100 kΩ. With the transceiver fitted you will never read infinity, so do not go hunting for a resistor that is not there.

Established for this build

Step 2 — Solve the 5 V problem

The board has a single VCC pin feeding both chips. That is the whole problem.

The TJA1050 transceiver needs 5 V to drive a CAN bus — it is specified for 4.75–5.25 V and has no 3.3 V mode. So the board gets fed 5 V, the MCP2515 controller runs at 5 V too, and a chip running at 5 V drives its outputs to 5 V. One of those outputs is MISO, and MISO goes straight into the Pi's GPIO9, which is not 5 V tolerant and has no clamping diodes.

Three ways out

What "cut the trace" actually means

A trace is a printed copper track on the surface of the circuit board. It does the job of a wire: it is flat, a fraction of a millimetre wide, glued to the board, and covered by the green lacquer you can see (the solder mask). Every connection on the module is one of these.

Cutting it means physically severing that copper with a sharp blade so current can no longer flow along it — you scrape a small gap across the track, right through to the bare fibreglass underneath. It is not cutting the board itself, and nothing is bent or removed; you are making a deliberate break in one connection, roughly a millimetre wide, in a track thinner than a pencil line.

Once broken, the two ends are electrically separate. You then solder a wire to one of those ends and feed it from somewhere else. That is the entire modification: break one connection, then re-feed one side of it.

Finding the right track without guessing

I located the track with the meter rather than relying on a board drawing. The same check works even when a module's layout differs from mine. With the meter on continuity, the sequence is:

1. Put one probe on the board's VCC header pin and leave it there.
2. Touch the other probe to each pin of the TJA1050 (the small 8-pin chip nearest the CAN screw terminals) until it beeps. That pin is its supply — pin 3 in the TJA1050's datasheet.
3. Do the same on the MCP2515 (the larger chip) to find its supply pin. Note both.
4. The copper running between the VCC pin and the TJA1050's supply pin is what you are cutting. Follow it by eye.

Now you know the two pins that must end up separated, and you can prove it afterwards rather than hoping.

Cut the transceiver side, not the controller side

Both directions give the same split rail. But leaving the header pin attached to the MCP2515 means the pin your jumper wire plugs into is the 3.3 V one — harder to get backwards later, and it matches every published write-up.

What you need

• Fine-tipped soldering iron and thin solder
• Scalpel or hobby knife for the cut
• Multimeter with continuity beep the important one
• Thin insulated wire 28–30 AWG, ~60 mm
• 100 nF ceramic capacitor only if there isn't one already
• Magnifier or phone camera to find the track and check the cut

1. Photograph the board first

   Close up, well lit, before you touch anything. If you lose track of which side is which mid-cut, that photo is the only way back.

2. Scrape through the copper

   Scratch away the green lacquer across the track, then cut the copper beneath it. Two or three light passes with the blade held across the track, not along it. Aim for a gap about a millimetre wide, down to bare board.

   Light passes beat one heavy pass that gouges the board or slips into a neighbouring track.

3. Prove the cut with the meter

   VCC header pin to TJA1050 supply pin: must now read open, no beep. VCC header pin to MCP2515 supply pin: must still beep. If either is the wrong way round, stop and re-read the board.

4. Solder the 5 V wire

   Tin the exposed copper on the TJA1050 side of the gap and solder your wire to it. Keep it short, and anchor it with hot glue or tape — a wire that works loose in a car will take the pad with it.

5. Check for shorts before applying power

   The two supply pins must now be independent of each other, and neither should be shorted to ground. Only then connect anything to the Pi.

Step 3 — Flash the SD card

Use Raspberry Pi Imager on your dev machine.

• OS: Raspberry Pi OS Lite (32-bit). Not the desktop version. 32-bit is required — the Zero W is ARMv6.
• Open "Edit Settings" and set: hostname blueandme; SSH enabled (key or password); username and password; Wi-Fi SSID, password and country.

Boot the Pi from USB power with nothing else connected and wait about two minutes, then ssh <user>@blueandme.local.

Step 4 — Install

# on your dev machine
git clone https://github.com/crimeofheart/giulietta-blue-me
cd giulietta-blue-me
rsync -a --exclude .git --exclude .venv ./ <user>@blueandme.local:~/giulietta-blue-me/

# on the Pi
cd ~/giulietta-blue-me
sudo ./install.sh --dry-run --oscillator 8000000     # read what it will do
sudo ./install.sh --oscillator 8000000               # 8 MHz, confirmed in step 1
sudo reboot

First run takes a while on a Zero W — the apt step is the slow part. On an OS release with no prebuilt package in packages/, it also compiles bluez-alsa for wideband calls, about ten more minutes (step 13). And it trims boot for a headless car unit: no initramfs, no display or camera drivers, none of the modem, disk or keyboard services, and the CAN and Bluetooth drivers loaded first (times in step 15). Run again on a working Pi, it takes about two minutes: it skips apt when every package is there and reinstalls only the application.

Step 5 — Wire the MCP2515 to the Pi

Power the Pi off first (sudo poweroff, wait for the LED to stop).

Find pin 1 before you count anything

Every number below is a physical pin position, and they are only meaningful once you know which end of the header is pin 1. Three ways to find it, in order of reliability:

1. The square pad. Pin 1 is the only square pad on the board; all thirty-nine others are round. If the header is already soldered on, turn the board over and look at the solder joints from underneath.
2. The J8 silkscreen outline. Pin 1 is the corner inside it nearest the microSD card slot.
3. The card slot itself. Pin 1 is at that end of the header, never the far end where the RUN pads and the second mounting hole are.

From there, numbering advances in pairs along the header, away from the card slot: 1 and 2 at the corner, then 3 and 4, then 5 and 6. Odd numbers stay in the row nearer the card slot; even numbers in the row nearer the board's outer edge.

Power up and check:

blueandme-status

Expect interface present ok, link state UP, bitrate 50000, bus errors 0, spidev present ok. If can0 does not exist:

dmesg | grep -i -E "mcp251|spi"      # driver probe failures show here
ls /dev/spidev*                       # SPI enabled?
grep -E "spi|mcp2515" /boot/firmware/config.txt

mcp251x spi0.0: MCP2515 successfully initialized is what you want. Cannot initialize MCP2515 points to the wiring or to a wrong oscillator value.

Step 6 — Prove the software works, with no car

Everything can be exercised over a virtual CAN interface before the car is involved.

sudo modprobe vcan
sudo ip link add dev vcan0 type vcan && sudo ip link set up vcan0
tests/fixtures/fetch.sh               # once: the Doblò recordings some tests read
python3 -m pytest                     # the vcan0 tests now run too
blueandme-protocol-map                # the profile tables, generated from code

03 In the car steps 7–10

Step 7 — First contact: listen only

Two connectors in my car matter, and they are for two different machines. Do not confuse them.

What you are looking for

The harness-side plug is the half that stays in the car: a blue housing with a black locking lever, the loom entering from the back and two rows of small square cavities on the mating face. Since the original module was removed it is vacant and hanging loose, which is what makes this tap possible without cutting into the loom.

The photographs identify the two connectors and their moulded numbers. They do NOT tell you what each pin carries: that is the map below. The two photos were not taken the same way up, so compare the moulded numbers, not the positions.

The pin map

Corroborated by two independent sources: a German Alfa 159/Brera thread documenting the M162 module's connector, and an Italian ClubAlfa thread about fitting Blue&Me to a Giulietta specifically. They agree with each other and with the numbers this project already used.

Where each wire actually lands

Then listen

candump -e can0,#FFFFFFFF     # errors and data, everything

Turn the key to MAR. Frames should appear.

The OBD2 socket, and why the Pi does not use it

The body B-CAN is on OBD2 pins 1 (CAN-H) and 9 (CAN-L), with ground from pin 4 or 5. It was measured on my car on 2026-09-21 at 122 frames/s carrying the familiar IDs (capture M), and the pinout was confirmed on the car. An earlier version of this guide guessed pins 3 / 11, which was wrong. It is a valid tap for body traffic, but it cannot hear diagnostics. Capture N contains no 18DA… frames at all across a PROXI alignment, a fault-code read and a fault-code clear. So any alignment work needs the Pi on the Blue&Me connector, and the tablet's adapter needs an OBD2 Y-splitter if it is to share the socket. Captures M and N are the only ones tapped here; do not diff them against the connector-tapped captures.

If you see nothing

1. Is the car awake? Key to MAR, or open a door.
2. Swap CAN-H and CAN-L. Harmless to try.
3. Is the ground wire connected? Without it the bus reads as nothing.
4. ip -details -statistics link show can0 — a rising bus-error count means the bitrate or oscillator is wrong; a flat zero with no frames means you are not electrically connected.
5. Re-check the crystal marking against what you passed to install.sh.

Step 8 — Capture A: 11-bit or 29-bit?

Start recording with the key out, then turn to MAR and wait 60 seconds.

mkdir -p ~/captures
TAP="Blue&Me connector 30/14/15"    # the same tap point for every capture

blueandme-capture --scenario A --out ~/captures/A-ignition-on.log \
                  --tap-point "$TAP" --duration 90

Read the last lines of the output:

ID widths seen: {'29-bit': 4127}   <- the answer

Check the identifier width. The expected value is 29-bit. The alfa-blue-me author reported it for the Giulietta, and I confirmed it on mine. A recording showing 11-bit is a different bus; the messages in this guide do not apply. The difference needs to be understood before continuing.

blueandme-decode ~/captures/A-ignition-on.log --profile doblo263 --summary

The Doblò profile is the structural template. Expect some IDs to match by luck and most not to — what matters is whether the topic<<16|node shape holds: do the IDs cluster into a small set of 0x40xx low halves?

Step 9 — The rest of the captures

Each is one recording. Take your time; the diffs are only as good as these.

# B — key MAR -> OFF, start recording first
blueandme-capture --scenario B --out ~/captures/B-ignition-off.log \
   --tap-point "$TAP" --duration 90

# E — baseline: key in MAR, engine off, touch nothing at all
blueandme-capture --scenario E --out ~/captures/E-baseline.log \
   --tap-point "$TAP" --duration 180

# C — one button at a time, 3 presses each, 2 seconds between
blueandme-capture --scenario C --out ~/captures/C-buttons.log \
   --tap-point "$TAP" --duration 180 \
   --label "vol+ x3, vol- x3, next x3, prev x3, src x3, mute x3, menu x3"

# F — radio: change source, volume up/down, mute
blueandme-capture --scenario F --out ~/captures/F-radio.log \
   --tap-point "$TAP" --duration 120 \
   --label "FM, volume, mute, source cycling"

Then find the button frame:

blueandme-diff ~/captures/E-baseline.log ~/captures/C-buttons.log --by bits

Look for an ID whose payload returns to all-zero between presses and whose volatile bits form a clean bitmask. Compare against the masks both reference platforms share: 0x8000 vol+, 0x4000 vol−, 0x2000 mute, 0x0400 source, 0x0080 menu, 0x0040 windows.

Step 10 — Capture H: re-align PROXI with Blue&Me

Using your OBD2 adapter and ECU software, run PROXI alignment with Blue&Me present in the Body Computer's configuration. The module is still physically absent, so the Body Computer will look for a node that never answers.

The Pi is tapped at the Blue&Me connector, so the OBD2 socket is free for the tablet and both can be connected at once. Start the capture first, then run the alignment inside it.

blueandme-capture --scenario H --out ~/captures/H-proxi-with-bm.log \
   --tap-point "$TAP" --duration 180
blueandme-diff ~/captures/E-baseline.log ~/captures/H-proxi-with-bm.log

If $TAP differs between E and H the diff is meaningless — check the two .meta.json sidecars agree before trusting it.

The H − E comparison showed the messages the Body Computer expects from Blue&Me: the PROXI challenge, its retries and status queries to the missing node. I used this comparison in place of a working original module's recording; my broken module could not provide a working example.

While you are in the ECU software, also check:

• whether the radio has its own Blue&Me / media-source configuration item (if the radio needs it too, no amount of CAN will help)
• whether the Blue&Me node's stored PROXI value is readable (the fallback, should the nodes not share one value)

04 Profile and first transmission steps 11–12

Step 11 — Check the profile against your captures bench

The frames the Pi expects and sends are in blueandme/protocol/profiles/giulietta940.py, each with the recording of my car it was seen in: the 29-bit width, the wheel frame and its masks, and every frame the Blue&Me node exchanges with the car. Received: the Body Computer's status poll and PROXI challenge, and the radio's media request. Sent: the status, the PROXI answer, the watchdog, track time, the audio channel and the track text.

I compared the profile with my recordings before allowing any transmission. The commands below print the profile and decode the captures. This comparison needs to be repeated for the car being fitted:

blueandme-protocol-map --profile giulietta940
blueandme-decode ~/captures/A-ignition-on.log --summary
blueandme-decode ~/captures/C-buttons.log --summary

The recordings must contain the status poll 0E094000, the PROXI challenge 1E114000 and the wheel frame 06354000. The wheel bits must also match the buttons pressed in capture C. If either check fails, the car differs from mine: this is the point to stop, with transmission still disabled.

Step 12 — First transmission, one frame at a time

First, two things. The original module is unplugged: two nodes with the same address contend. And your PROXI value from step 10 is in the Pi's configuration, /etc/blueandme/config.yaml, under can:, as 12 hex digits in quotes. While it is empty the Pi does not answer the PROXI question. On my own Pi the value is built into the copy it runs. This setting exists only in the published code: tests cover it, but I have not yet run it in the car.

can:
  proxi_value: "............"    # your car's six bytes, 12 hex digits, in quotes

blueandme-giulietta --config /etc/blueandme/config.yaml --check

Then one command takes the controller out of listen-only and lets the application send the frames named, all six by default; off reverses both:

sudo ~/giulietta-blue-me/tx.sh on                        # all six node frames
sudo ~/giulietta-blue-me/tx.sh on bm_status_response     # or one at a time
sudo ~/giulietta-blue-me/tx.sh status
journalctl -fu blueandme-giulietta             # every transmitted frame is logged
sudo ~/giulietta-blue-me/tx.sh off                       # back to listen-only

My car accepted all six, so on with all of them is the normal case. One at a time, in this order, if anything looks wrong:

At item 2, I had a replacement the car accepted. Item 4 opened the radio's audio input. Only then was it worth connecting the sound card to the car.

Emergency stop

sudo ~/giulietta-blue-me/tx.sh off
# or, if that script is not there:
sudo sed -i 's/^  mode:.*/  mode: listen-only/' /etc/blueandme/config.yaml
sudo systemctl restart blueandme-giulietta

Physically: pull CAN-H and CAN-L.

05 Audio and permanent install steps 13–15

Step 13 — Sound card bench

Do this in parallel with the CAN work; it needs no car. The Pi Zero W has no analog audio at all, and the car is analog on both sides: the radio takes Blue&Me audio on connector pins 5 / 22 / 21, and the microphone arrives on pins 8 / 24. A USB sound card handles both directions. Audio cannot travel over CAN: B-CAN runs at 50 kbit/s, and CD-quality stereo needs 1.4 Mbit/s.

The card is a Ugreen USB-A adapter built on a C-Media HS-100B. It plugs into the Zero W's micro-USB data port — the one marked USB, not PWR — through an OTG adapter.

• Ugreen USB sound card C-Media HS-100B
• Micro-USB OTG adapter micro-B plug to USB-A socket
• Headphones for the output test
• A headset with a microphone for the recording test
• Multimeter for the sleeve check

1. On a PC first

   lsusb lists the card with vendor ID 0d8c. Then meter the headphone sleeve against the USB plug's shell: 0 V.

2. On the Pi: find the card

   Plug it in through the OTG adapter. aplay -l and arecord -l must both list it, as card N: Device [USB Audio Device].

3. Play and record

   A tone into headphones, then five seconds from the headset mic, played back.

speaker-test -D plughw:CARD=Device -c 2 -t sine -f 440 -l 1
arecord -D plughw:CARD=Device -f S16_LE -r 48000 -c 1 -d 5 /tmp/mic.wav
aplay -D plughw:CARD=Device /tmp/mic.wav

install.sh makes the card the Pi's default sound device, by its name Device. It also sets up Bluetooth for both music and calls:

Calls are wideband. Debian's bluez-alsa (4.0) carries calls only at 8 kHz. install.sh puts bluez-alsa 4.3.1 built with mSBC into /usr/local, from the prebuilt package in packages/ or by compiling it, and swaps it over Debian's files with dpkg-divert. The phone then picks mSBC, 16 kHz, on the Zero W's own Bluetooth chip: on the bench quiet words came through that 8 kHz lost, and the few damaged packets (about three in 75 s) were concealed. sudo ./install.sh --no-wideband puts Debian's files back.

Pair the phone once. Nothing answers pairing requests while the app is listen-only, so blueandme-pair opens pairing for a while, trusts the phone that pairs, and closes it again. Pair after install.sh has run, so that the phone sees the hands-free profile; a phone paired earlier shows only "Media audio" and has to be forgotten and paired again.

sudo blueandme-pair --seconds 120
# on the phone: pair with "blueandme", then check Phone calls and Media audio are on

I tested music first, then a call, using headphones on the sound card and a mic in its input. Both directions need to work before the audio wiring goes into the car. During a call, journalctl -u blueandme-sco-uplink shows how much microphone audio was sent.

The Pi can also control the call, by AT command over the hands-free link: blueandme-call answer, blueandme-call hangup, and blueandme-call calls to list them. Each prints the phone's reply and succeeds on OK. After a reboot, blueandme-bt-reconnect brings the phone back without touching it.

Call audio timing

The microphone relay drops audio that has waited more than 120 ms. A plain arecord | aplay pipeline retained four seconds of audio between calls in my test. Keep separate players for music and calls; the shared player did not return to music. Polling Bluetooth state every three seconds, with higher priority for the microphone relay, avoided overloading the single core.

The steering wheel

The installed app turns the wheel's buttons into phone actions, as the Giulietta Blue&Me manual describes them (604_38_194, p. 9): the action comes when the button is let go, and a press held over a second is a long press. At each press it asks the phone which calls exist (AT+CLCC), so it never falls out of step with it. It sends nothing on CAN, so it works in listen-only too. On the bench, with buttons injected through the controller's loopback (sudo ~/press.sh phone 1.5), each of these worked with a real phone and a real call (2026-09-26). In the car, with the real wheel buttons, I have since confirmed answering a normal call, hanging up, rejecting a call, muting the mic, moving a call to the phone and back, and the assistant through the roof microphone.

Moving a call to the phone is done at the radio link: the Pi drops the call's audio link (hcitool, HCI Disconnect), and the phone takes the call to its earpiece. Bringing it back is AT+BCC, which asks the phone to set the link up again. Merely stopping the players does not do it with bluez-alsa 4.3.1: the link stays up and the call goes silent on both sides.

Step 14 — Connect audio and the mic to the car

The card's headphone output goes to the Blue&Me connector's audio pins.

The sleeve is a true ground (step 13), so the plug wires straight across: tip is left, to pin 5; ring is right, to pin 22; sleeve to pin 21.

I started with the card's volume low, selected Blue&Me and compared its loudness with FM by ear. The level is adjusted on the Pi with the card's own volume control. The next check is for alternator whine with the engine running. If it is present, a 1:1 audio isolation transformer (a "ground loop isolator") between the card and the car breaks the ground loop.

The microphone. Pins 8 (MIC+) and 24 (MIC−) carry the roof-console microphone, which is amplified. It needs its own 5–8 V supply on its signal wire, and a divider before the card's input, because the card cannot power it and its signal is close to line level. The circuit below does both. On other cars of the group the capsule is a Telicom MIC-98, which its datasheet runs on 5–8 V through 680 Ω; I found no confirmation that the 940 has the same one, so the circuit is built to be measured before it is trusted. During a call the application also tells the radio on CAN that a call is on, with the value the Doblò's module uses.

The mic test board

A breadboard that powers the roof microphone the way the module did, only more gently, and feeds it to the sound card's mic jack through a capacitor (keeps the mic's DC off the card) and two resistors (turn its level down about twelve times). The Pi then measures it, plays it back and carries a test call. The ignition wake of step 15 sits on rows 20–27 of the same breadboard.

Home test, done 2026-09-27. With the 5 V jumper off, the audio lead's tip in row 5 and its sleeve in the − strip, the card played a 200 Hz tone into the board: 520 mV at row 5, 41.6 mV at row 12, twelve and a half times less, and the recording through the mic jack was clean (−37.5 dBFS at 0 dB gain, no clipping). At that gain the card's mic input takes about 2 V before it clips, so at the car the recording starts at full gain; if speech comes out quiet, a larger 1 kΩ weakens the reduction.

Measurements from my car

To test the roof microphone, I recorded myself talking and whistling towards it, then made a call. I set the relay to add 15 dB before sending the audio to the phone (--gain-db 15 in /etc/blueandme/sco-uplink.env). The person on the other end said it sounded great. That was a much more useful result than a level reading alone.

At the car, in order

I brought the audio and power tests together for the car visit: step 14 and the car work from step 15. The order below keeps the Pi on its power bank until the buck is connected last.

At home, before leaving

1. Take the audio lead's wires out of the breadboard (tip out of its row, sleeve out of the − strip): from now on it serves the car's audio pins 5, 22, 21.
2. Take the 5 V stand-in jumper out of row 26 (the ignition wake's bench test).
3. Leave unconnected for the trip: the mic's 5 V jumper (row 1) and the four car leads (pins 8, 24, 15, 32). The Pi pin 5 wire and the Pi pin 6 ground stay on.
4. Buck: solder a red wire to IN+ and a black one to IN−, heat-shrink over the pads, dupont pins on the ends.
5. Pack: the Pi with MCP2515 and sound card, the breadboard, power bank, buck with a USB cable to the Pi's PWR port, audio lead, dupont wires, a spare 1 kΩ resistor, multimeter, phone, tablet, a fuse puller.
6. sudo ~/giulietta-blue-me/preflight.sh ends in PREFLIGHT PASS, then sudo ~/giulietta-blue-me/tx.sh off: the Pi stays listen-only while the CAN leads go on. Make sure you can reach the Pi at the car, for example over the phone's hotspot.

At the car, first measure (Pi on the power bank)

1. Blue&Me module unplugged, can0 still listen-only from home (tx.sh status) while the CAN leads go on.
2. DC volts, black probe on bare metal: pin 16 about 12 V with the key off and in MAR (permanent); pin 32 0 V off, about 12 V in MAR (ignition).
3. Pull F36 (the fuse box below): pin 16 drops to 0 V. Put it back.
4. CAN: 30 to H, 14 to L, and the − strip lead to pin 15.
5. When ip -s -d link show can0 shows frames arriving and no errors: tx.sh on. The Pi answers the car from here on. Key off and on again: the odometer must not blink.

Then the mic

1. Meter only, board not on pins 8 and 24 yet: Ω pin 8 to 24, both ways; pin 8 and pin 24 to bare metal (OL).
2. Board leads onto pins 8 and 24; row 1 jumper to Pi pin 2; mic plug in the card's MIC jack.
3. DC volts, black on the − strip, red on row 5: clearly under 5 V means the mic is alive. Around 3–4 V is good. Under about 2.5 V, or a recording that distorts on loud whistling, means the 2 kΩ starves it: swap it for 1 kΩ, or put the 1 kΩ beside it (also rows 1 to 5): together about 670 Ω, the datasheet's 680 Ω.
4. Record on the Pi while someone whistles and talks towards the roof console, play it back, and if it sounds clean, a test call with the car's mic.

Then audio and the app

1. Audio lead onto pins 5 (tip), 22 (middle), 21 (sleeve), plug in the card's headphone jack. Select Blue&Me on the radio: the phone plays (if its music app was recently used), the radio shows the track. Set the level, listen for whine with the engine running (on the power bank that verdict is provisional).
2. The wheel: skip, pause, the assistant, answer and reject a call.

Then the ignition (step 15)

1. Key off. The row 26 lead onto pin 32.
2. Set the Pi to read the ignition on GPIO3 and watch it while the key goes to MAR and back: low in MAR, high off.

Last, the buck (step 15)

1. Key out. Pull F36.
2. Buck IN+ (red) onto pin 16; buck IN− (black) into a free hole of the − strip, which reaches pin 15 through its lead (about 0.1 A; the permanent install gives the buck its own ground wire).
3. Halt the Pi. When its LED is out, move the Pi's PWR cable from the power bank to the buck's USB socket.
4. Refit F36: the Pi boots from the car. Check the supply voltage measured at the Pi; Zero W has no under-voltage detector.
5. Start the engine: the Pi must keep running. Mine reset until the converter was replaced; see the diode, the capacitor and the test results in step 15.
6. Leaving it: either it stays, running from the car with tx.sh on, or it comes home: halt it, then pull F36 before unplugging anything.

Radio controls and display

I matched the card's Speaker level to FM by ear. At −20 dB the music was too quiet; I ended up at 0 dB, the card's maximum, and saved it with alsactl store. Then I listened with the engine running. There was no whine, so I did not need a ground-loop isolator. That first check was on the power bank. With the unit on the car's supply and the engine running there is no whine either.

The radio handles some buttons itself. Outside a call, it reports its mute state over CAN and the Pi pauses the phone until the radio unmutes. I also read the radio's arrow buttons from these messages. Left and right change tracks; up and down adjust Bluetooth volume.

Track text uses the Doblò module's format with its 6-bit character set, as decoded in fiatcan, and the Giulietta's radio accepts it. The top line shows the first twelve characters of one text field, so the Pi runs "artist - title" through it every quarter of a second. The bottom line shows another field, which carries the time as M:SS. Four character codes of that set show nothing on this radio and none of them is a bracket, so brackets in a title become *.

Step 15 — Permanent install

Once I had verified the audio in step 14, I connected the permanent supply. The Pi runs from the car's permanent 12 V line through fuse F36. It stays in standby for up to 72 hours while parked, ready to answer PROXI when the car wakes. After that it halts. I added further parts as tests showed a need for them.

Why the Pi stays on while parked

The car asks for PROXI about a second after it wakes, which is when it is unlocked, before the key turns. It asks three times within a few seconds. A Pi that has to boot at that moment is far too late: from a cold power-on on 2026-09-27 the firmware took about 3.8 s, the kernel 5.6 s, and the app was on the bus about 53 s after power-on.

A Pi that is already running answers at once: 3.3 ms in the bench replay of the car's traffic (step 11), 8 ms from the supervised script in capture ZB. In every test so far the Pi was running when the car woke, so PROXI was always answered and the odometer never blinked. What the car does when a Pi starts only after it woke, as it would after a parking longer than the hold, has not been tested.

Standby, measured

Measured on the bench with a USB power meter at the Pi's 5 V input (experiments/standby/). Standby switches off Bluetooth and Wi-Fi, sets the CPU to its slowest and turns the LED off; the CAN interface stays up, in the mode tx.sh set, to notice the car waking (on the car: transmitting, so PROXI is answered at once).

For the battery calculation I assumed 12.4 V and a buck converter with 80 % efficiency. The battery's actual capacity needs checking on its label. The halted Pi still draws roughly a third of its running current. Three weeks parked use about 4.7 + 11 Ah, roughly 22 %. If I will be away longer, I pull F36 to disconnect the supply.

Blue&Me is unavailable while the Pi is halted. The radio cannot use the source and PROXI goes unanswered. Removing and refitting F36 restarts the Pi, which is ready in about a minute. If long parking is frequent, the ignition-wake circuit below can be added; turning the key then restarts it.

Waking from standby. blueandme-standby enters standby after a minute of bus silence with the ignition off. It wakes on a CAN message when the car is unlocked, or through the ignition line if connected. In my bench test with a message, music was ready in 3.3 s and calls in 3.7 s. A cold start takes 33.5 and 34.2 s. The service only arms after seeing car traffic, so a bench setup with a silent bus never enters standby.

The install

I have not made the root filesystem read-only yet. The card has survived the power cuts so far, but that does not establish that it is safe from damage.

The ignition wake

Optional: it lets the ignition restart a Pi that has halted after a parking longer than 72 hours; without it, pull F36 and put it back. Three kit parts on rows 20–27 of the mic board's breadboard, sharing its − strip. When the key is in MAR, the transistor pulls Pi pin 5 (GPIO3) to ground, and a halted Pi boots on that.

Bench-tested 2026-09-27. The Pi's own 5 V (pin 2) on row 26, standing in for the ignition, set GPIO3 to 0; without it, 1. A halted Pi booted the moment it went in (halted 14:38:48, back on the network 14:39:56). That stand-in comes out afterwards, or the Pi restarts whenever it halts. At the car it only needs the pin 32 wire and two lines of config (ignition_gpio: 3, ignition_active_low: true).

12 V to 5 V

The buck module stays off the breadboard: it has its own solder pads and a USB socket, and keeping 12 V off the board keeps it away from the Pi's pins.

Soldered, without a breadboard

For the permanent install the mic circuit is soldered, each joint covered with heat-shrink: a breadboard shakes loose in a car. The ignition wake goes onto the perfboard of the next part. Values as kept at the car (2026-09-27): with a 1 kΩ beside the 2 kΩ the mic sat at 2.37 V (2.16 V on the 2 kΩ alone) and recorded clean at full gain, loud whistles included.

1. Cut the wires to length. Before soldering, slide a sleeve onto each wire that ends at A, B or G, and one over each part you will join.
2. The 2 kΩ and a 1 kΩ side by side, their legs twisted together at both ends (about 670 Ω); one end to the Pi pin 2 wire.
3. A: the pair's other end, the capacitor's + leg and the car pin 8 wire, twisted and soldered. The capacitor's − leg to one end of the 10 kΩ.
4. B: the 10 kΩ's other end, the second 1 kΩ and the mic plug tip wire.
5. G: that 1 kΩ's other end, car pins 24 and 15, the mic plug sleeve and the Pi ground wire.
6. Slide each sleeve over its joint or part and shrink it (heat gun, or a lighter held below, not in the flame).
7. Meter on Ω before the car: Pi pin 2 wire to car pin 8 wire about 670 Ω; mic tip to ground about 1 k; car pin 8 to ground open.

Ignition wake and crank hold-up on one perfboard

Both circuits that touch the car's 12 V, on one piece of the kit's perfboard (plated holes, none joined): 10 columns × 24 rows, the size of the 3 × 7 cm board (count yours). The ignition wake takes rows A–G; row H stays empty; the crank hold-up takes rows I–X, most of it the capacitor lying flat. Parts go on top, connections are made underneath with bent leads and solder bridges. With the capacitor lying down the board stands about 21 mm tall.

Crank hold-up and converter fix (2026-10-01). The installed Pi reset during cranking despite an added 2200 µF capacitor. The original converter, advertised for 6–32 V, produced 0 V at a 10 V bench supply even with the Pi disconnected and the supply in constant-voltage mode. Output returned by 11 V; at 12 V supply the multimeter measured 5.09 V output. Replacing the converter resolved the resets. The replacement, a TECNOIOT 6–24 V to 5 V USB step-down module, kept the Pi running down to 5 V at the bench supply; the Pi's rail voltage at that input has not been recorded. Buck IN− was also found disconnected and reconnected before these tests; it needs its own return to pin 15. Pin 16 reaches the buck through a diode, with the fitted 2200 µF capacitor across IN+/IN− after it. Use a capacitor rated at least 35 V; the diode's stripe faces the capacitor. No increase in capacitance is required by the reported fix. The car's crank waveform remains unmeasured; do not assume an advertised 6 V input limit when calculating hold-up time.

1. Transistor first: bend E and C outwards so the legs sit in B3, B5, B7, flat face toward row C. Solder underneath, keeping the three blobs apart.
2. The two resistors and the 1N4007, flat on the board, stripe at F5; the crank diode in J10–J6, stripe at J6. Solder, leaving the leads long until the tracks are done.
3. The capacitor: bend both leads 90° about 3 mm from the body, + into L6 and − into L3, body lying flat toward row X. Solder, then a line of glue (or a tie through two free holes) holds the body.
4. Tracks underneath: lay each long lead along its track and solder it into the next holes; bridge the rest with solder or a bare offcut. Ignition: B3–B1–G1, B5–F5, B7–B9, E9–G9. Crank: I10–J10, J6–K6–L6–L10, K1–L1–L3. Row H and everything else stay apart.
5. The seven wires in from the top, soldered underneath.
6. Meter on Ω, nothing connected: C to E open both ways; Pi pin 5 wire to Pi ground wire open; car pin 32 wire to B5 about 100 k. Crank side: car pin 16 wire to buck IN− wire must not read near 0 (the capacitor charges from the meter, so the reading climbs); buck IN+ to buck IN− the same; on the diode range, I10 to L10 about 0.3–0.7 V one way, nothing the other. Then a dab of glue over the wire joints.
7. At the car, F36 out: wires on, F36 back in. Read GPIO3 while the key goes to MAR and back (0 in MAR, 1 off). Confirm the Pi stays running through a crank; the Zero W has no low-voltage detector, so get_throttled=0x0 is not proof of a stable supply. If it resets, measure buck input and Pi 5 V with a scope.

• I have not completed the long-parking test yet. The battery needs checking after one night and then four days parked. The Pi must halt after 72 hours; blueandme-standby should log the halt and Wi-Fi should stop responding. Refitting F36, or turning the key with ignition wake fitted, must restart the Pi. Working in daily use does not establish that it will avoid draining the battery during a longer stay.

Case and connector fitting

The original case is 150 × 175 × 40 mm, with four M3 mounting bosses. Its PP-TD40 plastic passes Bluetooth. Use PETG or ASA for the printed frame and tray; PLA can soften in a parked car. Check the real cable and plug clearances as well as the model, and secure the parts and wiring before closing the lid.

The fix for the adapter: the card's USB cable is cut short and soldered to the test pads on the Pi's underside. PP1 is 5 V, PP6 ground, PP22 D+ and PP23 D−. The buck's 5 V goes to header pins 4 and 6.

The car connector uses 32 square header pins, 0.64 mm wide and 2.54 mm apart, in perfboard cut to 2 × 16 holes with about a 5 mm border. Only the needed pins have wires. Mark pins 1 and 17 and match them to the plug’s moulded "1" and "17" before mating the connector.

Support and insulate the USB pad wires. If the card disappears with device descriptor read/64, error -71, check the data wires and their solder joints. Do not reset the Zero W’s USB controller by unbinding it: that crashed the kernel in my test and USB stayed unavailable until the power was cut.

Wi-Fi while audio is playing

The Zero W shares one radio between Bluetooth and Wi-Fi. I measured the following packet losses while connected to the phone’s hotspot; switching Wi-Fi off removed the gaps in the music.

I added a small service to handle that for me. It checks the Bluetooth audio streams every three seconds and switches Wi-Fi off during music or a call. Thirty seconds after the audio stops, it brings Wi-Fi back. It only restores Wi-Fi if it disabled it itself, so it leaves standby's decision alone.

At the car it goes off two seconds after the music starts. The price: to reach the Pi over SSH, pause the music and wait about 40 seconds.