Audi A3 8P: Guida al sistema FIS centrale

Ciao,
Attraverso l'analisi e la decodifica dei dati registrati, ho compreso il funzionamento del sistema di controllo dell'area centrale del display nell'A3 8P e posso visualizzare qualsiasi tipo di testo, simbolo di navigazione e grafica sul display.
Sorprendentemente, a quanto ne so io, solo pochissime persone ci sono riuscite. Diversi prodotti che descrivono l'area FIS utilizzano per questo lo standard telematico, che però non è più disponibile nei tachigrafi più recenti.

Qui è necessario utilizzare la modalità di navigazione, ovvero simulare un sistema di navigazione RNS-E di Audi.

In questo post, mi concentrerò solo sulle basi della comunicazione. Le procedure dettagliate devono essere sviluppate autonomamente .

Veicolo: Audi A3 8P, immatricolazione 05/2011, con contachilometri (codice TN terminante con 932), display informativo multifunzione (FIS) grande e bianco.
Autoradio: Audi RNS-E modello 193 (quello con il tasto "Media").

Fondamenti:
Per poter visualizzare le prime due righe di informazioni, il sistema radio deve registrarsi nell'anello OSEK. Il sistema radio trasmetterà quindi periodicamente dei testi (di 2x8 caratteri) sul CAN bus. L'unità di visualizzazione (FIS) mostrerà questi testi, ma non invierà alcuna conferma. Per inviare testi personalizzati, è necessario inserire un router CAN (gateway) tra il sistema radio e il CAN bus, che filtrerà gli ID specifici (0x363 + 0x365), mentre tutti gli altri frame dovranno essere trasmessi.

Ho risolto il problema utilizzando una piccola scheda basata su un microcontrollore STM32F4.

Per la sezione centrale del FIS, non è necessaria alcuna registrazione OSEK. È possibile accedere al FIS anche senza radio, il che è addirittura più semplice perché non è necessario filtrare alcun frame. Per i miei scopi, continuo a utilizzare il mio modulo e filtro i messaggi rilevanti tra l'auto e il sistema RNS-E, e viceversa.

Per la comunicazione, sono responsabili due identificativi: 0x6C0 e 0x6C1 (0x6C0 proviene dal sistema di navigazione RNS-E, mentre 0x6C1 proviene dal quadro strumenti).

Per capire il protocollo, è sufficiente "semplicemente" registrare questi due ID sul bus di informazioni e imparare a interpretarli .

Elementi fondamentali:
Dopo l'accensione del motore, viene stabilito un protocollo di comunicazione tra il tachimetro e il sistema RNS-E, simile a una sessione OBD. La connessione può essere avviata e terminata da entrambi i dispositivi.
Il partecipante 1 invia ripetutamente una sequenza di avvio per stabilire la connessione. Se l'altra parte non risponde entro un certo periodo di tempo, il tentativo di connessione viene interrotto e non viene riprovato.

Se un partecipante risponde alla richiesta, vengono inviati ulteriori pacchetti di dati all'altra parte e viene fornita una risposta appropriata. Inoltre, esistono due tipi di messaggi: alcuni che non devono essere confermati dall'altra parte e altri che richiedono una conferma.

Per osservare il processo, si registrano i due ID e si accende l'accensione. Dopo un breve periodo, la connessione viene stabilita e mantenuta tramite messaggi "Keep-Alive". Successivamente, si passa alla modalità navigazione sul sistema RNS-E e si attiva la bussola nelle impostazioni. A questo punto, è possibile visualizzare i dati trasmessi dalla radio al cruscotto per mostrare la direzione e il nome della strada corrente nel display informativo del conducente (FIS).

Tipi di notizie:
0x52 è la modalità comando.
0x57 è la modalità dati.
e altri ancora, ad esempio, per la modalità grafica, per controllare singoli pixel.

Con la modalità comando, ad esempio, è possibile definire l'area del display FIS in cui si desidera scrivere (massimo 64x48 pixel). In questa modalità, l'area può essere definita, cancellata o riempita di bianco.

La modalità dati invia al cruscotto più blocchi di dati consecutivi per poter visualizzare, ad esempio, testi più lunghi.

Un frame che inizia con l'esadecimale 1x deve essere confermato dalla controparte. Un frame che inizia con l'esadecimale 2x non richiede una conferma.

Nell'analisi dei file di log, si nota rapidamente come viene confermata la ricezione. In breve, ogni partecipante ha un contatore sequenziale a cui vengono aggiunti valori esadecimali "1x" o "2x", ad esempio "10", poi "11", e così via. Quando si raggiunge il valore esadecimale "1F", si verifica un overflow e il contatore ricomincia da "10".

I testi possono avere diverse formattazioni.
Carattere più grande, carattere più piccolo, bianco su nero, nero su bianco, operazione XOR per la visualizzazione, operazione OR per la visualizzazione, allineamento a sinistra e centrato.
Inoltre, esiste un set di caratteri che genera simboli grafici per le icone di navigazione. Tuttavia, è necessario combinare più caratteri per creare, ad esempio, una freccia a sinistra, poiché ogni carattere ha una dimensione massima di 6x7 pixel.

L'RNS-E, tra l'altro, non sfrutta tutte le potenzialità del FIS. Ad esempio, è possibile indirizzare direttamente singoli pixel in modalità grafica, cosa che l'RNS-E non fa.

Dato che stiamo parlando di pixel, la risoluzione è di 64x48 pixel. Un pixel è composto da 4 sottocomponenti, che io chiamo subpixel.
In pratica, si verifica una doppia esposizione. Nel frattempo, ho trovato un modo per indirizzare questi subpixel.
È importante sottolineare che non ci si può aspettare miracoli di velocità dal display FIS, poiché esso svolge un ruolo secondario nel tachimetro (il tachimetro fa molto più di quanto si pensi!). Pertanto, avere "Doom" visualizzato sul FIS non è auspicabile .

