Come ho costruito il mio sostituto del Blue&Me: guida passo passo

01 Prima di cominciare

Nell'articolo precedente ho spiegato cos'è questo progetto e perché l'ho costruito. In questa guida racconto come l'ho fatto, in quindici passi dai primi controlli alla musica e alle chiamate in auto.

Le misure sono del mio hardware e della mia auto. Su un'altra i risultati possono cambiare. Per questo ho cominciato con misure e registrazioni, prima di trasmettere messaggi o fare altri collegamenti.

Il software è su GitHub: github.com/crimeofheart/giulietta-blue-me.

Prima, solo ascolto

Non ho trovato informazioni pubblicate sul CAN della Giulietta 940. Sono partito da fmntf/fiatcan per il Fiat Doblò 263 e karolkrupa/alfa-blue-me per l'Alfa 159. Ma descrivono altre auto e differiscono su molti identificatori. Ho confrontato i messaggi con le registrazioni della mia auto. Ogni messaggio nelle tabelle del software riporta la sua registrazione, e il controllo di trasmissione consente soltanto quelli confermati.

Alla prima installazione la trasmissione è bloccata in due punti: il controller CAN è in modalità di solo ascolto e l'elenco dei messaggi consentiti nell'applicazione è vuoto. Il sistema riceve e decodifica il traffico dell'auto, ma non può trasmettere. Ho abilitato la trasmissione al passo 12 con un comando che permette anche di disabilitarla.

Ricostruire il protocollo senza un modulo funzionante

All'inizio non avevo un modulo funzionante da registrare e l'auto era configurata senza Blue&Me. Ho quindi registrato l'auto due volte: prima com'era, poi dopo aver detto al Body Computer di aspettarsi un modulo Blue&Me. Il confronto con blueandme-diff ha mostrato cosa cercava l'auto (passo 10). In seguito ho ricavato altri identificatori dai messaggi che il modulo guasto inviava ancora, come racconto nell'articolo.

02 Montaggio al banco passi 1–6

Passo 1 — Identificare il modulo MCP2515

Due cose che ho chiarito prima di collegare qualsiasi filo.

a) Frequenza del quarzo

Ho cominciato dalla scritta sul quarzo della scheda CAN: 8.000 significa 8 MHz, 16.000 significa 16 MHz. Una foto ravvicinata ben illuminata aiuta se la scritta si legge male. Nell'installer il valore deve essere corretto, altrimenti più avanti il bus sembrerà silenzioso anche con i collegamenti giusti.

b) Resistenza di terminazione

Senza niente collegato, ho misurato con il multimetro la resistenza tra i morsetti a vite CAN-H e CAN-L.

• ~120 Ω → sulla scheda c'è una terminazione. Sulla mia c'era, e l'ho tolta. Sulla classica schedina blu MCP2515+TJA1050 sta proprio tra i due morsetti, con serigrafia 120R e sigla 121. Va bene dissaldarla o sollevarne un lato.
• Decine di kΩ → nessuna terminazione. È il risultato giusto, e non è un circuito aperto: la resistenza d'ingresso differenziale del TJA1050 resta sempre tra i pin, più o meno 20–100 kΩ. Con il transceiver montato non si legge mai infinito, quindi non ha senso cercare una resistenza che non c'è.

Risultato dei controlli

Passo 2 — Risolvere il problema dei 5 V

La scheda ha un solo pin VCC che alimenta tutti e due i chip. Il problema è tutto qui.

Il transceiver TJA1050 ha bisogno di 5 V per pilotare un bus CAN: è specificato per 4.75–5.25 V e non ha una modalità a 3.3 V. Quindi la scheda va alimentata a 5 V, anche il controller MCP2515 lavora a 5 V, e un chip che lavora a 5 V porta le sue uscite a 5 V. Una di quelle uscite è MISO, e MISO entra dritta nel GPIO9 del Pi, che non tollera i 5 V e non ha diodi di clamp.

Tre possibilità

Cosa vuol dire davvero "tagliare la pista"

Una pista è una striscia di rame stampata sulla superficie del circuito. Fa il lavoro di un filo: è piatta, larga una frazione di millimetro, incollata alla scheda e coperta dalla vernice verde che si vede (il solder mask). Ogni collegamento del modulo è una di queste.

Tagliarla vuol dire interrompere fisicamente quel rame con una lama affilata, in modo che la corrente non possa più passarci: ho raschiato una piccola fessura attraverso la pista, fino alla vetronite nuda che c'è sotto. La scheda non si taglia, e non si piega né si toglie niente. Quello che ho fatto è un'interruzione voluta in un solo collegamento, larga circa un millimetro, in una pista più sottile di un tratto di matita.

Una volta interrotta, i due capi sono elettricamente separati. A quel punto ho saldato un filo a uno dei due e l'ho alimentato da un'altra parte. La modifica è tutta qui: interrompere un collegamento, e poi rialimentarne un lato.

Trovare la pista giusta senza tirare a indovinare

Ho individuato la pista con il multimetro anziché affidarmi al disegno di una scheda. Lo stesso controllo funziona anche con un modulo disposto diversamente dal mio. Con il multimetro sulla continuità, la sequenza è questa:

1. Ho appoggiato un puntale sul pin VCC dell'header della scheda e l'ho lasciato lì.
2. Con l'altro puntale ho toccato ogni pin del TJA1050 (il piccolo chip a 8 pin più vicino ai morsetti a vite del CAN) finché non ha suonato. È il pin di alimentazione: il pin 3 nel datasheet del TJA1050.
3. Ho fatto lo stesso sull'MCP2515 (il chip più grande) per trovare il suo pin di alimentazione. Me li sono segnati tutti e due.
4. Il rame che corre tra il pin VCC e il pin di alimentazione del TJA1050 è quello da tagliare. L'ho seguito a occhio: di solito è corto.

Così sapevo quali due pin dovevano risultare separati e potevo verificarlo con il multimetro dopo il taglio.

Il taglio dal lato del transceiver, non da quello del controller

