Oggetto: Interni VW Golf5 | Messaggi 64+

Potrebbe esserci un problema con questo protocollo NM-Ring? Se solo sapessi quali messaggi o sequenze di messaggi sono importanti. Proverò ancora un po'…
esattamente, questo sarà il tuo problema.

A quale scopo serve esattamente questo protocollo MN? Il processo, invece, mi è abbastanza chiaro. Un dispositivo di controllo si disconnette dal bus CAN quando il protocollo ad anello fallisce? Ci sono dei flag chiamati SleepInd (bit 12, Ind = indicatore???) e SleepAck (bit 13) che, secondo le misurazioni del bus CAN, sembrano essere collegati ai bit Ring/Alive (bit 8 e 9) già menzionati in questo thread (che producono valori 0x11 e 0x12).

Il protocollo serve a informare le altre centraline quali dispositivi sono collegati al CAN bus, al fine di attivare e disattivare le centraline stesse.

Quando un'unità di controllo desidera stabilire una connessione di rete, ma ciò non è possibile e, successivamente, non ha più alcun bisogno di comunicare, si disconnette e torna in uno stato di inattività. Se si verificano richieste di comunicazione, il sistema passa in modalità di emergenza.

Ho simulato il funzionamento dell'anello. Sto inviando i messaggi NM per gli indirizzi 0x00, 0x01, 0x0a, 0x0b e 0x0e alla centralina della porta disconnessa della Golf 5. L'indirizzo della centralina della porta è 0x03. In realtà, anche il modulo di controllo della porta si integra perfettamente nel sistema, e lo fa in questo modo:

ID: 0x403 DLC: 6 DATI: 0x0a 0x01

Dopo alcuni cicli di squillo, l'unità di controllo della porta invia:

ID: 0x403 DLC: 6 DATI: 0x0a 0x11

cioè, il bit di segnale di chiamata (0x01) viene associato a un bit di segnale SleepInd (0x10). Nonostante ciò, l'unità di controllo della porta continua a partecipare ai cicli di comunicazione.

Perché si spegne improvvisamente in modalità sleep (se SleepInd indica effettivamente questo), nonostante sia collegato al sistema di alimentazione? Come posso impedirgli di andare in sleep mode? Inoltro costantemente anche il messaggio relativo all'accensione (ID 0x2c3).

Non è disattivato. Semplicemente, indica che vorrebbe andare in modalità sleep. Finché le altre centraline non segnalano anch'esse di voler andare in modalità sleep, anche la centralina della porta non entra in modalità sleep. Questo vale per tutti i dispositivi di controllo NWM.

E sì, stai inviando lo stato di accensione. Ma quello sbagliato. Stai inviando lo stato della chiave, ma non quello che permette la centralina del quadro strumenti . Controlla il segnale di accensione in 0x575. Quello sarà il valore corretto. Questo messaggio viene inviato dalla BSG. L'altra del ZAS...

E sì, stai inviando lo stato di accensione. Ma quello sbagliato. Stai inviando lo stato della chiave, ma non quello che permette la centralina del quadro strumenti . Controlla il segnale di accensione in 0x575. Quello sarà il valore corretto. Questo messaggio viene inviato dalla BSG. L'altra del ZAS...

Sono riuscito a inviare comandi per l'alzacristalli e per la regolazione degli specchietti alla portiera del passeggero, che era stata separata dal veicolo. È necessario, almeno, un ciclo di comunicazione funzionante e l'invio periodico dell'ID messaggio 0x591 (rilascio alzacristallo = bit 1).

Ho appena collegato il mio secondo pannello di controllo Climatronic per i test.
Collegato e connesso al CAN-Hacker, ecco, vengono inviati messaggi NM.
Ho poi sperimentato un po' con l'invio di messaggi tramite il sistema di notifiche a cerchio.
Ora ho il problema che il pannello di controllo non invia più alcun dato al bus CAN.
Potrebbe essere che il pannello di controllo si trovi in uno stato di errore in cui non trasmette più messaggi CAN (condizione di 'bus off')?
Riesco a rimettere in funzione questo componente senza utilizzare un dispositivo VAG-Com?

Deve essere attivato tramite il protocollo CAN, ma, come già detto più volte, questo non può funzionare in modo sicuro con il CANhack. Il CANhack utilizza un transceiver ad alta velocità. Il sistema Climatronic richiede un transceiver a bassa velocità.

Scollegare l'unità di controllo per un po' di tempo, in modo che tutti i condensatori si scarichino, quindi collegarla al CANhack e riaccendere l'alimentazione. A quel punto, l'unità di controllo dovrebbe normalmente avviarsi brevemente e inviare messaggi CAN.

Ma, come ho detto... CANhack + LowspeedCAN = affidabilità imprevedibile!

Ok, grazie per l'informazione!
Potrebbe essere stato un puro caso che l'hacker di CAN abbia 'visto' i telegrammi.

Beh, lui vedrà più cose di quanto lei abbia mai visto, e senza un'azione specifica, lei non verrebbe rappresentata in can tool, giusto?

Sì. L'interfaccia deve aver inviato un messaggio di conferma. Tuttavia, a causa di condizioni 'temporaneamente ottimali', a volte può funzionare. La regola sarà che, semplicemente, non funzionerà .

Avete già integrato un trasmettitore-ricevitore a bassa velocità nell'interfaccia CAN Hacker?

Ecco, io non lo farò. E non lo farò nemmeno in futuro. Ho provato a usare un adattatore. L'adattatore si poteva collegare al CANhack e avrebbe dovuto convertire il segnale a bassa velocità, ma l'adattatore non si è comportato come volevo. Ora giace in un angolo e non riceve più l'attenzione di nessuno.
Installare un altro transceiver è problematico perché è necessario disattivare quello esistente e poi inserire il nuovo transceiver nell'alloggiamento. Queste operazioni non sono così semplici da eseguire. Sarebbe meglio se l'interfaccia avesse entrambi i transceiver integrati di serie e offrisse la possibilità di commutazione tra di essi.

L'interruzione prolungata dell'alimentazione ha fatto sì che il pannello di controllo si sia riattivato.
Mi occuperò ora del NWM.
Vediamo se riesco a farcela.

Stavo pensando di sostituire il transceiver ad alta velocità con uno transceiver a bassa velocità compatibile.
Supponendo che esista una parte del genere.

SGM.

Purtroppo, non esistono transceiver a bassa velocità compatibili.

Certo, è una cosa stupida .
Beh, vediamo cosa si può fare.
Dopo che il pannello di controllo si è riattivato, posso continuare i test con il trasmettitore ad alta velocità.

SGM.