Dopo ogni frame inviato al tachimetro, è necessario inserire una breve pausa, altrimenti i frame potrebbero essere persi e il testo potrebbe arrivare frammentato o, nel peggiore dei casi, la connessione potrebbe bloccarsi. Non c'è bisogno di preoccuparsi, con l'Info-Bus non si può danneggiare nulla. Basta spegnere e riaccendere l'accensione e tutto torna a funzionare.

Bene, per ora è tutto.

Ciao 8pa .

Lo trovo interessante anche come non proprietario di un'auto Audi, vedere come funziona con altri marchi . Finora, ho avuto modo di sperimentare solo con l'Astra G CID e la (più recente) Vectra C CID, che si assomigliano molto tra loro.

Ecco come appare la mia attuale scheda di sviluppo CAN, progettata e saldata da me.

Il cuore del sistema è un microcontrollore STM32F4 con una frequenza di clock di 168 MHz, dotato di due transceiver CAN, memoria EEPROM, 2 regolatori di tensione e un pulsante di reset .
La scheda può essere equipaggiata anche con un microcontrollore STM32F1.
Il modulo presenta connessioni esterne per 2 porte CAN, alimentazione continua, 5V e massa. Sulla scheda sono inoltre presenti connettori per SWD e UART.

Naturalmente, l'alimentazione è progettata per essere conforme agli standard automobilistici; il modulo si attiva automaticamente in presenza di attività sul bus CAN e passa in modalità standby quando non viene utilizzato, ovvero entra in uno stato di riposo autonomamente e consuma solo pochi microampere.

Schau mal einer guck, nach Jahren mal wieder was interessantes hier. Grazie per questo!

La scheda sembra buona, dove la produci, se posso chiedere?

Contesto: Attualmente utilizzo PCAN-USB e il mio smartphone per intercettare i dati del CAN bus, ma ovviamente non posso installare questi dispositivi come centralina aggiuntiva. Pertanto, potrebbe essere che in futuro avrò bisogno anche di una scheda elettronica (e purtroppo intendo dire 'una', dato che ne ho già una).

Saluti,
Non ho ricevuto alcun testo da tradurre. Per favore, fornisci il testo che desideri venga tradotto dal tedesco all'italiano.

Ho progettato il circuito stampato con Eagle e l'ho fatto realizzare da PCB Joker. Sicuramente esistono produttori di circuiti stampati più economici, ma la qualità è eccellente.

Ho montato io stesso i componenti. I miei occhi, ormai vecchi, hanno bisogno di un microscopio per il controllo finale. L'STM32F4 ha una distanza tra i pin di 0,5 mm .

Grazie per il feedback!

Devo dire che questo è davvero impressionante!
Il fatto che tu abbia dedicato tempo a studiare il flusso di lavoro del sistema FIS e a comprenderlo veramente, e che non ti sei dimenticato di menzionare anche la tua azienda, è davvero notevole!

Grazie per aver condiviso le tue scoperte!


Riguardo al PCB Joker, avete idea se effettuano spedizioni anche al di fuori della Germania?
Ho cercato fornitori per i miei progetti e finora solo Seeed si è distinto dagli altri nella mia ricerca.

Ciao.
Grazie mille.

Sì, PCB Joker effettua consegne in alcuni altri paesi al di fuori della Germania; dai un'occhiata a questo sito -> http://www.pcb-joker.com/versandkosten.html

Va bene.
Ecco una breve guida su come scrivere un testo nell'area centrale del display FIS. Si presuppone che la connessione al tachimetro sia già stata stabilita! Come funziona in linea di principio, l'ho menzionato all'inizio e ognuno dovrebbe essere in grado di dedurlo da solo. Questo non è una soluzione pronta all'uso!

TEST

Codice:

6C0 = ID RNS-E 6C1 = ID Tacho 1: 6C0 8 10 52 05 02 00 1B 40 30 2: 6C1 1 B1 3: 6C0 8 21 57 07 02 01 01 54 45 4: 6C0 3 12 53 54 5: 6C1 1 B3

Le righe, una per una:

Codice:

1: 6C0 8 10 52 05 02 00 1B 40 30 = Definiert und löscht den gewünschten FIS Bereich

Significato dei byte.
0.. Conferma necessaria.
1 .. Modalità comando.
2 .. Numero di byte.
3. Definisce e elimina l'area FIS.
4. Coordinata X dell'area FIS.
5. Coordinata Y dell'area FIS.
6. Ampia gamma di prodotti FIS.
7 .. Altezza della zona FIS.

Codice:

2: 6C1 1 B1 = Tacho sendet Bestätigung

Codice:

3: 6C0 8 21 57 07 02 01 01 54 45 = Teil 1 der Textausgabe

Significato dei byte.
0.. Nessuna conferma richiesta.
1 .. Modalità dati, testo.
2. Numero di byte dei dati.
Carattere più grande, bianco su sfondo nero, allineato a sinistra.
4 .. Coordinata X del testo.
5.. Coordinata Y del testo.
6 .. Codice ASCII per la lettera "T".
7 .. Codice ASCII per la lettera 'E'.

Codice:

4: 6C0 3 12 53 54 = Teil 2 der Textausgabe

Significato dei byte.
0.. Conferma necessaria.
1 .. Codice ASCII per la lettera "S".
2 .. Codice ASCII per la lettera "T".

Codice:

5: 6C1 1 B3 = Tacho sendet Bestätigung

Il risultato è visibile nell'allegato...

Come protocollo di trasporto, viene utilizzato il TP2.0.
http://jazdw.net/tp20