In tutti e due i casi si ottengono le alimentazioni separate. Ma se il pin dell'header resta collegato all'MCP2515, il pin in cui si infila il ponticello è quello dei 3.3 V: più difficile da sbagliare in seguito, ed è così in tutte le guide pubblicate.

Cosa serve

• Saldatore a punta fine e stagno sottile
• Bisturi o cutter da modellismo per il taglio
• Multimetro con cicalino di continuità quello importante
• Filo isolato sottile 28–30 AWG, ~60 mm
• Condensatore ceramico da 100 nF solo se non c'è già
• Lente o fotocamera del telefono per trovare la pista e controllare il taglio

1. Prima di tutto, una foto della scheda

   Ho fotografato la scheda da vicino e con buona luce prima di modificarla. La foto serve da riferimento se durante il taglio non è più chiaro dove vanno i due lati della pista.

2. Incidere la pista di rame

   Ho grattato via la vernice verde attraverso la pista, poi ho tagliato il rame che c'è sotto. Sono bastate due o tre passate leggere con la lama di traverso alla pista, non lungo la pista. Ho lasciato una fessura larga circa un millimetro, fino al supporto della scheda.

   Meglio più passate leggere che una pesante che scava la scheda o scivola in una pista vicina.

3. Verificare il taglio con il multimetro

   Dal pin VCC dell'header al pin di alimentazione del TJA1050: adesso deve leggere aperto, nessun suono. Dal pin VCC dell'header al pin di alimentazione dell'MCP2515: deve suonare ancora. Se una delle due è al contrario, bisogna fermarsi e riguardare la scheda.

4. Saldare il filo dei 5 V

   Ho stagnato il rame scoperto dal lato TJA1050 della fessura e ci ho saldato il filo. L'ho tenuto corto e l'ho fermato (va bene colla a caldo o nastro): un filo che in auto si allenta si porta via la piazzola.

5. Controllare che non ci siano corti prima di dare tensione

   I due pin di alimentazione adesso devono essere indipendenti l'uno dall'altro, e nessuno dei due deve essere in corto verso massa. Solo dopo averlo controllato ho collegato qualcosa al Pi.

Passo 3 — Scrivere la scheda SD

Ho usato Raspberry Pi Imager sul mio computer.

• Sistema operativo: Raspberry Pi OS Lite (32-bit). Non la versione desktop. Il 32 bit è obbligatorio: lo Zero W è un ARMv6.
• In "Edit Settings" ho impostato: hostname blueandme; SSH abilitato (chiave o password); nome utente e password; SSID, password e paese del Wi-Fi.

Ho avviato il Pi alimentandolo via USB senza nient'altro collegato, ho aspettato circa due minuti e poi sono entrato con ssh <user>@blueandme.local.

Passo 4 — Installare

# 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

La prima installazione richiede un po' di tempo sullo Zero W: la parte più lunga è scaricare e installare i pacchetti con apt. Se in packages/ non c'è un pacchetto pronto per quella versione del sistema, viene compilato anche bluez-alsa per le chiamate a banda larga. Servono circa dieci minuti in più (passo 13). L'installazione riduce anche il tempo di avvio disabilitando ciò che non serve su un dispositivo senza schermo: initramfs, driver di display e fotocamera, servizi per modem, dischi e tastiera. I driver CAN e Bluetooth vengono caricati all'inizio (tempi al passo 15). Con i pacchetti già presenti, ripetere l'installazione richiede circa due minuti: apt viene saltato e si reinstalla solo l'applicazione.

Passo 5 — Collegare l'MCP2515 al Pi

Prima ho spento il Pi (sudo poweroff, e ho aspettato che il LED si fermasse).

Il pin 1, prima di contare qualsiasi cosa

Tutti i numeri qui sotto sono posizioni fisiche dei pin, e hanno senso solo quando si sa da che parte dell'header sta il pin 1. Tre modi per trovarlo, dal più affidabile al meno:

1. La piazzola quadrata. Il pin 1 è l'unica piazzola quadrata della scheda; le altre trentanove sono tonde. Se l'header è già saldato, si gira la scheda e si guardano le saldature da sotto.
2. Il contorno serigrafato J8. Il pin 1 è l'angolo al suo interno più vicino allo slot della microSD.
3. Lo slot della scheda. Il pin 1 è a quell'estremità dell'header, mai all'estremità opposta, dove ci sono le piazzole RUN e il secondo foro di fissaggio.

Da lì la numerazione avanza a coppie lungo l'header, allontanandosi dallo slot: 1 e 2 nell'angolo, poi 3 e 4, poi 5 e 6. I dispari restano nella fila più vicina allo slot; i pari nella fila più vicina al bordo esterno della scheda.

Ho dato tensione e ho controllato:

blueandme-status

Si deve vedere interface present ok, link state UP, bitrate 50000, bus errors 0, spidev present ok. Se can0 non esiste:

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 è quello che volevo leggere. Cannot initialize MCP2515 vuol dire quasi sempre cablaggio, oppure il valore dell'oscillatore sbagliato.

Passo 6 — Dimostrare che il software funziona, senza auto

Tutto si può provare su un'interfaccia CAN virtuale prima di tirare in ballo l'auto.

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 auto passi 7–10

Passo 7 — Primo contatto: solo ascolto

Ho usato due connettori diversi, uno per il Pi e uno per il tablet. Hanno funzioni distinte.

Cosa bisogna cercare

La spina lato cablaggio è la metà che rimane sull'auto: corpo blu, leva nera di bloccaggio, cablaggio che entra da dietro e due file di piccole cavità quadrate sulla faccia di accoppiamento. Nella mia auto penzola libera, perché il modulo originale non c'è più. Mi sono collegato lì, e così ho potuto accedere ai segnali senza tagliare il cablaggio originale.

Le foto identificano i due connettori e i numeri stampati sul loro corpo. NON dicono che cosa porta ciascun pin: quello è nella mappa qui sotto. Nelle due foto i connettori non hanno lo stesso orientamento: vanno confrontati i numeri stampati, non le posizioni.

La mappa dei pin

