BMW Serie 1 E81/E82/E87/E88 Soluzione aggiunta Bluetooth Arduino + KCAN

Si, vanno mantenuti tutti come input per come funziona il sistema di rilevazione tasto premuto. Vengono switchati ad output solo quando il tasto deve essere premuto. l'MCU dell'unità BT usa un solo ingresso ADC per rilevare il tasto premuto definito da un partitore di tensione fatto da una rete di resistenza. Se le uscite delle porte fossero tutte ad impedenza bassa questo non funzionerebbe correttamente. Quindi per quel tipo di modulo BT i diversi tasti vengono rilevati così - se poi si usa un altro tipo di modulo con altri ingressi magari separati il discorso va analizzato ma con questo è così.

 

Il microfono è già saldato su, puoi dissaldarlo e prolungarlo usando un cavo schermato/coax da microfoni se ce l'hai oppure anche un classico doppino se il percorso è corto.

 

No, il bus CAN è gestito dal MCP - questo riceve i comandi dall'arduino in protocollo SPI. Cerco di spiegare in breve come funziona il tutto:
traffco BUS K-CAN -> MCP2515 (filtrato) -> verso arduino in SPI
5 OUTPUT (pin 5-9) Arduino -> 5 Tasti modulo BT (rete divisoria su unico pin del MCU sul modulo BT)

l'MCP 2515 riceve dal bus CAN il comando per es. CORNETTA (filtrando tutto il traffico di ID che non servono) e lo invia tramite SPI all'Arduino. Usando l'Arduino io traduco come PLAY il comando cornetta emulando la pressione del relativo tasto.

Il lavoro pesante lo fa in realtà l'MCP2515 che filtra tutto il traffico non necessario e fa passare solo l'ID che interessa (comandi volante). L'Arduino non fa altro che leggere questi comandi ed interpretarli e trasformare il comando CAN in pressione tasto sul moduo BT.

Il modulo BT in questione ha 5 tasti. Ogni tasto non è collegato al Microcontrollore del modulo BT (un 1743NRZ della Electrodragon) separatamente ad un ingresso dedicato, ma sono collegati tramite una rete partitore di resistenze ad un unico ingresso ADC. Quindi ogni volta che si preme un tasto si genera una tensione diversa sul pin input del MCU 1743NRZ ed in base a questa tensione lui identifica il comando. E' un modo per risparmiare pin di input. Quando non vengono premuti tasti, l'ingresso è "floating" o meglio e ad alta impedenza. Se quindi lasciamo le uscite dell'arduino (del 328p) BASSE (quindi come OUTPUT) il sistema non funziona perchè i valori del partitore sarebbe falsati. IN pochi parole è come se tenessi premuto uno e due tasti assieme sempre del modulo - è chiaro che il risultato non è quello voluto. Quindi per emulare correttamente la pressione del tasto, i pin di "uscita" sono configurati come ingressi e solo quando il tasto deve essere premuto viene commutato in uscita/output, emulando la pressione del tasto, e subito dopo viene riportato ad input.

 

Qui vedi come è collegato il CAN transceiver con l'MCP2515; sono collegati i 4 pin SPI: SS(CS)/MOSI(SO)/MISO(SI)/SCK -> 10,11,12,13 su arduino. I 5 tasti sono i pin Digitali da 5 a 9 che vanno saldati sugli interruttori del modulo BT dalla parte verso la rete partitore (quindi lato resistenze, puoi usare la mia foto nel primo post come riferimento se la configurazione tasti è la stessa).

 

Allora, dando un occhio al sistema sulla E46 il bus è il "classico" I/K bus e non CAN quindi devi adottare un altro transceiver per tradurre i comandi. Questo è già stato fatto utilizzando un TH3122 e puoi vedere come qui:
http://curious.ninja/blog/arduino-bmw-i-bus-interface-intro/

Inoltre un certo Resler ha creato una chiavetta USB che si collega con 3 fili (+ - e Ibus) al bus che puoi collegare ad un portatile (usando NavCoder) o via BT ad uno smartphone (IBusApp) per vedere tutti i dati.

Come dicevo, il vecchio I/K Bus viaggia su 1 filo ed è uno standard diverso da quello ormai industriale e largamente adottato CAN. Basandoti sul suddetto schema puoi facilmente modificare il codice per interfacciarti con il tuo I-Bus ed ottenere lo stesso risultato. Unica cosa è che il 328p (Arduino Uno/Nano/Mini) ha solo una porta seriale RS232 e quindi dato che il TH3122 usa questo protocollo per comunicare, dovrai dedicare la porta seriale per questo ed il debug seriale eliminarlo - oppure - inserire la libreria softwareserial dove puoi aggiungere un'altra seriale (non quindi quella integrata) per un minimo di debug (ma devi usare un convertitore RS232-TTL se vuoi usarla). Insomma un modo per interfacciarti lo trovi, fondamentalmente hai bisogno solo del transceiver TH3122 per adattare il progetto. Ci sono potenzialmente altri transceiver per lo scopo (forse anche SPI) - bisogna indagare meglio.

 

Si è fatto l'interprete usando un classico PIC della Microchip (scrivevo direttamente in ASM per quella famiglia di MCU oltre 20 anni fa) collegato direttamente alla sua UART RX senza usare un transceiver dedicato. Potenzialmente puoi usare la libreria softwareserial per ricevere frame del I/K bus senza alcun transceiver. La seriale Ibus è 9600 8 E 1 (8 bit Even parity 1 bit stop) quindi potresti usare la seriale integrata del 328p o usare la softwareserial così hai anche debug sulla seriale integrata. Ha "mascherato" l'ingresso UART del PIC con uno Schottky per protezione anche quando spento e con una resistenza da 10K come pullup (con questa configurazione riceve dal bus e basta). Direi che potresti provare direttamente senza il transceiver per la sola ricezione che è quello poi che ti interessa fare. Per invece mandare anche dei comandi la cosa diventa più complicata perchè va considerato ed implementato il collision detection - devi quindi aggiungere dei componenti per rilevare che il bus non sia in uso da altre periferiche ed evitare di corrompere i dati. A quel punto il transceiver TH3122 è più adeguato dato che implementa già tutto questo al suo interno.