Ciao a tutti! È molto bello vedere i lavori in corso. Vorrei condividere le mie esperienze con il protocollo DDP di VW/Skoda (cosiddetti "file rossi"). Forse alcune parti della comunicazione saranno simili a quelle di Audi.
Sto utilizzando un canale di comunicazione telematica. In questo caso, è necessario inviare dei cosiddetti "pacchetti di controllo" per segnalare che il dispositivo è attivo e funzionante.

Codice:

(000.000000)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.299862)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.301372)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.298739)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.300010)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.301492)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.298484)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.300022)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.301235)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.298764)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.300141)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.301100)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....' (000.299074)  can0  5A7   [8]  80 80 00 40 00 09 00 00   '...@....'

In questo caso, il periodo è di circa 300 ms. Se non inviamo questo messaggio, l'unità di controllo non ci permetterà di stabilire la sessione TP2.0 e non visualizzerà affatto i tuoi contenuti. Dobbiamo continuare a inviare questi messaggi in background. Il nostro modulo gateway reagirà e dovrebbe rilevare l'attività del modulo telematico. Questo potrebbe causare un errore nel GW, come "modulo di controllo codificato in modo errato". Possiamo quindi abilitare "Telematica" nella lista delle installazioni del modulo GW. A proposito, il bit più significativo (MSB) del byte B0 nel messaggio heartbeat è l'indicatore di errore. Se è 0x80, come nell'esempio precedente, il nostro GW ci darà un errore durante la scansione automatica, quindi è meglio utilizzare 0x00 invece.
Successivamente, dobbiamo configurare la sessione TP2.0:

Codice:

(000.000000)  can0  686   [6]  A0 0F 8A FF 4A FF         '....J.' (000.006734)  can0  687   [6]  A1 04 8A FF 32 FF         '....2.'

L'emulatore di telematica è all'indirizzo 0x686. L'unità di controllo risponde all'indirizzo 0x687. In questo caso, invieremo pacchetti TP2.0 con una dimensione del blocco di 0x0f (decimale 15). Ci sono alcuni valori temporali in questo frame; se desideri maggiori dettagli, consulta l'ottimo articolo su TP2.0 pubblicato precedentemente in questa discussione. 0x687 è una risposta dal gruppo strumenti. Descrive come il gruppo strumenti comunicherà con noi. In questo caso, la dimensione del blocco sarà di 4. Procediamo e invieremo un messaggio speciale. Non so esattamente cosa sia, ma sembra simile all'inizio di una sessione diagnostica TP2.0:

Codice:

(000.002244)  can0  686   [5]  10 00 55 00 FF            '..U..' (000.007213)  can0  687   [1]  B1                        '.'

Ma è al di fuori delle specifiche TP2.0, poiché la lunghezza del messaggio non è corretta. 0x55 è l'ID del modulo telematico. È lo stesso ID utilizzato nella modalità sessione diagnostica, quindi puoi facilmente verificarlo semplicemente intercettando la sessione VCDS con il modulo telematico. Il significato del byte 0xFF mi è sconosciuto. Ok, procediamo e poi otteniamo una risposta dal quadro strumenti:

Codice:

(000.011284)  can0  687   [8]  20 20 01 11 00 11 00 11   '  ......' (000.009427)  can0  687   [8]  21 00 11 00 0A 00 0D 00   '!.......' (000.009023)  can0  687   [3]  12 11 00                  '...' (000.000897)  can0  686   [1]  B3                        '.'

Non conosco il significato di quei byte, ma dovremmo reagire e inviare un altro "frame" speciale, come farebbero altri moduli correlati a DDP.

Codice:

(000.001267)  can0  686   [3]  11 01 12                  '...' (000.008116)  can0  687   [1]  B2                        '.'

Allora dovremmo ricevere un invito a creare una voce di menù.

Codice:

(000.010654)  can0  687   [8]  13 21 00 04 00 6E 00 5B   '.!...n.[' (000.000969)  can0  686   [1]  B4                        '.'

Osservate i valori: 0x6e, 0x5b. Probabilmente si tratta della risoluzione dello schermo.
Ok, possiamo inviare una voce di menù.

Codice:

(000.001283)  can0  686   [8]  22 02 70 55 12 54 65 73   '".pU.Tes' (000.003170)  can0  686   [7]  13 74 20 4D 65 6E 75      '.t Menu' (000.003469)  can0  687   [1]  B4                        '.'

Dai un'occhiata al valore B3: è di nuovo 0x55, quindi si tratta dell'ID del nostro modulo telematico. Ora dovremmo avere una nuova voce nel menu visualizzato. L'unità di controllo dovrebbe rispondere che il menu è attualmente in background.

Codice:

(000.020368)  can0  687   [5]  14 23 18 00 00            '.#...' (000.000915)  can0  686   [1]  B5                        '.'

0x23,0x18,0x00,0x00 ci indica che il nostro menu è attualmente visualizzato in background. 0x18 è un altro tipo di identificativo particolare. Per la telematica è 0x18, per il telefono è 0x08, per la radio è 0x00, per la navigazione è 0x10, per il riscaldamento ausiliario è 0x38, e 0x11 potrebbe essere la bussola?
Ora invieremo una richiesta di tipo "mostrami".

Codice:

(000.001187)  can0  686   [3]  15 0C 18                  '...' (000.007487)  can0  687   [1]  B6                        '.' (000.041926)  can0  687   [5]  16 23 18 01 00            '.#...' (000.001240)  can0  686   [1]  B7                        '.'

Come potete vedere, otterremo il permesso di visualizzare i nostri contenuti. La sequenza 0x23,0x18,0x01,0x00 è la richiesta inviata dal nostro modulo telematico per fornire i dati da visualizzare. Ora dovremmo cancellare lo schermo con:

Codice:

(000.003329)  can0  686   [8]  26 09 18 60 09 01 00 00   '&..`....' (000.001302)  can0  686   [8]  17 00 00 6E 00 5B 00 08   '...n.[..' (000.002091)  can0  687   [1]  B8                        '.' 09 = header. 18 = "other" id of our module 60 = clear screen id / create menu entry id 09 = length of elementary frame 01 = normal clear. Other possibilities: 0x02=invert, 0x03=add menu entry 00 = start point (horizontal) 00 = unknown 00 = start point (vertical) 00 = unknown 6E = a number of horizontal lines to clear 00 = unknown 5B = a number of vertical lines to clear 00 = unknown 08 = footer

Ora possiamo finalmente aggiungere del testo:

Codice:

(000.085506)  can0  686   [8]  2A 09 18 61 0F 00 00 00   '*..a....' (000.001864)  can0  686   [8]  2B 00 20 00 56 61 6C 75   '+. .Valu' (000.003969)  can0  686   [8]  2C 65 20 30 20 00 61 07   ',e 0 .a.' (000.001331)  can0  686   [8]  2D 0C 00 10 00 40 00 30   '-....@.0' (000.001326)  can0  686   [8]  2E 60 09 02 02 00 00 00   '.`......' (000.001289)  can0  686   [8]  2F 67 00 0B 00 60 09 00   '/g...`..' (000.001324)  can0  686   [8]  20 03 00 01 00 65 00 09   ' ....e..' (000.001994)  can0  686   [3]  11 00 08                  '...' (000.009957)  can0  687   [1]  B2                        '.' (000.030656)  can0  687   [4]  1A 27 18 01               '.'..' 09 = header 18 = "other" id of our module 61 = print function id 0F = length of elementary frame 00 = font type 00 = inversion 00 = print starting pos. (h) 00 = unknown 20 = print starting pos. (v) 00 = unknown 56 A 61 S 6C C 75 I 65 I 20 Characters 30 To 20 Display 00 = Faulty Ascii character (bad code) . ...another elementary frame 08 = footer

0x27, 0x18, 0x01 è un'acknowledgement (ACK) proveniente dall'IC. Conferma che il nostro messaggio è stato visualizzato correttamente.
Spero che ti piaccia. Michal.

Ciao Michal,
È bello rivederti qui di nuovo .

Grazie mille per aver condiviso le sue informazioni.
Per quanto ne so, i circuiti integrati più recenti (come il mio, con il numero di parte che termina con "932") non supportano il protocollo telematico.
Ma per i circuiti integrati più vecchi, queste informazioni sono molto utili .

Comunque, la seguente immagine mostra la risoluzione FIS. La linea a punti superiore indica la risoluzione normale (64x48 pixel), mentre la linea a punti inferiore indica la risoluzione alta (128x96 pixel). Io la chiamo Subpixel .

La foto seguente mostra la risoluzione FIS. La linea punteggiata superiore è a risoluzione normale (64x48 pixel), mentre la linea punteggiata inferiore è ad alta risoluzione (128x96 pixel). Io chiamo questo "subpixel" .

GerdJ, grazie .
I have an audi instrument cluster for tests, but it's probably too new and i cannot display a text on it according to your method. È:

Codice:

Control Module Part Number: 8U0 920 940 A   Component and/or Version: KOMBI_COLOUR  H15 0030 Advanced Identification/FAZIT      Serial number: 00000000000000      Identification: VD1-048      Date: 16.04.12      Manufacturer number: 7393      Test stand number: 7759 Software      Theft prot.: 03.02.03      BAP: 01.04.01      OSEK-OS: 03.00.00      Theft prot.: 00.00.00 Misc.      Hardware number: 8U0 920 940 A      Workshop System Name: J285

Non ricevo alcun messaggio all'indirizzo 0x6c1 quando invio dati a 0x6c0. Temo che si tratti di un sistema basato su BAP. Ho notato alcuni ID, come ad esempio 0x6e6, 0x6e7, 0x6e8 e 0x6e9, che sembrano appartenere al protocollo BAP. Comunque, proverò a vedere cosa succede.
Cordiali saluti, Michal.

Ciao,
Post molto interessante, grazie per l'ottimo lavoro, GerdJ.
Sono necessari fotogrammi CAN da 500 kbit che controllino il quadro strumenti dell'Audi A3 8P, e questi devono essere eseguiti al di fuori del veicolo.
Cordiali saluti.

Ecco il mio post dal forum dedicato alla Polo 9N; magari può essere utile a qualcuno.

@Utente originale: Come hai fatto a controllare i singoli pixel? Nella grafica del navigatore della Polo c'è un punto, ma in questo modo il carico sul bus sarebbe molto alto e la costruzione dell'immagine sarebbe molto lenta.

Ecco come appare l'immagine sul display LCD:

https://www.youtube.com/watch?v=eoAqhVP7CjE






Un analizzatore CAN e delle prove effettuate in auto sono essenziali per familiarizzare con la materia. Questo tutorial fornisce un aiuto per comprendere i messaggi presenti sul bus CAN relativi al protocollo di trasporto, al protocollo dei dati del display e all'anello di heartbeat OSEK.



Per poter inviare dati al display MFA, è necessario innanzitutto comprendere il protocollo di trasporto 1.6. Il protocollo dei dati del display viene infatti trasmesso tramite messaggi di dati utili. Originariamente, il TP 1.6 veniva utilizzato per trasmettere dati diagnostici tra il gateway e l'unità di controllo, poiché la linea K non era disponibile.

Cercherò di rendere il tutorial TP 1.6 il più generale possibile, ma lo illustrerò comunque con gli esempi pratici di "Tacho" e "Radio".