Confermata da due fonti indipendenti: una discussione tedesca su Alfa 159/Brera che documenta il connettore del modulo M162, e una discussione italiana su ClubAlfa che parla proprio del montaggio del Blue&Me su una Giulietta. Vanno d'accordo tra loro e con i numeri che questo progetto usava già.

Dove collegare i fili

Poi ascoltare

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

Ho girato la chiave su MAR. Devono comparire dei frame.

La presa OBD2, e perché di norma il Pi non la usa

Il B-CAN della carrozzeria è sui pin 1 (CAN-H) e 9 (CAN-L) dell'OBD2, con la massa dal pin 4 o 5. L'ho misurato su quest'auto il 2026-09-21 a 122 frame/s, con gli ID di sempre (cattura M), e la piedinatura è stata confermata sull'auto. In una versione precedente di questa guida avevo ipotizzato i pin 3 / 11, ed era sbagliato. Come punto di presa per il traffico della carrozzeria va bene, ma la diagnosi da lì non si sente. La cattura N non contiene nemmeno un frame 18DA… lungo un allineamento PROXI, una lettura degli errori e una cancellazione degli errori. Quindi per qualsiasi lavoro di allineamento il Pi deve stare sul connettore del Blue&Me, e se l'adattatore del tablet deve condividere la presa gli serve uno sdoppiatore a Y per OBD2. Le catture M e N sono le uniche che ho fatto da qui; non le confronto con quelle fatte dal connettore.

Se non si vede niente

1. L'auto è sveglia? La chiave deve essere su MAR, oppure una portiera aperta.
2. Scambiare CAN-H e CAN-L. Provare non fa danni, ed è un errore comunissimo.
3. Il filo di massa è collegato? Senza, il bus non si legge.
4. ip -details -statistics link show can0: se il contatore bus-error sale, è sbagliato il bitrate o l'oscillatore; se resta a zero e non arrivano frame, manca il collegamento elettrico.
5. Ricontrollare la scritta sul quarzo rispetto a quello che è stato passato a install.sh.

Passo 8 — Cattura A: 11 bit o 29 bit?

Il comando più importante di tutto il progetto. Ho fatto partire la registrazione con la chiave sfilata, poi ho girato su MAR e ho aspettato 60 secondi.

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

Ho guardato le ultime righe dell'output:

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

Controllare la larghezza dell'identificatore. Il valore previsto è 29 bit. L'autore di alfa-blue-me lo aveva indicato per la Giulietta e l'ho confermato sulla mia. Una registrazione a 11 bit riguarda un bus diverso: i messaggi di questa guida non sono applicabili. Prima di proseguire va chiarita la differenza.

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

Il profilo del Doblò è il mio modello per la struttura. Mi aspettavo che qualche ID coincidesse per caso e che la maggior parte no. Quello che conta è se regge la forma topic<<16|node: gli ID si raggruppano in un piccolo insieme di metà basse 0x40xx?

Passo 9 — Il resto delle catture

Ho fatto un'acquisizione per ciascuno scenario, senza fretta. I confronti successivi dipendono dalla qualità di queste registrazioni.

# 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"

Poi ho cercato il frame dei tasti:

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

Ho cercato un ID il cui payload torna tutto a zero tra una pressione e l'altra e i cui bit variabili formano una maschera pulita. L'ho confrontato con le maschere che le due piattaforme di riferimento hanno in comune: 0x8000 vol+, 0x4000 vol−, 0x2000 muto, 0x0400 sorgente, 0x0080 menu, 0x0040 windows.

Passo 10 — Cattura H: riallineare il PROXI con il Blue&Me

Con l'adattatore OBD2 e il software per le centraline ho lanciato l'allineamento PROXI con il Blue&Me presente nella configurazione del Body Computer. Il modulo fisicamente non c'era ancora, quindi il Body Computer ha cercato un nodo che non risponde mai.

Ho collegato il Pi alla spina del Blue&Me, lasciando la presa OBD2 al tablet. Potevo così usare entrambi contemporaneamente. Prima ho avviato l'acquisizione, poi ho eseguito l'allineamento mentre il Pi continuava a registrare.

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

Se $TAP è diverso tra E e H, il confronto non è valido. Prima di usarlo ho verificato che i due file .meta.json indicassero lo stesso punto di collegamento.

Il confronto H − E ha mostrato i messaggi che il Body Computer si aspetta dal Blue&Me: la richiesta PROXI, le ripetizioni e le richieste di stato al nodo assente. Ho usato questo confronto al posto di una registrazione del modulo originale funzionante; il mio modulo guasto non poteva fornire quell'esempio.

Già che ero nel software per le centraline, ho controllato anche:

• se l'autoradio richiede una propria impostazione per attivare Blue&Me / la sorgente multimediale; in quel caso, trasmettere i messaggi CAN non basterebbe
• se il valore PROXI memorizzato nel nodo Blue&Me si può leggere (il ripiego, nel caso i nodi non condividessero un solo valore)

04 Profilo e prima trasmissione passi 11–12

Passo 11 — Confrontare il profilo con le catture banco

I frame che il Pi si aspetta e che manda stanno in blueandme/protocol/profiles/giulietta940.py, ognuno con la registrazione della mia auto in cui è stato visto: la larghezza a 29 bit, il frame del volante con le sue maschere, e tutti i frame che il nodo Blue&Me scambia con l'auto. Ricevuti: l'interrogazione di stato e la domanda PROXI del Body Computer, e la richiesta multimediale dell'autoradio. Trasmessi: lo stato, la risposta PROXI, il watchdog, il tempo del brano, il canale audio e il testo del brano.

Ho confrontato il profilo con le mie registrazioni prima di consentire qualsiasi trasmissione. I comandi qui sotto mostrano il profilo e decodificano le catture. Il confronto va ripetuto per l'auto su cui si fa il montaggio:

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

Nelle registrazioni devono esserci la richiesta di stato 0E094000, la richiesta PROXI 1E114000 e il frame del volante 06354000. I bit del volante devono anche corrispondere ai tasti premuti nella cattura C. Se una verifica fallisce, l'auto è diversa dalla mia: qui ci si ferma, con la trasmissione ancora disabilitata.

Passo 12 — Prima trasmissione, un frame alla volta

Due controlli prima di trasmettere. Il modulo originale deve essere scollegato: due nodi con lo stesso indirizzo entrano in conflitto. Il valore PROXI del passo 10 va in /etc/blueandme/config.yaml, sotto can:, come 12 cifre esadecimali tra virgolette. Se il valore è vuoto, il Pi non risponde al PROXI. Sul mio Pi il valore è incluso nella copia che esegue. Questa impostazione esiste solo nel codice pubblicato: è coperta dai test, ma non l'ho ancora provata in auto.

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

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

Poi un solo comando toglie il controller dal solo ascolto e lascia che l'applicazione mandi i frame indicati, tutti e sei se non si dice altro; off annulla tutte e due le cose:

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

La mia auto li ha accettati tutti e sei, quindi on con tutti è il caso normale. Se qualcosa non torna, si va uno alla volta, in quest'ordine:

Al punto 2 avevo un sostituto accettato dall'auto. Il punto 4 ha aperto l'ingresso audio dell'autoradio. Solo allora aveva senso collegare la scheda audio all'auto.

Arresto di emergenza

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

Fisicamente: si staccano CAN-H e CAN-L.

05 Audio e installazione definitiva passi 13–15

Passo 13 — Scheda audio banco

Ho preparato l'audio a casa mentre lavoravo sul CAN. Il Pi Zero W non ha ingressi né uscite audio analogiche. L'autoradio riceve il suono sui pin 5 / 22 / 21 del connettore Blue&Me, mentre il microfono arriva sui pin 8 / 24. Ho usato una scheda audio USB per entrambi. L'audio non può passare sul CAN: il B-CAN lavora a 50 kbit/s, contro gli 1.4 Mbit/s necessari per l'audio stereo in qualità CD.

La scheda è un adattatore Ugreen USB-A basato su un C-Media HS-100B. Si collega alla porta micro-USB dati dello Zero W, quella con scritto USB e non PWR, con un adattatore OTG.

• Scheda audio USB Ugreen C-Media HS-100B
• Adattatore micro-USB OTG da spina micro-B a presa USB-A
• Cuffie per la prova dell'uscita
• Cuffie con microfono per la prova di registrazione
• Multimetro per il controllo del contatto esterno del jack

1. Prima su un PC

   lsusb elenca la scheda con ID produttore 0d8c. Poi ho misurato il contatto esterno del jack dell'uscita cuffie rispetto al guscio della spina USB: 0 V.

2. Sul Pi: trovare la scheda

   L'ho collegata con l'adattatore OTG. aplay -l e arecord -l devono elencarla tutti e due, come card N: Device [USB Audio Device].

3. Riprodurre e registrare

   Ho mandato un tono in cuffia, poi ho registrato cinque secondi dal microfono delle cuffie e li ho riascoltati.

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 fa della scheda il dispositivo audio predefinito del Pi, con il suo nome Device. E configura il Bluetooth sia per la musica sia per le chiamate:

Le chiamate sono in banda larga. Il bluez-alsa di Debian (4.0) porta le chiamate solo a 8 kHz. install.sh mette in /usr/local bluez-alsa 4.3.1 compilato con mSBC, dal pacchetto già pronto in packages/ oppure compilandolo, e con dpkg-divert lo sostituisce ai file di Debian. Il telefono allora sceglie mSBC, 16 kHz, sul chip Bluetooth dello Zero W stesso: sul banco sono arrivate parole dette piano che a 8 kHz si perdevano, e i pochi pacchetti danneggiati (circa tre in 75 s) sono stati mascherati. sudo ./install.sh --no-wideband rimette i file di Debian.

Il telefono si associa una volta. Finché l'applicazione è in solo ascolto nessuno risponde alle richieste di associazione, quindi blueandme-pair apre l'associazione per un po', si fida del telefono che si associa e la richiude. Ho associato dopo aver lanciato install.sh, così il telefono vede il profilo vivavoce; un telefono associato prima mostra solo "Media audio" e va dimenticato e associato di nuovo.

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

Ho provato prima la musica, poi una chiamata, con le cuffie sulla scheda audio e un microfono nel suo ingresso. Entrambe le direzioni devono funzionare prima di portare i collegamenti audio in auto. Durante una chiamata, journalctl -u blueandme-sco-uplink mostra quanto audio del microfono è stato inviato.

Il Pi gestisce le chiamate con comandi AT sul collegamento vivavoce: blueandme-call answer per rispondere, blueandme-call hangup per riagganciare e blueandme-call calls per elencarle. Ogni comando mostra la risposta del telefono e ha esito positivo se riceve OK. Dopo un riavvio, blueandme-bt-reconnect ricollega il telefono automaticamente.

Tempi dell’audio delle chiamate

Il servizio che inoltra la voce al telefono scarta l'audio rimasto in attesa per più di 120 ms. Quando ho provato arecord | aplay, si accumulavano quattro secondi di audio tra le chiamate. Ho anche separato i riproduttori per musica e telefonate: con uno solo, la musica non ripartiva dopo aver riagganciato. Controllare il Bluetooth ogni tre secondi e dare più priorità al servizio del microfono ha evitato di sovraccaricare l'unico core.

Il volante

L'applicazione installata trasforma i tasti del volante in azioni sul telefono, come le descrive il manuale Blue&Me della Giulietta (604_38_194, p. 9): l'azione parte quando si rilascia il tasto, e una pressione tenuta più di un secondo è una pressione lunga. A ogni pressione chiede al telefono quali chiamate ci sono (AT+CLCC), così non perde mai il passo. Sul CAN non manda niente, quindi funziona anche in solo ascolto. Sul banco, con i tasti iniettati attraverso il loopback del controller (sudo ~/press.sh phone 1.5), ognuna di queste cose ha funzionato con un telefono vero e una chiamata vera (2026-09-26). In seguito, in auto e con i tasti veri del volante, ho verificato la risposta a una chiamata normale, il riaggancio, il rifiuto di una chiamata, il mute del microfono, il passaggio di una chiamata al telefono e ritorno, e l'assistente attraverso il microfono della plafoniera.