[size=150]Protocollo di Trasporto 1.6[/size]


Flusso di comunicazione fondamentale in TP 1.6:

1. Creazione di un canale di comunicazione e definizione degli identificativi di comunicazione.

2. Scambio di dati relativi al protocollo, ad esempio valori di temporizzazione (già a partire da questo punto, utilizzando gli ID di comunicazione concordati).

3. Trasmissione di dati utente.

4. Cambiata di direzione.

5. Ricezione dei dati utili.

6. Cambio di direzione o interruzione della comunicazione.

// In caso di terminazione, qui si conclude; in caso di cambio di direzione, invece, no!

7. Trasmissione di dati utente.

8. Cambiata di direzione.

9. ECC VIA...





[size=150]Costruzione del canale di comunicazione[/size]



Quando la radio si accende:


1. La radio chiede informazioni.

2. Tacho risponde.



Quando Tacho inizia:


1. Ciao, come stai?

2. La radio risponde.



Il messaggio per la richiesta e la risposta è composto da 3 byte di dati ed è costituito dall'ID CAN (AAA), dall'ID del dispositivo dell'unità di controllo con cui si deve comunicare (BB).
Codice operativo (CC), ID di comunicazione personalizzata desiderata in seguito (DD).



0xAAA 0xBB 0xCC 0xDD




Il primo passaggio è l'identificatore CAN (AAA).


Ogni partecipante ha un ID base e un ID del dispositivo.


L'ID base della radio è 0x4A0.

L'ID del dispositivo della radio è 0x36 oppure 0x39. Entrambe le opzioni sono possibili, ma per il momento continuerò a considerare 0x36.


L'ID base del tachigrafo è 0x2E0.

L'ID del dispositivo del tachigrafo è 0x08.



Per ottenere l'identificatore della richiesta, si sommano l'ID di base e l'ID del dispositivo.

Radio = 0x4D6

Tachimetro = 0x2E8




Il secondo passaggio è il codice operativo (CC).


Ci sono 3 possibilità:

0xC0 = Richiesta.

0xD0 = Risposta

0xD8 = Rifiuto della comunicazione.




Il terzo passaggio è l'ID di comunicazione (DD).


Si calcola sommando la base 0x600 + l'ID del dispositivo radio 0x36 + un offset specifico del dispositivo per il tachimetro 0x60, radio 0x80, a seconda di chi invia il messaggio.


In questa posizione viene utilizzato l'ID del dispositivo della radio, poiché più partecipanti potrebbero avere contemporaneamente un canale TP aperto verso il tachigrafo.

Da ne risultano gli identificativi di comunicazione:

Contachilometri: 0x696

Radio: 0x6B6


Poiché la base di 0x600 sembra essere ovvia, viene trasmesso solo il byte meno significativo, ovvero per la radio 0xB6 e per il tachimetro 0x96.




Ecco un esempio di un intero processo di comunicazione.


in cui la radio stabilisce la comunicazione:


0x4D6 0x08 0xC0 0xB6

0x2E8 0x36 0xD0 0x96



in cui il tachigrafo stabilisce la comunicazione.


0x2E8 0x36 0xC0 0x96

0x4D6 0x08 0xD0 0xB6





[size=150]Scambio di dati relativi a protocolli[/size]



Finora tutto bene. La comunicazione è stata stabilita e gli identificatori per le successive trasmissioni sono stati concordati ( 0xB6 e 0x96 ).

Ora vengono scambiati dati relativi al protocollo, come la dimensione del blocco (che verrà spiegata in seguito) e i valori di temporizzazione.



Se la radio ha avviato la comunicazione:


Il dispositivo radio trasmette dati relativi a protocolli specifici.

Il tachimetro risponde con dati relativi al protocollo.


Se è il tachigrafo ad aver avviato la comunicazione, allora l'intero processo avviene esattamente al contrario.



Il messaggio è composto da 6 byte di dati e include l'ID CAN (AAA), il codice operativo (BB), la dimensione del blocco (CC) e i valori di temporizzazione (T0 - T3).



0xAAA 0xBB 0xCC 0xT0 0xT1 0xT2 0xT3




Il primo passo è l'ID CAN (AAA).


Da questo punto, fino alla terminazione/conferma del canale TP, verranno utilizzati gli ID di comunicazione dei partecipanti trasmittenti.


Se il radio trasmette il messaggio: 0x6B6.

Il contachilometri: 0x696.




Il secondo passaggio è il codice operativo (BB).


Ecco due possibilità:

0xA0 = Richiesta

0xA1 = Risposta




Il terzo passaggio è la dimensione del blocco (CC).


Die Blockgröße gibt an, ab wieviel gesendeten Nutzdatennachrichten ein Acknowledge erwartet wird. DNe parleremo più tardi.

L'intervallo di valori è compreso tra 0x01 e 0x0F.




Il quarto passaggio riguarda i valori temporali (T0 - T3).

T0: Tempo massimo tra due messaggi (se superato, viene inviata una conferma).

T1: Tempo massimo tra due blocchi.

T2: Tempo minimo tra due messaggi.

T3: Tempo massimo per l'attesa di telegrammi destinati al destinatario.


Ogni byte di temporizzazione è composto da un predivisore a 2 bit e da un moltiplicatore a 6 bit.

( PRESC1 | PRESC0 | MUL5 | MUL4 | ... | MUL0 )

Valori del prescaler:

00 = 100 µS.

01 = 1 mS

10 = 10 milliSecondi (mS)

11 = 100 mS


Valori moltiplicativi:

0x00 - 0x3F


Il divisore di frequenza viene semplicemente moltiplicato per il fattore di moltiplicazione... come suggerisce già il nome.


Ecco un esempio del flusso di comunicazione.


se è la radio ad aver avviato la comunicazione:


0x6B6 0xA0 0x04 0x82 0x84 0x46 0xC5

0x696 0xA1 0x04 0x8A 0x85 0x43 0x94



se è stato il tachigrafo ad avviare la comunicazione:


0x696 0xA0 0x04 0x8A 0x85 0x43 0x94

0x6B6 0xA1 0x04 0x82 0x84 0x46 0xC5





[size=150]Invio di dati utente[/size]



Un messaggio di dati utili ha una dimensione compresa tra 1 e 8 byte ed è composto dall'ID CAN (AAA), dal byte di controllo (BB) e dai byte di dati utili (D0-D6).



0xAAA 0xBB 0xD0 0xD1 0xD2 0xD3 0xD4 0xD5 0xD6




Il primo passo è l'ID CAN (AAA).


Qui vengono utilizzati nuovamente gli ID di comunicazione (0x6B6 e 0x696).




Il secondo passaggio è il byte di controllo (BB).


Qui la situazione si complica, poiché questo byte contiene una parte significativa del protocollo TP 1.6.

I singoli bit del byte:



( NV | NV | /RICHIEDERE ACK | CAMBIO DI DIREZIONE | BIT CONTATORE 3 - 0 )



I bit 7 e 6 non sono utilizzati.

Il bit 5 è attivo a livello basso (0). Se questo bit è a livello basso ("LOW"), il ricevitore invia un'conferma.

Il bit 4 è attivo (a livello logico 1). Se questo bit è a livello "alto", viene forzata una variazione di direzione e il ricevitore inizia a trasmettere dati.

Il bit 3-0 del byte di controllo, denominato "Lownipple", viene incrementato con ogni messaggio inviato. In caso di overflow (superiore a 0xf), il valore riparte semplicemente da 0x0.
Dopo una svolta, si riparte anche qui con il valore 0x0.





Il messaggio di conferma occupa 1 byte ed è composto dall'ID CAN (AAA) e dal messaggio di conferma effettivo (BB).



0xAAA 0xBB




Il primo passo è l'ID CAN (AAA).


Qui vengono utilizzati nuovamente gli ID di comunicazione (0x6B6 e 0x696).




Il secondo passaggio è il messaggio di ACK (BB).


Il valore di Highnipple è sempre 0xB.

Il valore di "Lownipple" viene incrementato ad ogni messaggio di dati utili ricevuto.



Ora sono arrivato al punto giusto per affrontare l'argomento dei "blocchi". Un blocco è composto da un certo numero di messaggi di dati utili.
Come già descritto, questo numero viene definito durante lo scambio di dati relativi al protocollo. Nel caso dell'esempio che ho fornito in precedenza, un blocco contiene 4 messaggi di dati utili.

Significa che ogni quarta messaggio di dati utente imposta il bit 5 del byte di controllo su "LOW", e il destinatario invia un messaggio di conferma (ACK). Se un blocco non è completo (solo 1-3 messaggi di dati utente),...
In questo modo, il destinatario invia l'ultimo messaggio di conferma al momento del cambio di direzione.



Dopo aver invertito la direzione, il destinatario originale (che diventa trasmettitore) invia i suoi dati seguendo lo stesso schema.

Dopo aver cambiato direzione e il partecipante che ora sta trasmettendo non dispone di dati da inviare, quest'ultimo conferma la comunicazione.





Il messaggio di conferma ha una lunghezza di 1 byte ed è composto dall'ID CAN (AAA) e dal codice operativo (OP code) (BB).



0xAAA 0xBB




Il primo passo è l'ID CAN (AAA).


Qui vengono utilizzati nuovamente gli ID di comunicazione (0x6B6 e 0x696).



Il secondo passaggio è il codice operativo (BB).


0xA8 = Confermare.




Un esempio del flusso di comunicazione:



0x4D6 0x08 0xC0 0xB6 // Inizializzazione della comunicazione.
0x2E8 0x39 0xD0 0x96
0x6B6 0xA0 0x04 0x82 0x84 0x46 0xC5 // Scambio dei parametri relativi al protocollo.
0x699 0xA1 0x04 0x8A 0x85 0x43 0x94

0x6B6 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 // Invio di dati utili.
0x6B6 0x21 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x6B6 0x22 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x6B6 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 // Blocco di 4 elementi pieno, richiesta di conferma.

0x696 0xB4 // Conferma: Ricevute 4 messaggi di dati utente.

0x6B6 0x24 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x6B6 0x15 0x00 0x00 0x00 0x00 0x00 0x00 0x00 // Ultimo messaggio di dati utili, inversione di direzione!

0x696 0xB6 // Conferma: ricevute 6 messaggi di dati utili.

0x696 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x696 0x11 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x6B6 0xB2 // Conferma: Ricevute 2 messaggi di dati utente.
0x6B6 0xA8 // Conferma di comunicazione.





Con questo, il protocollo di trasporto versione 1.6 è stato spiegato.



[size=150]Il registro dei dati del display:[/size]


Poiché il tutorial DDP è piuttosto datato, negli esempi di comunicazione successivi si assume che l'ID del dispositivo radio sia 0x39, e non più 0x36 come nel tutorial TP 1.6.

Nelle spiegazioni, gli ID sono indicati con "X", ma questi valori sono variabili.

Un messaggio DDP viene suddiviso in più messaggi di dati utili TP 1.6, a seconda della sua lunghezza.

Il display è diviso in 3 segmenti: indicatore radio, display MFA/navigazione e indicatore di marcia. Questi possono essere utilizzati singolarmente o insieme, il che si traduce in un totale di 6 possibili segmenti.