Per passare la chiamata al telefono, il Pi interrompe il collegamento audio Bluetooth (hcitool, HCI Disconnect). Il telefono sposta quindi l'audio sulla propria capsula auricolare. Per riportarlo in auto uso AT+BCC, che chiede al telefono di ristabilire il collegamento. Con bluez-alsa 4.3.1 fermare i riproduttori non basta: la connessione rimane attiva, ma nessuna delle due persone sente più l'altra.

Passo 14 — Portare audio e microfono all'auto

L'uscita cuffie della scheda va ai pin audio del connettore del Blue&Me.

Il contatto esterno del jack è una vera massa (passo 13), quindi lo spinotto si collega pari pari: la punta è il sinistro, al pin 5; l'anello è il destro, al pin 22; il contatto esterno del jack al pin 21.

Sono partito con il volume della scheda basso, ho selezionato Blue&Me e confrontato a orecchio il livello con la radio FM. La regolazione si fa sul Pi con il controllo della scheda. Poi va verificato se c'è ronzio dell'alternatore con il motore acceso. Se c'è, un trasformatore di isolamento audio 1:1 fra la scheda e l'auto interrompe l'anello di massa.

Il microfono. I pin 8 (MIC+) e 24 (MIC−) portano il microfono della plafoniera, che è amplificato. Vuole una sua alimentazione a 5–8 V sul filo di segnale, e un partitore prima dell'ingresso della scheda, perché la scheda non può alimentarlo e il suo segnale è vicino al livello di linea. Il circuito qui sotto fa tutte e due le cose. Su altre auto del gruppo la capsula è un Telicom MIC-98, che secondo il datasheet lavora a 5–8 V attraverso 680 Ω; nessuno ha confermato che la 940 monti lo stesso, quindi il circuito l'ho fatto in modo da poterlo misurare prima di fidarmi. Durante una chiamata l'applicazione dice anche all'autoradio, via CAN, che c'è una chiamata in corso, con il valore usato dal modulo del Doblò.

La basetta di prova del microfono

Ho montato prima il circuito su breadboard. Alimenta il microfono della plafoniera come faceva il modulo originale, ma con meno corrente. Il condensatore blocca la tensione continua e le due resistenze riducono il segnale di circa dodici volte prima dell'ingresso della scheda audio. Con questo circuito ho registrato, misurato il livello, riascoltato e fatto una telefonata. Il circuito di accensione sotto chiave del passo 15 occupa le righe 20–27 della stessa breadboard.

Prova a casa, il 2026-09-27. Ho tolto il ponticello dei 5 V, collegato la punta del cavo audio alla riga 5 e il contatto di massa alla striscia −. Ho riprodotto dalla scheda un tono a 200 Hz: misuravo 520 mV sulla riga 5 e 41.6 mV sulla riga 12. Il segnale si riduceva di dodici volte e mezza. La registrazione era pulita: −37.5 dBFS a 0 dB di guadagno, senza clipping. Con quel guadagno l'ingresso regge circa 2 V prima di saturare, quindi in auto ho iniziato con il guadagno massimo. Se la voce fosse risultata bassa, una resistenza più grande al posto di quella da 1 kΩ avrebbe ridotto l'attenuazione.

Misure sulla mia auto

Per provare il microfono della plafoniera ho registrato la mia voce e qualche fischio, poi ho fatto una telefonata. Ho impostato un guadagno di 15 dB prima di inviare l'audio al telefono (--gain-db 15 in /etc/blueandme/sco-uplink.env). Dall'altra parte mi hanno detto che la voce arrivava molto bene. Era la conferma pratica delle misure.

In auto, in ordine

Ho riunito le prove audio e di alimentazione per il lavoro in auto: il passo 14 e la parte in auto del passo 15. L'ordine qui sotto lascia il Pi sul power bank fino al collegamento finale del convertitore.

A casa, prima di uscire

1. Ho tolto dalla breadboard i fili del cavo audio (la punta dalla sua riga, il contatto esterno del jack dalla striscia −): da lì in poi quel cavo va ai pin audio 5, 22, 21 dell'auto.
2. Ho tolto dalla riga 26 il ponticello provvisorio dei 5 V (serviva per la prova al banco del accensione sotto chiave).
3. Per il viaggio sono rimasti scollegati il ponticello dei 5 V del microfono (riga 1) e i quattro fili verso l'auto (pin 8, 24, 15, 32). Il filo del pin 5 del Pi e la massa sul pin 6 del Pi sono rimasti collegati.
4. Buck: ho saldato un filo rosso su IN+ e uno nero su IN−, ho messo guaina termorestringente sulle piazzole e pin dupont alle estremità.
5. Cosa ho portato: il Pi con MCP2515 e scheda audio, la breadboard, il power bank, il buck con un cavo USB per la porta PWR del Pi, il cavo audio, cavetti dupont, una resistenza da 1 kΩ di scorta, multimetro, telefono, tablet, una pinzetta estrai-fusibili.
6. sudo ~/giulietta-blue-me/preflight.sh finisce con PREFLIGHT PASS, poi sudo ~/giulietta-blue-me/tx.sh off: il Pi resta in solo ascolto mentre si collegano i fili CAN. In auto bisogna poter raggiungere il Pi; io ho usato l'hotspot del telefono.

In auto, prima misurare (Pi sul power bank)

1. Modulo Blue&Me scollegato, can0 ancora in solo ascolto da casa (tx.sh status) mentre si collegano i fili CAN.
2. Volt in continua, puntale nero su metallo nudo: pin 16 circa 12 V sia a chiave spenta sia su MAR (permanente); pin 32 0 V a chiave spenta, circa 12 V su MAR (sotto chiave).
3. Togliendo l'F36 (la scatola fusibili qui sotto) il pin 16 deve scendere a 0 V. Poi si rimette.
4. CAN: il 30 su H, il 14 su L, e il filo della striscia − al pin 15.
5. Quando ip -s -d link show can0 ha mostrato frame in arrivo e nessun errore: tx.sh on. Da lì in poi è il Pi a rispondere all'auto. Ho spento e riacceso il quadro: il contachilometri non ha lampeggiato.

Poi il microfono

1. Solo multimetro, con la basetta ancora staccata dai pin 8 e 24: Ω dal pin 8 al 24, nei due versi; pin 8 e pin 24 verso metallo nudo (OL).
2. Ho messo i fili della basetta sui pin 8 e 24, il ponticello della riga 1 sul pin 2 del Pi e lo spinotto del microfono nell'ingresso MIC della scheda.
3. Con il multimetro in tensione continua, ho messo il puntale nero sulla striscia − e il rosso sulla riga 5. Una lettura nettamente inferiore a 5 V indica che il microfono assorbe corrente; circa 3–4 V è un buon riferimento iniziale. Meno di circa 2.5 V, oppure distorsione sui fischi forti, può indicare che la resistenza da 2 kΩ limita troppo la corrente. Si può sostituirla con una da 1 kΩ o aggiungerne una da 1 kΩ in parallelo, tra le righe 1 e 5. Ho scelto la seconda soluzione: circa 670 Ω, vicini ai 680 Ω del datasheet.
4. Ho registrato sul Pi mentre fischiavo e parlavo verso la plafoniera, e ho riascoltato. Suonava pulito, quindi ho fatto una chiamata di prova con il microfono dell'auto.

Poi l'audio e l'applicazione

1. Ho collegato il cavo audio ai pin 5 (punta), 22 (anello) e 21 (contatto esterno), e lo spinotto all'uscita cuffie. Selezionando Blue&Me, il telefono riproduce musica se l'app è stata usata di recente, e la radio mostra il brano. Ho regolato il volume e ascoltato a motore acceso per cercare eventuali ronzii. Con il Pi ancora sul power bank, la prova andava ripetuta dopo il passaggio all'alimentazione definitiva.
2. Il volante: salto traccia, pausa, l'assistente, rispondere e rifiutare una chiamata.

Poi il sotto chiave (passo 15)

1. Chiave spenta. Ho messo il filo della riga 26 sul pin 32.
2. Ho impostato il Pi perché legga il sotto chiave su GPIO3. Mentre la chiave va su MAR e torna indietro, quell'ingresso deve risultare basso su MAR e alto da spenta.

Per ultimo, il buck (passo 15)