Per visualizzare testo o simboli sul display, è necessario aprire un canale dati per ogni segmento del display utilizzato. Ogni canale dati ha un numero compreso tra 0x00 e 0xFF, che viene assegnato dal tachimetro al momento della registrazione del canale. Per ciascun dispositivo collegato, possono essere registrati al massimo 3 canali.

Dopo aver creato un canale dati per un segmento e configurato la sua creazione, questo canale dati può essere descritto, a condizione che il tachigrafo lo consenta. Un canale dati può anche essere riconfigurato o eliminato in una certa misura, successivamente.


[size=150]Codici operativi dei messaggi DDP[/size]

Il primo byte del tuo messaggio DDP contiene un opcode che determina quale funzione il messaggio deve svolgere.


Codici operativi per radio / Partecipanti al programma DDP

0x00 = Eliminazione di tutti i canali DDP del tuo partecipante DDP (ID dispositivo/apparecchiatura).

0x01 = Richiesta della dimensione del segmento di visualizzazione (codice operativo/numero del segmento [per la descrizione dei segmenti, vedere il codice operativo 0x02]).

0x02 = Registrazione del canale DDP (vedere la descrizione dettagliata di seguito).

0x05 = Disattivare canale DDP (OP/numero di canale).

0x06 = Modifica la modalità del menu del canale DDP (numero di operazione/numero di canale/modalità del menu [per la spiegazione della modalità del menu, vedere il codice operativo 0x02]).

0x09 = Invia dati per il canale DDP (vedere la descrizione dettagliata di seguito).

0x0A = Passa alla voce del menu corrispondente al canale (numero del canale/codice).

0x0B = Cambia segmento del display (numero operazione/numero canale/nuovo segmento).

0x0C = Dare la priorità al canale DDP (numero di operazione/canale).

0x0D = Elimina tutti i canali del partecipante al sistema DDP (OP/0x00/0x00).

0x15 = Inviare lo stato del partecipante DDP (ID operazione/ID dispositivo/0x20/0x01/Stato [0x00 = Disattivato, 0x01 = Attivato]).


Codici operativi del tachigrafo.

0x20 = Tutti i canali DDP del partecipante DDP sono stati eliminati.

0x21 = Invio delle dimensioni dei segmenti del display (Numero di segmento interno al OP/Tachimetro/0x00/Larghezza in pixel - byte alto/Larghezza in pixel - byte basso/Altezza in pixel - byte alto/Altezza in pixel - byte basso).

0x23 = Richiesta di invio dati per canale DDP, trasmissione dei parametri del canale (OP/numero canale/stato del canale [0x00 = bloccato, 0x01 = dati richiesti]).

0x25 = Conferma generale.

0x27 = Stato del canale DDP, trasmissione dei parametri del canale (OP/numero di canale/stato del canale).

0x2A = Canale DDP: per uscire dal menu, tornare al menu principale (numero OP/canale).

0x2B = Errore (numero operazione/canale/codice errore).

Codici di errore:
0x01: Codice operativo sconosciuto.
0x02: Messaggio incompleto.
0x03: Numero di canale sconosciuto.
0x04: Segmento sconosciuto.
0x05: Errore nei dati di visualizzazione.
0x06: ?
0x07: La coordinata X è troppo grande per il segmento.
0x08: La coordinata Y è troppo grande per il segmento.
0x09: Superato il numero massimo di canali (3).

0x35 = Partecipante al programma DDP disconnesso (OP).




[size=150]Registrazione di un canale dati[/size]

Un canale dati ha diversi parametri:

- Con/senza voce di menù e nome.
- Segmento del display.


Struttura del messaggio per la registrazione di un canale dati:

Titolo:

Byte 0: Codice operativo per creare un canale dati = 0x02.

Notizia:

Byte 0: Con voce di menu = 0x70, Senza voce di menu = 0x71-0x85 (Più basso è il valore, maggiore è la priorità).

Byte 1: ID del dispositivo = 0x3X.

Byte 2: Tutti i segmenti = 0x00, segmento centrale = 0x10, segmento superiore = 0x20, segmento inferiore = 0x30, segmento superiore + centrale = 0x40, segmento centrale + inferiore = 0x50.

Byte n: Etichetta della voce di menu ASCII (se il byte 0 = 0x70).


[size=150]Descrizione di un canale dati[/size]

Ogni messaggio di testo/grafica viene trasmesso insieme al numero del canale dati corrispondente.

Struttura dei messaggi per la trasmissione di notizie testuali/grafiche (inviate dai partecipanti a DDP).

Titolo:

Byte 0: Codice operativo per l'invio di dati al canale DDP = 0x09.

Byte 1: Numero del canale dati.

Notizia:

Byte 0: Dimensione del carattere: 0x57 (caratteri medi), 0x69 (caratteri grandi), 0x55 (caratteri piccoli).

Byte 1: 0x05 + lunghezza della stringa che segue il byte 6.

Byte a bit.

0: Attivare/disattivare i pixel attivi del personaggio sullo schermo.
text
1: Carattere normale = 1, Carattere invertito = 0
2: Carattere piccolo = 1, carattere normale = 0.
3: Elementi grafici = 1, Caratteri = 0.
4: Caratteri grandi = 1, caratteri normali = 0.
5: Orientamento verso destra = 1, orientamento verso sinistra = 0.
6: Sovrascrivere la riga del display = 1, cancellare completamente il display = 0.
7: Non utilizzato.

Byte 3: Posizione orizzontale in pixel (valore minimo).

Byte 4: Posizione orizzontale in pixel (valore alto).

Byte 5: Posizione verticale (Y) in pixel, valore minimo.

Byte 6: Posizione verticale (Y) in pixel, valore più significativo.

Byte n: Dati a freccia 0x00 - 0x74, dati di testo in formato ASCII.

Byte n: fine = 0x08.


Esempio:

Le notizie del DDP vengono semplicemente scritte sequenzialmente nei 7 byte dei dati utili delle notifiche del protocollo di trasporto.


Apertura di un canale dati.

0x4D9 0x08 0xC0 0xB9
0x2E8 0x39 0xD0 0x99
0x6B9 0xA0 0x04 0x82 0x84 0x46 0xC5
0x699 0xA1 0x04 0x8A 0x85 0x43 0x94

0x6B9 0x20 0x02 0x70 0x39 0x10 0x41 0x42 0x43 // Con voce di menu (0x70), Nome: ABCDE, Segmento: Centro (0x10)
0x6B9 0x11 0x44 0x45

0x699 0xB2
0x699 0x10 0x23 0x04 0x01 // Il tachimetro richiede dati dal canale, numero di canale = 0x04; il tachimetro desidera ricevere dati testuali/grafici per questo canale.

0x6B9 0xB1
0x6B9 0xA8

Descrizione del canale dati

0x4D9 0x08 0xC0 0xB9
0x2E8 0x39 0xD0 0x99
0x6B9 0xA0 0x04 0x82 0x84 0x46 0xC5
0x699 0xA1 0x04 0x8A 0x85 0x43 0x94

0x6B9 0x20 0x09 0x04 0x57 0x0a 0x02 0x02 0x00 // Numero del canale = 0x04, numero di caratteri da trasmettere = 5, carattere non invertito, posizione X = 0x02
0x6B9 0x21 0x03 0x00 0x48 0x41 0x4C 0x4C 0x4F // Posizione Y = 0x03, Testo = HALLO
0x6B9 0x12 0x08 // Fine

0x699 0xB3
0x699 0x10 0x27 0x04 0x01 // Trasmissione di stato, numero del canale dati = 0x04, il tachigrafo desidera continuare a ricevere dati per questo canale.

0x6B9 0xB1
0x6B9 0xA8

Eliminazione del canale dati

0x4D9 0x08 0xC0 0xB9
0x2E8 0x39 0xD0 0x99
0x6B9 0xA0 0x04 0x82 0x84 0x46 0xC5
0x699 0xA1 0x04 0x8A 0x85 0x43 0x94

0x6B9 0x10 0x05 0x04 // Disconnessione, numero del canale = 0x04

0x699 0xB1
0x699 0x10 0x25 0x04 // Disconnesso, numero di canale = 0x04

0x6B9 0xB1
0x6B9 0xA8



Osservazione generale:

Il quadro strumenti svolge molte funzioni. Di conseguenza, il display è la funzione meno importante di questa centralina (come si evince dagli identificativi elevati della comunicazione CAN).

Il tachimetro ha bisogno di tempo per elaborare i dati. Se vengono inviati pacchetti di dati troppo velocemente uno dopo l'altro, potrebbe semplicemente dimenticare di inviare una richiesta di dati o non visualizzare affatto i dati inviati. Quindi, è importante procedere con calma.

Lo schermo non è quindi adatto per frequenze di aggiornamento elevate.




[size=150]L'anello "Heartbeat":[/size]

Le centraline del sistema Comfort CAN inviano messaggi di "heartbeat" in una sequenza specifica. Ogni centralina fa riferimento alla successiva, mentre l'ultima fa riferimento alla prima. I dispositivi "Ringmaster" sono il gateway (ID dispositivo 0x00) e il tachimetro (ID dispositivo 0x08).

Immediatamente dopo l'attivazione, il gateway avvia la sequenza di inizializzazione del sistema. Dopo 30 millisecondi, questa sequenza viene completata dal tachimetro. Durante questi 30 millisecondi, ogni nodo rimanente invia un messaggio di inizializzazione.

Le centraline che si aggiungono successivamente al sistema inviano semplicemente il loro messaggio di inizializzazione e attendono che una centralina principale le indirizzi. La nuova centralina, inizialmente, fa riferimento al gateway, ovvero all'indirizzo 0x00. Se una centralina già registrata, che ora è stata superata, si rende conto della situazione, invierà un messaggio di reinizializzazione. La nuova centralina deve ascoltare questo messaggio e, durante il successivo ciclo di comunicazione, indirizzare la sua risposta a quella centralina.

Gli identificatori dei messaggi heartbeat sono composti dalla base 0x400 sommata all'ID del dispositivo.

Nel caso di un partecipante al programma DDP, quindi 0x43X.

Il messaggio è composto da 6 byte.

Il primo byte contiene, in caso di rilevamento di un errore o durante la fase di registrazione (cioè il primo messaggio "heartbeat" inviato da un dispositivo), l'ID di riferimento del dispositivo stesso. Per un dispositivo con ID 0x39, l'ID di riferimento è 0x19, mentre per un dispositivo con ID 0x36 è invece 0x16.

Byte 0: Riferimento all'ID del prossimo dispositivo di controllo (0x00 fino a 0x1f) / Durante la registrazione o in caso di errore, il proprio.

Byte 1: Stato interno: 0x01 = Modalità operativa normale; 0x02 = Errore rilevato; 0x11 = Pronto per la modalità standby; 0x31 = Se un'unità di controllo rileva che essa stessa e tutti gli altri dispositivi sono pronti per la modalità standby, questo valore disabilita l'anello. L'anello viene riattivato solo quando il dispositivo master 0x400 invia il suo messaggio di inizializzazione.

Byte 3: 0x00 = modalità normale; 0x80 = modalità di login.



L'intervallo di identificativi CAN (CAN ID) consentito per il sistema Polo è: 0x400 - 0x43F.

Ciao,

Ottima idea, tuttavia consiglio di caricare il video direttamente nella sezione del forum, perché spesso i video collegati esternamente smettono di funzionare dopo un po' di tempo.

Cordiali saluti, Rainer.