1. Chiave sfilata. Ho tolto l'F36.
2. IN+ del buck (rosso) sul pin 16; IN− del buck (nero) in un foro libero della striscia −, che arriva al pin 15 con il suo filo (circa 0.1 A; nell'installazione definitiva il buck ha un filo di massa tutto suo).
3. Ho spento il Pi (halt). Quando il suo LED si è spento, ho spostato il cavo PWR del Pi dal power bank alla presa USB del buck.
4. Ho rimesso l'F36: il Pi si è avviato dall'auto. La tensione di alimentazione va misurata sul Pi, perché lo Zero W non ha un rilevatore di sottotensione.
5. Ho avviato il motore: il Pi doveva restare acceso. Il mio si è resettato finché non ho cambiato il convertitore; il diodo, il condensatore e i risultati delle prove sono al passo 15.
6. Per lasciarlo ci sono due possibilità: o resta lì, alimentato dall'auto con tx.sh on, oppure torna a casa con me. In quel caso lo spengo (halt), poi tolgo l'F36 prima di scollegare qualsiasi cosa.

Comandi e display della radio

Ho regolato a orecchio il livello Speaker della scheda per pareggiare il volume della radio FM. A −20 dB la musica era troppo bassa; sono arrivato a 0 dB, il massimo della scheda, e l'ho salvato con alsactl store. Poi ho ascoltato con il motore acceso. Non c'era ronzio, quindi non ho avuto bisogno di un isolatore di massa. Quel primo controllo era con il power bank. Anche con l'unità alimentata dall'auto e il motore acceso non c'è ronzio.

Alcuni tasti sono gestiti direttamente dalla radio. Fuori da una chiamata comunica sul CAN se è in mute, e il Pi mette in pausa il telefono finché l'audio non viene riattivato. Ho letto da questi messaggi anche le frecce della radio. Sinistra e destra cambiano brano; su e giù regolano il volume Bluetooth.

Il testo del brano usa il formato del modulo del Doblò, con il suo set di caratteri a 6 bit, come decodificato in fiatcan, e l'autoradio della Giulietta lo accetta. La riga in alto mostra i primi dodici caratteri di un campo di testo, quindi il Pi ci fa scorrere "artista - titolo" ogni quarto di secondo. La riga in basso mostra un altro campo, che porta il tempo come M:SS. Quattro codici di quel set su questa radio non mostrano niente e nessuno è una parentesi, quindi le parentesi in un titolo diventano *.

Passo 15 — Installazione definitiva

Dopo aver verificato l'audio al passo 14, ho collegato l'alimentazione permanente. Il Pi riceve i 12 V permanenti dell'auto attraverso il fusibile F36. Rimane in standby fino a 72 ore, pronto a rispondere al PROXI quando l'auto si risveglia. Poi si spegne. Ho aggiunto altri componenti quando le prove ne hanno mostrato la necessità.

Perché il Pi resta acceso in parcheggio

L'auto chiede il PROXI circa un secondo dopo essersi svegliata, cioè quando la si apre, prima di girare la chiave. Chiede tre volte nel giro di pochi secondi. Un Pi che deve avviarsi in quel momento arriva troppo tardi, e di molto: in un avvio a freddo il 2026-09-27 il firmware ci ha messo circa 3.8 s, il kernel 5.6 s, e l'applicazione era sul bus circa 53 s dopo l'accensione.

Un Pi già acceso risponde subito: 3.3 ms riproducendo sul banco il traffico dell'auto (passo 11), 8 ms dallo script sorvegliato nella cattura ZB. In tutte le prove fatte finora il Pi era acceso quando l'auto si è svegliata, quindi al PROXI è sempre arrivata risposta e il contachilometri non ha mai lampeggiato. Cosa fa l'auto quando un Pi parte solo dopo il suo risveglio, come succederebbe dopo una sosta più lunga dell'attesa, non l'ho provato.

Il consumo che ho misurato in standby

Misurato sul banco con un misuratore di potenza USB sull'ingresso a 5 V del Pi (experiments/standby/). Lo standby spegne Bluetooth e Wi-Fi, mette la CPU alla velocità minima e spegne il LED; l'interfaccia CAN resta attiva, nella modalità impostata da tx.sh, per accorgersi che l'auto si sveglia (in auto: in trasmissione, così al PROXI si risponde subito).

Per il calcolo ho assunto 12.4 V e un convertitore buck con efficienza dell'80 %. La capacità reale della batteria va letta sull'etichetta. Il Pi spento assorbe ancora circa un terzo della corrente di funzionamento. Tre settimane di parcheggio consumano circa 4.7 + 11 Ah, intorno al 22 %. Per assenze più lunghe tolgo F36 e interrompo l'alimentazione.

Blue&Me non è disponibile quando il Pi è spento. La radio non può usare la sorgente e il PROXI resta senza risposta. Togliendo e rimettendo F36 il Pi riparte ed è pronto in circa un minuto. Se le soste lunghe sono frequenti si può aggiungere il circuito di risveglio dal quadro descritto sotto; basta poi girare la chiave.

Risveglio dallo standby. blueandme-standby entra in standby dopo un minuto senza traffico, a quadro spento. Si risveglia con un messaggio CAN quando si sblocca l'auto, oppure dalla linea del quadro se collegata. Nella mia prova al banco con un messaggio, la musica era pronta in 3.3 s e le chiamate in 3.7 s. Da spento servono 33.5 e 34.2 s. Il servizio si attiva solo dopo aver visto traffico dell'auto: sul banco, con bus sempre silenzioso, non entra in standby.

L'installazione

Non ho ancora reso il filesystem radice di sola lettura. La scheda ha superato finora le interruzioni di corrente, ma questo non dimostra che sia al sicuro dai danni.

Accensione sotto chiave

Facoltativo: permette al quadro di riavviare un Pi che si è spento dopo una sosta di più di 72 ore; senza, si toglie l'F36 e lo si rimette. Tre componenti del kit sulle righe 20–27 della breadboard del microfono, con la sua stessa striscia −. Quando la chiave è su MAR, il transistor tira a massa il pin 5 del Pi (GPIO3), e un Pi spento parte.

Provato al banco il 2026-09-27. I 5 V del Pi stesso (pin 2) sulla riga 26, al posto del sotto chiave, hanno portato GPIO3 a 0; senza, 1. Un Pi spento è partito nel momento in cui li ho collegati (spento alle 14:38:48, di nuovo in rete alle 14:39:56). Quel ponticello provvisorio dopo l'ho tolto, altrimenti il Pi riparte ogni volta che si spegne. In auto servono solo il filo del pin 32 e due righe di configurazione (ignition_gpio: 3, ignition_active_low: true).

Da 12 V a 5 V

Il convertitore non va sulla breadboard: ha le proprie piazzole di saldatura e l'uscita USB. Così tengo i 12 V separati dalla breadboard e dai pin del Pi.

Saldato, senza breadboard

Per l'installazione definitiva il circuito del microfono è saldato, con ogni giunzione coperta dalla guaina termorestringente: in auto una breadboard con le vibrazioni si allenta. Il circuito di accensione sotto chiave va sulla millefori della parte successiva. Valori come sono rimasti in auto (2026-09-27): con una da 1 kΩ accanto alla 2 kΩ il microfono stava a 2.37 V (2.16 V con la sola 2 kΩ) e registrava pulito a guadagno massimo, fischi forti compresi.

1. Ho tagliato i fili a misura. Prima di saldare ho infilato un pezzo di guaina su ogni filo che finisce in A, B o G, e uno su ogni componente da unire.
2. La 2 kΩ e una da 1 kΩ affiancate, con i reofori attorcigliati insieme ai due capi (circa 670 Ω); un capo al filo del pin 2 del Pi.
3. A: l'altro capo della coppia, il reoforo + del condensatore e il filo del pin 8 dell'auto, attorcigliati e saldati. Il reoforo − del condensatore a un capo della 10 kΩ.
4. B: l'altro capo della 10 kΩ, la seconda da 1 kΩ e il filo della punta dello spinotto del microfono.
5. G: l'altro capo di quella da 1 kΩ, i pin 24 e 15 dell'auto, il contatto esterno del jack dello spinotto del microfono e il filo di massa del Pi.
6. Ho fatto scorrere ogni guaina sulla sua giunzione o sul suo componente e l'ho ristretta (con una pistola ad aria calda, oppure con un accendino tenuto sotto, non dentro la fiamma).
7. Multimetro in Ω prima di andare in auto: dal filo del pin 2 del Pi al filo del pin 8 dell'auto circa 670 Ω; dalla punta del microfono a massa circa 1 k; dal pin 8 dell'auto a massa aperto.

Accensione sotto chiave e sostegno dell'alimentazione durante l'avviamento su un'unica millefori

I due circuiti che toccano i 12 V dell'auto, su un solo pezzo della millefori del kit (fori metallizzati, nessuno collegato): 10 colonne × 24 righe, la misura della basetta da 3 × 7 cm (su un'altra basetta i fori vanno contati). Il circuito di accensione sotto chiave prende le righe A–G; la riga H resta vuota; il sostegno dell'alimentazione durante l'avviamento prende le righe I–X, quasi tutte occupate dal condensatore sdraiato. I componenti stanno sopra, i collegamenti si fanno sotto con i reofori piegati e ponti di stagno. Con il condensatore sdraiato la basetta è alta circa 21 mm.

Sostegno dell'alimentazione durante l'avviamento e rimedio per il convertitore (2026-10-01). Il Pi installato si resettava durante l'avviamento nonostante un condensatore da 2200 µF che avevo aggiunto. Il convertitore originale, venduto per 6–32 V, dava 0 V con un alimentatore da banco a 10 V, anche con il Pi scollegato e l'alimentatore in tensione costante. L'uscita tornava verso gli 11 V; a 12 V di alimentazione il multimetro misurava 5.09 V in uscita. Cambiando il convertitore i reset sono spariti. Il sostituto, un modulo step-down USB TECNOIOT da 6–24 V a 5 V, ha tenuto acceso il Pi fino a 5 V sull'alimentatore da banco; la tensione sul Pi con quell'ingresso non l'ho registrata. Inoltre l'IN− del buck è risultato scollegato e l'ho ricollegato prima di queste prove; gli serve un ritorno tutto suo al pin 15. Il pin 16 arriva al buck attraverso un diodo, con il condensatore da 2200 µF montato in parallelo a IN+/IN− subito dopo. Serve un condensatore da almeno 35 V; la banda del diodo guarda verso il condensatore. Questo rimedio non ha richiesto di aumentare la capacità. La forma d'onda dell'avviamento dell'auto non l'ho ancora misurata; nel calcolare il tempo di tenuta non va dato per buono un limite d'ingresso dichiarato di 6 V.

1. Ho iniziato dal transistor: ho allargato E e C per inserire i piedini in B3, B5 e B7, con la faccia piatta verso la riga C. Ho saldato sotto, senza unire i tre punti di saldatura.
2. Le due resistenze e l'1N4007, sdraiati sulla basetta, banda in F5; il diodo dell'avviamento in J10–J6, banda in J6. Ho saldato, lasciando i reofori lunghi finché le piste non erano fatte.
3. Ho piegato i due reofori del condensatore a 90°, a circa 3 mm dal corpo: + in L6 e − in L3. Ho disposto il corpo in orizzontale verso la riga X, saldato e fissato con colla. Si può anche usare una fascetta attraverso due fori liberi.
4. Le piste sotto: ho steso ogni reoforo lungo sulla sua pista e l'ho saldato nei fori successivi; il resto l'ho fatto con ponti di stagno o con uno spezzone di filo nudo. Sotto chiave: B3–B1–G1, B5–F5, B7–B9, E9–G9. Avviamento: I10–J10, J6–K6–L6–L10, K1–L1–L3. La riga H e tutto il resto restano separati.
5. I sette fili entrano da sopra e si saldano sotto.
6. Multimetro in Ω, niente collegato: da C a E aperto nei due versi; dal filo del pin 5 del Pi al filo di massa del Pi aperto; dal filo del pin 32 dell'auto a B5 circa 100 k. Lato avviamento: dal filo del pin 16 dell'auto al filo IN− del buck non deve leggere vicino a 0 (il condensatore si carica dal multimetro, quindi la lettura sale); tra IN+ e IN− del buck lo stesso; in prova diodi, da I10 a L10 circa 0.3–0.7 V in un verso, niente nell'altro. Poi una goccia di colla sulle saldature dei fili.
7. In auto, con l'F36 tolto, ho collegato i fili e ho rimesso l'F36. Resta da leggere GPIO3 mentre la chiave va su MAR e torna (0 su MAR, 1 da spenta), e da vedere che il Pi resti acceso durante un avviamento; lo Zero W non ha un rilevatore di bassa tensione, quindi get_throttled=0x0 non prova che l'alimentazione sia stabile. Se si resetta, vanno misurati con un oscilloscopio l'ingresso del buck e i 5 V del Pi.

• Non ho ancora completato la prova di parcheggio prolungato. Occorre controllare la batteria dopo una notte e poi dopo quattro giorni. Il Pi deve spegnersi dopo 72 ore; blueandme-standby deve registrare lo spegnimento e il Wi-Fi smettere di rispondere. Rimettendo F36, oppure girando la chiave con il circuito di risveglio installato, il Pi deve ripartire. Il funzionamento quotidiano non dimostra che non scarichi la batteria durante una sosta più lunga.

Montaggio di custodia e connettore

La custodia originale misura 150 × 175 × 40 mm e ha quattro supporti per viti M3. La plastica PP-TD40 lascia passare il Bluetooth. Per stampare telaio e base di montaggio servono PETG o ASA; il PLA può ammorbidirsi in un'auto parcheggiata. Oltre a controllare il modello, bisogna provare gli ingombri dei cavi e degli spinotti reali e fissare tutto prima di chiudere.

Per eliminare l'adattatore USB ho accorciato il cavo della scheda audio e l'ho saldato alle piazzole di test sotto il Pi. PP1 corrisponde a 5 V, PP6 a massa, PP22 a D+ e PP23 a D−. L'uscita a 5 V del convertitore va ai pin 4 e 6 del Pi.

Il connettore usa 32 pin quadrati da 0.64 mm, a passo 2.54 mm, su millefori tagliata a 2 × 16 fori con un bordo di circa 5 mm. Sono cablati solo i pin necessari. Prima di collegarlo, segnare i pin 1 e 17 e verificarli con i numeri "1" e "17" stampati sulla spina.

Fissare e isolare i fili sui pad USB. Se la scheda scompare con device descriptor read/64, error -71, controllare i cavi dati e le saldature. Non azzerare il controller USB dello Zero W tramite unbind: nella mia prova ha causato un crash del kernel e l’USB è tornato solo togliendo alimentazione.

Wi-Fi durante l’audio

Sullo Zero W, Bluetooth e Wi-Fi condividono lo stesso chip radio. Ho misurato queste perdite di pacchetti con il Pi collegato all'hotspot del telefono. Spegnendo il Wi-Fi, le interruzioni della musica sono sparite.

Ho aggiunto un piccolo servizio perché lo facesse al posto mio. Controlla i flussi audio Bluetooth ogni tre secondi e spegne il Wi-Fi durante la musica o una chiamata. Trenta secondi dopo la fine dell'audio lo riaccende. Lo ripristina soltanto se l'aveva spento lui, quindi non interferisce con lo standby.

In auto il Wi-Fi si spegne due secondi dopo l'inizio della musica. Quando voglio collegarmi al Pi via SSH, metto in pausa e aspetto circa 40 secondi.