Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen

Hallo,
durch auswendiges Loggen und Auswerten habe ich die Ansteuerung des mittleren FIS Bereiches im A3 8P entschlüsselt und kann beliebige Texte, Navisymbole und Grafik im Display darstellen.
Erstaunlicherweise ist dies, meiner Kenntnis nach, nur sehr wenigen Leuten gelungen. Mehrere Produkte, die den FIS Bereich beschreiben, nutzen hierfür den Telematik Modus, der allerdings bei neueren Tachos nicht mehr vorhanden ist.

Hier muss man den Navigationsmodus nutzen, sprich man emuliert ein Navigationsradio RNS-E von Audi.

In diesem Post gehe ich nur auf die Grundlagen der Kommunikation ein. Detailliertes Vorgehen muss man sich selbst erarbeiten

KFZ: Audi A3 8P MJ 2011, mit Tacho (TN-Endung 932), weißes großes FIS
Radio: Audi RNS-E Modell 193 (das mit der Media Taste)

Grundlagen:
Um die oberen 2 Zeilen beschreiben zu können, muss sich das Radio im OSEK Ring anmelden. Das Radio sendet von nun an periodisch Texte (2x8 Zeichen) in den Canbus. Das FIS stellt diese dar. Er erfolgt keine Bestätigung vom FIS. Um eigene Texte zu schicken, muss ein CAN-Router (Gateway) zwischen Radio und CAN-Bus geschaltet werden, das die betroffenen ID's rausfiltert (0x363 + 0x365), alle anderen Frames müssen durchgereicht werden.

Ich habe dies mit einer kleinen Platine auf Basis eines STM32F4 MC gelöst.

Für den mittleren Bereich im FIS ist keine OSEK Anmeldung nötig. Man kann das FIS auch ohne Radio ansteuern, was sogar leichter ist, da man keine Frames rausfiltern muss. Ich nutze für meine Zwecke weiterhin mein Modul, und filtere die relevanten Nachrichten vom KFZ-> RNS-E und umgekehrt raus.

Für die Kommunikation sind 2 ID's zuständig, 0x6C0 und 0x6C1 (6C0 kommt vom RNS-E, 6C1 vom Tacho).

Um dem Protokoll auf die Schliche zu kommen, muss man 'nur' diese beiden ID's auf dem Info-Canbus loggen und lernen diese zu verstehen

Basics:
Zwischen Tacho und RNS-E wird nach Einschalten der Zündung ein Transport-Protokoll aufgebaut, ähnlich einer OBD Session. Die Verbindung kann durch beide Teilnehmer aufgebaut und auch wieder beendet werden.
Teilnehmer 1 sendet mehrmals eine Startsequenz um die Verbindung aufzubauen. Antwortet die Gegenstelle nicht innerhalb einer gewissen Zeit, wird der Verbindungversuch wieder unterbrochen und nicht weiter versucht.

Antwortet Teilnehmer 2 auf die Anfrage, werden weitere Frames an die Gegenstelle gesendet und entsprechend geantwortet. Auch gibt es 2 Arten von Nachrichten, einmal die von der Gegenstelle nicht bestätigt werden müssen, und welche die bestätigt werden müssen.

Um das Vorgehen zu beobachten loggt man die beiden ID's und schaltet die Zündung ein. Nach kurzer Zeit wird die Verbindung bestehen und durch 'Keep-Alive' Nachrichten aufrechterhalten. Danach schaltet man in den Navi Modus am RNS-E und aktiviert den Kompass im Setup. Jetzt sieht man was vom Radio zum Tacho gesendet wird um die Himmelsrichtung und den aktuellen Strassennamen im FIS darzustellen.

Nachrichten Arten:
0x52 ist der Kommandomodus
0x57 ist der Datenmodus
und noch weitere, z.B. für Grafikmodus um einzelne Pixel anzusteuern

Mit dem Kommandomodus wird z.B. der FIS Bereich definiert, in den man schreiben möchte (max. 64x48 Pixel), dabei kann dieser Bereich entweder nur definiert werden, gelöscht oder mit Weiß gefüllt werden.

Der Datenmodus schickt mehrere Datenblöcke in Folge an den Tacho, um z.B. längere Texte darstellen zu können.

Beginnt ein Frame mit Hex 1x muss von der Gegenstelle der Frame bestätigt werden. Beginnt ein Frame mit Hex 2x muss dieser nicht bestätigt werden.

Beim Auswerten von Logfiles erkennt man recht schnell wie bestätigt wird. Nur soviel, jeder Teilnehmer hat einen fortlaufenden Zähler der zu Frames mit Hex 1x oder 2x addiert wird, z.B. Hex 10, dann 11 u.s.w. bei Hex 1F erfolgt ein Überlauf und der Zähler beginnt wieder bei Hex 10.

Texte können mehrere Formatierungen aufweisen.
Breiter Font, schmaler Font, weiß auf schwarz, schwarz auf weiß, XOR zum Display, OR zum Display, links sowie zentriert ausgerichtet.
Weiters gibt es einen Zeichensatz, der grafische Charakter für Navigationssymbole ausgibt. Man muss allerdings z.B. einen Linksabbiegepfeil durch mehrere Navicharakter kombinieren, weil ein Charakter grade man 6x7 Pixel groß ist.

Das RNS-E nutzt übrigens nicht alle Möglichkeiten des FIS. So kann man auch im Grafikmodus einzelne Pixel direkt ansteuern, was das RNS-E nicht tut.

Da wir schon bei Pixel sind. Die Auflösung beträgt 64x48 Pixel. Ein Pixel besteht aus 4 Pixel, die ich Subpixel nenne.
Man hat also eigentlich doppelte Auslösung. Ich habe inzwischen einen Weg gefunden diese Subpixel ansteuern zu können.
Man darf allerdings vom FIS Display keine Tempowunder erwarten, da es eine untergeordnete Rolle im Tacho spielt (der Tacho tut mehr als einem bewusst ist!). Doom im FIS ist also nicht erstrebenswert

Nach jedem Frame an den Tacho muss eine kleine Pause eingefügt werden, da sonst Frames verschluckt werden und die Texte zerstückelt ankommen oder im schlimmsten Fall die Verbindung stecken bleibt. Keine Panik, kaputt machen kann man beim Info-Bus eigentlich nichts. Zündung aus-ein und läuft wieder.

So, das soll es fürs Erste gewesen sein.

Hallo 8pa

Find ich sogar als Nicht-Audi-Fahrer interessant wie das bei anderen Marken funktioniert . Bisher hab ich mich ja nur auf dem Astra G CID und dem (neueren) Vectra C CID austoben können und die ähneln sich untereinander ziemlich.

So sieht übrigens meine aktuelle selbstentwickelte, handgelötete CAN Developer Platine aus.

Herzstück ist ein STM32F4 mit 168MHz, zwei CAN Tranceiver, EEPROM, 2 Spannungsregler, und ein Reset Button
Die Platine kann auch mit einem STM32F1 bestückt werden.
Das Modul hat Anschlüsse für 2x CAN, Dauerplus, 5V und Masse nach Aussen geführt. Auf der Platine sind noch Stecker für SWD und UART vorhanden.

Selbstverständlich ist die Spannungsversorgung automotive gerecht konzipiert, das Modul wacht selbstständig bei CAN Aktivität auf und geht in Standby bei Nichtbenutzung, sprich es schläft selbstständig ein und verbraucht dann wenige uA.

Schau mal einer guck, nach Jahren mal wieder was interessantes hier. Danke dafür!

Die Platine schaut gut aus, wo lässt Du die fertigen, wenn ich fragen darf?

Hintergrund: ich setze derzeit PCAN-USB und mein Handy ein um am CAN zu lauschen, aber als Zusatz-Steuergerät verbauen mag ich das natürlich nicht und daher könnte es sein, dass ich in Zukunft auch eine (das ist leider als Anzahl zu verstehen) Platine brauchen könnte...

Gruß,
candev

Die Platine habe ich mit Eagle erstellt und bei PCB Joker fertigen lassen. Es gibt mit Sicherheit preiswertere Platinenhersteller, aber die Qualität ist 1A.

Bestückung habe ich selbst gemacht. Meine alten Augen brauchen zur Endkontrolle ein Mikroskop. Der STM32F4 hat 0.5mm Pitch

Danke für die Rückmeldung!

Gotta say this is really impressive!
The fact that you actually spent time in researching the FIS workflow and to really understand it and not to forget to mention your board, really attractive!

Thanks for sharing your findings !


About the PCB Joker, any ideas if they deliver outside Germany as well ?
Ive been looking for manufacturers for my own projects and so far only Seeed has stuck out from the crowd in my search.

Hi,
thank very much.

Yes, PCB Joker delivers to some other countries outside germany, take a look at this site -> http://www.pcb-joker.com/versandkosten.html

So,
hier eine kleine Anleitung wie man einen Text in den mittleren FIS Bereich schreibt. Es wird vorausgesetzt, dass die Verbindung zum Tacho bereits aufgebaut wurde! Wie das prinzipiell funktioniert habe ich eingangs erwähnt und soll sich jeder selbst herleiten. Dies hier ist keine schlüsselfertige Lösung!

Folgendes Beispiel gibt einen Text aus ('TEST').

Code:

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

Die Zeilen im Einzelnen:

Code:

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

Bedeutung der Bytes
0 .. Bestätigung erforderlich
1 .. Kommando Modus
2 .. Anzahl der Bytes
3 .. Definiert und löscht FIS Bereich
4 .. X-Koordinate FIS Bereich
5 .. Y-Koordinate FIS Bereich
6 .. Breite FIS Bereich
7 .. Höhe FIS Bereich

Code:

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

Code:

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

Bedeutung der Bytes
0 .. Keine Bestätigung erforderlich
1 .. Daten Modus Text
2 .. Anzahl der Datenbytes
3 .. Breiter Font Weiß auf Schwarz linksbündig
4 .. X-Koordinate des Textes
5 .. Y-Koordinate des Textes
6 .. ASCII für 'T'
7 .. ASCII für 'E'

Code:

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

Bedeutung der Bytes
0 .. Bestätigung erforderlich
1 .. ASCII für 'S'
2 .. ASCII für 'T'

Code:

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

Das Ergebnis sieht man im Anhang ...

Als Transportprotokoll wird übrigens TP2.0 verwendet.
http://jazdw.net/tp20

Hello community! It's very nice to see the work in progress. Let me share my experiences with VW/Skoda DDP protocol (so called "red fises"). Maybe some part of the communication will be similar to audi's one.
I'm using telematic communication channel. In that case it's necessary to send so called heartbeat frames to let know that unit is alive:

Code:

(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 this case period is about 300ms. If we won't send this, the instrument cluster will not let us estabilish the TP2.0 session and will not display your content at all. We need to keep sending this messages in the background. Our gateway module will react and should detect activity of the telematic module. This can lead to error in GW like "control module incorrectly coded", so we can enable "Telematics" in the installation list of the GW module. By the way - MSB of the B0 in the heartbeat message is the error indicator. If it's 0x80 like in the example above, our GW will give us an error while autoscanning, so we better use 0x00 instead.
Next we need to setup TP2.0 session:

Code:

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

Telematics emulator is at 0x686. IC answers at 0x687. In this case we will send TP2.0 packages with blocksize of 0x0f (dec 15). There are some timing values in this frame, if you want details then just look at great tp2.0 article posted before in this topic. 0x687 is an answer from the instrument cluster. It describes how IC will be speaking to us. In this case blocksize will be 4. We go forward and we will send a magic message. I don't exactly know what it is, but it looks similar to TP2.0 diag session begining:

Code:

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

But it's out of tp2.0 specs, since message length is incorrect. 0x55 is the Telematics module ID. It's the same ID as in diagnostic session mode, so you can easily see this just by sniffing VCDS session with Telematics module.The meaning of 0xFF byte is not known to me. Ok, we go further and then we get an answer from instrument cluster:

Code:

(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                        '.'

I don't know the meaning of those bytes, but we should react and send another magic frame as any other DDP related module does:

Code:

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

Then we should get an invitation to create a menu entry:

Code:

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

Take a look at the valuses: 0x6e,0x5b. This is probably the screen resolution.
Ok, we are clear to send a menu entry:

Code:

(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                        '.'

Take a look at B3 - it's 0x55 again, so it is our Telematic module ID. Now we should have a new menu entry on our display. IC should answer that our menu is in background at the moment:

Code:

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

0x23,0x18,0x00,0x00 tells us that our menu is at the background now. 0x18 is another freaky kind of ID. For telematics it's 0x18, phone=0x08, radio=0x00, navi=0x10, aux. heating=0x38, 0x11=compass?
Now we will send "show me" request:

Code:

(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                        '.'

As you can see we will get a permission to display our content. 0x23,0x18,0x01,0x00 is the request for giving the content to the display from our telematic module. Now we shoud clear the screen with:

Code:

(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

Now we can finally add some text:

Code:

(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 is ACK from IC. It confirms that our message was displayed correctly.
I hope you like it. Michal.

Hi Michal,
great to see you here again

Thank you so much for sharing your information.
As far as I know, the newer ICs (like mine with partnumber 932 at the end) don't support Telematik protocol.
But for older ICs this information is very helpful

BTW, the following picture shows the FIS resolution. Upper dot line normal resolution (64x48 pixel), lower dot line high resolution (128x96 pixel). I call it Subpixel

Auf deutsch: das nachfolgende Foto zeigt die FIS Auflösung. Die obere gepunktete Linie in normaler Auflösung (64x48 Pixel), die untere gepunktete Linie in hoher Auflösung (128x96 Pixel). Diese nenne ich Subpixel

GerdJ, thank you
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. It is:

Code:

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

It doesn't put any messages at 0x6c1 when i'm sending at 0x6c0. I'm afraid it's BAP based. I've noticed some ids like eg. 0x6e6, 0x6e7, 0x6e8, 0x6e9 that looks like BAP-proto. Anyways i will be trying.
Regards, Michal.

Hello,
Very interesting post, thanks for the great work GerdJ.
Needs CAN 500kBit frame which runs the instrument cluster Audi A3 8P outside the vehicle.
Best regards

Ich kopiere einfach mal meinen Beitrag aus dem Polo 9N . Info Forum hier rein, vieleicht hilft es jemandem.

@OP: wie hast Du die einzelnen Pixel ansteuern können? Beim Polo gibt es im Navi-Zeichensatz zwar einen Punkt, doch dann wäre beim Beschreiben des Displays die BUS Last sehr hoch und der Bildaufbau sehr langsam

So sieht das nacher auf dem LCD aus:

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






Ein CAN Logger und Versuche im Auto sind unerlässlich, um sich in die Materie einarbeiten zu können. Dieses Tutorial ist eine Hilfestellung, um die auf dem CAN vorhandenen Telegramme bezüglich des Transportprotokolls, des Displaydatenprotokolls und des OSEK Heartbeat Rings zu verstehen.



Um an das MFA Display Daten senden zu können, muss man in erster Linie das Transport Protokoll 1.6 verstehen. Das Display Datenprotokoll wird nämlich mit Hilfe von Nutzdatennachrichten übertragen. Ursprünglich wird das TP 1.6 zum Übertragen von Diagnosedaten zwischen Gateway und Steuergerät genutzt, da die K-Line entfiel.

Ich versuche das TP 1.6 Tutorial so allgemein wie möglich zu halten, werde es aber dennoch mit den Teilnehmern Tacho und Radio erklären.



[size=150]Transport Protokoll 1.6[/size]


Grundlegender Ablauf der Kommunikation bei TP 1.6:

1. Aufbau eines Kommunikationskanals mit dem Aushandeln der Kommunikations IDs

2. Austauschen von protokollbedingten Daten z.B. Timingwerte (Schon ab hier mit den ausgehandelten Kommunikations IDs)

3. Senden von Nutzdaten

4. Richtungswechsel

5. Empfangen von Nutzdaten

6. Richtungswechsel oder Beendigung der Kommunikation

// Im Falle der Beendigung ist hier schluss, bei Richtungswechsel allerdings nicht!

7. Senden von Nutzdaten

8. Richtungswechsel

9. USW....





[size=150]Aufbau des Kommunikationskanals[/size]



Wenn das Radio beginnt:


1. Radio frägt an

2. Tacho antwortet



Wenn Tacho beginnt:


1. Tacho frägt an

2. Radio antwortet



Die Nachricht für Anfrage und Antwort ist 3 Datenbytes groß und besteht aus CAN ID (AAA), Geräte ID des Steuergerätes mit dem kommuniziert werden soll (BB),
OP Code (CC), Die später gewünschte eigene Kommunikations ID (DD)



0xAAA 0xBB 0xCC 0xDD




Der 1. Schritt ist CAN Identifier (AAA).


Jeder Teilnehmer hat eine Basis ID und eine Geräte ID.


Die Basis ID des Radios ist 0x4A0

Die Geräte ID des Radios ist 0x36 oder 0x39. Beides ist später möglich, ich gehe nun weiterhin von 0x36 aus.


Die Basis ID des Tachos ist 0x2E0

Die Geräte ID des Tachos ist 0x08.



Um den Identifier für die Anfrage zu erhalten, addiert man Basis ID und Geräte ID:

Radio = 0x4D6

Tacho = 0x2E8




Der 2. Schritt ist der OP Code (CC)


Es gibt 3 Möglichkeiten:

0xC0 = Anfrage

0xD0 = Antwort

0xD8 = Ablehnen der Kommunikation




Der 3. Schritt ist die Kommunikations ID (DD)


Sie errechnet sich aus der Basis 0x600 + Geräte ID Radio 0x36 + eines Gerätespezifischen Offsets Tacho 0x60, Radio 0x80, jeh nach dem wer die Nachricht sendet.


Man verrechnet an dieser Stelle die Geräte ID des Radios, da mehrere Teilnehmer gleichzeitig einen TP Kanal zum Tacho geöffnet haben können.

Daraus resultieren die Kommunikation IDs:

Tacho: 0x696

Radio: 0x6B6


Da die Basis von 0x600 anscheinend offensichtlich ist, wird jeweils nur das niederwertige Byte übertragen, d.h. für das Radio 0xB6 und für den Tacho 0x96.




Nun ein Beispiel zu einem kompletten Kommunikationsablauf


bei dem das Radio die Kommunikation aufbaut:


0x4D6 0x08 0xC0 0xB6

0x2E8 0x36 0xD0 0x96



bei dem der Tacho die Kommunikation aufbaut:


0x2E8 0x36 0xC0 0x96

0x4D6 0x08 0xD0 0xB6





[size=150]Austauschen von protokollbedingten Daten[/size]



Soweit so gut, Die Kommunikation ist aufgebaut, die Identifier für weitere Übertragungen ausgehandelt ( 0xB6 und 0x96 )

Nun werden protokollbedingte Daten ausgetauscht, wie Blockgröße ( Wird später erläutert ) und Timingwerte.



Wenn das Radio die Kommunikation initiierte:


1. Radio sendet protokollbedingte Daten

2. Tacho antwortet mit protokollbedingten Daten


Wenn der Tacho die Kommunikation initiiert hat, ist das Ganze genau andersrum.



Die Nachricht dafür ist 6 Datenbytes groß und besteht aus CAN ID (AAA), OP Code (BB), Blockgröße (CC) und den Timingwerten (T0 - T3)



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




Der 1. Schritt ist die CAN ID (AAA)


Ab hier werden bis zur Beendigung/Quittierung des TP Kanals die Kommunikations IDs der sendenden Teilnehmer verwendet.


Wenn das Radio die Nachricht sendet: 0x6B6

Der Tacho: 0x696




Der 2. Schritt ist der OP Code (BB)


Hier gibt es 2 Möglichkeiten:

0xA0 = Anfrage

0xA1 = Antwort




Der 3. Schritt ist die Blockgröße (CC)


Die Blockgröße gibt an, ab wieviel gesendeten Nutzdatennachrichten ein Acknowledge erwartet wird. Dazu später mehr.

Der Wertebereich liegt zwischen 0x01 und 0x0F




Der 4. Schritt sind Timingwerte (T0 - T3)

T0: Maximale Zeit zwischen zwei Nachrichten (Bei überschreiten erfolgt Quittierung)

T1: Maximale Zeit zwischen zwei Blöcken

T2: Minimalste Zeit zwischen zwei Nachrichten

T3: Maximale Zeit in der als Empfänger Telegramme erwartet werden


Jedes Timingbyte besteht aus einem 2 Bit Prescaler und einem 6 Bit Multiplikator.

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

Prescalerwerte:

00 = 100 µS

01 = 1 mS

10 = 10 mS

11 = 100 mS


Multiplikatorwerte:

0x00 - 0x3F


Der Prescaler wird einfach mit dem Multiplikator multipliziert... wie der Name schon sagt


Nun ein Beispiel für den Kommunikationsablauf


wenn das Radio die Kommunikation initiierte:


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

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



wenn der Tacho die Kommunikation initiierte:


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

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





[size=150]Senden von Nutzdaten[/size]



Eine Nutzdatennachricht ist 1 - 8 Datenbytes groß und besteht aus der CAN ID (AAA), dem Kontrollbyte (BB) und den Nutzdatenbytes (D0 - D6)



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




Der 1. Schritt ist die CAN ID (AAA)


Hier werden wieder die Kommunikations IDs verwendet (0x6B6 und 0x696).




Der 2. Schritt ist das Kontrollbyte (BB)


Hier wird es komplizierter, da dieses Byte einen großen Teil des TP 1.6 beinhaltet.

Die einelnen Bits des Bytes:



( NV | NV | /ACK ANFORDERN | RICHTUNGSWECHSEL | ZÄHLERBITS 3 - 0 )



Bit 7 und 6 sind nicht verwendet.

Bit 5 ist 0-Aktiv. Ist dieses "LOW" schickt der Empfänger ein Acknowledgement.

Bit 4 ist 1-Aktiv. Ist dieses "HIGH" so wird ein Richtungswechsel erzwungen und der Empfänger fängt an Daten zu senden.

Das Lownipple (Bit 3 - 0) des Kontrollbytes wird mit jeder verschickten Nachricht inkementiert. Bei einem Überlauf (> 0xf) geht es einfach wieder bei 0x0 weiter.
Nach einem Richtungswechsel geht es ebenfalls wieder mit 0x0 weiter.





Die Acknowledgement Botschaft ist 1 Byte lang und besteht aus CAN ID (AAA) und der eigentlichen ACK Botschaft (BB).



0xAAA 0xBB




Der 1. Schritt ist die CAN ID (AAA)


Hier werden wieder die Kommunikations IDs verwendet (0x6B6 und 0x696).




Der 2. Schritt ist die ACK Botschaft (BB)


Das Highnipple ist immer 0xB

Das Lownipple inkrementiert mit jeder bereits erhaltenen Nutzdatennachricht.



Nun habe ich die richtige Stelle erreicht um das Thema mit den "Blöcken" anzuschneiden. Ein Block besteht aus einer gewissen Anzahl von Nutzdatennachrichten.
Diese Anzahl wird wie schon beschrieben, beim Austausch von protokollbedingten Daten festgelegt. In Falle meines Beispiels oben ist ein Block 4 Nutzdatennachrichten groß.

Das heißt: Bei jeder 4. Nutzdatennachricht wird Bit 5 des Kontrollbytes "LOW" und der Empfänger schickt eine ACK Nachricht. Wird ein Block nicht voll ( Nur 1 - 3 Nutzdatennachrichten ),
so sendet der Empfänger das letzte Acknowledgement beim Richtungswechsel.



Nach dem Richtungswechsel sendet der ursprüngliche Empfänger (wird zum Sender) seine Daten nach dem gleichen Schema.

Nachdem ein Richtungswechsel stattgefunden hat und der nun sendende Teilnehmer keine Daten zum Senden hat, Quittiert der Teilnehmer die Kommunikation.





Die Quittierungsbotschaft ist 1 Byte lang und besteht aus CAN ID (AAA) und dem OP Code (BB).



0xAAA 0xBB




Der 1. Schritt ist die CAN ID (AAA)


Hier werden wieder die Kommunikations IDs verwendet (0x6B6 und 0x696).



Der 2. Schritt ist der OP Code (BB)


0xA8 = Quittieren




Ein Beispiel zum Kommunikationsablauf:



0x4D6 0x08 0xC0 0xB6 // Initiieren der Kommunikation
0x2E8 0x39 0xD0 0x96
0x6B6 0xA0 0x04 0x82 0x84 0x46 0xC5 // Austauschen der protokollbezogenen Parameter
0x699 0xA1 0x04 0x8A 0x85 0x43 0x94

0x6B6 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00 // Senden von Nutzdaten
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 // 4er Block voll, Acknowledgement angefordert

0x696 0xB4 // Acknowledgement: 4 Nutzdatennachrichten erhalten

0x6B6 0x24 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x6B6 0x15 0x00 0x00 0x00 0x00 0x00 0x00 0x00 // Letzte Nutzdatennachricht, Richtungswechsel!

0x696 0xB6 // Acknowledgement: 6 Nutzdatennachrichten erhalten

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

0x6B6 0xB2 // Acknowledgement: 2 Nutzdatennachrichten erhalten
0x6B6 0xA8 // Kommunikation quittieren





Hiermit wäre das Transport Protokoll 1.6 erklärt.



[size=150]Das Display Datenprotokoll:[/size]


Da das DDP Tutorial schon älter ist, wird in den späteren Kommunikationsbeispielen von der Radio Geräte ID 0x39 ausgegangen, nicht mehr von 0x36 wie im TP 1.6 Tutorial.

In den Erklärungen sind die IDs mit "X" allerdings variabel gehalten.

Eine DDP Nachricht wird je nach Länge auf mehrere TP 1.6 Nutzdatennachrichten aufgeteilt.

Das Display ist in 3 Segmente unterteilt. Radioanzeige, MFA/Navianzeige und Ganganzeige. Diese können einzeln oder Barrierefrei genutzt werden, daraus ergeben sich insgesamt 6 mögliche Segmente.

Um nun Text oder Symbole auf dem Display anzuzeigen, muss für jedes verwendete Displaysegment ein Datenkanal geöffnet werden. Jeder Datenkanal hat eine Nummer von 0x00 - 0xFF, diese wird bei der Anmeldung eines Kanals vom Tacho vergeben. Pro Teilnehmer können maximal 3 Kanäle angemeldet werden.

Nachdem für ein Segment ein Datenkanal erstellt und mit der Erstellung konfiguriert wurde, kann dieser Datenkanal beschrieben werden, solange der Tacho diesen freigibt. Ein Datenkanal kann auch in einem gewissen Rahmen nachträglich umkonfiguriert, oder auch gelöscht werden.


[size=150]OP Codes der DDP Nachrichten[/size]

Das erste Byte deiner DDP Nachricht beinhaltet einen OPcode, der bestimmt, welche Funktion die Nachricht erfüllen soll:


Opcodes Radio / DDP Teilnehmer

0x00 = Löschen aller DDP Kanäle deines DDP Teilnehmers (OP/Geräte ID)

0x01 = Displaysegment-Größe anfordern (OP/Segmentnummer [Erklärung Segmente siehe OP Code 0x02])

0x02 = DDP Kanal anmelden (genaue Beschreibung siehe unten)

0x05 = DDP Kanal abmelden (OP/Kanalnummer)

0x06 = DDP Kanal Menümodus ändern (OP/Kanalnummer/Menümodus [Erklärung Menümodus siehe OP Code 0x02])

0x09 = Daten für DDP Kanal senden (genaue Beschreibung siehe unten)

0x0A = Zum Menüeintrag des Kanals springen (OP/Kanalnummer)

0x0B = Displaysegment wechseln (OP/Kanalnummer/Neues Segment)

0x0C = DDP Kanal priorisieren (OP/Kanalnummer)

0x0D = Alle Kanäle des DDP Teilnehmers löschen (OP/0x00/0x00)

0x15 = DDP Teilnehmer Status senden (OP/Geräte ID/0x20/0x01/Status [0x00 = Aus, 0x01 = Ein])


Opcodes Tacho

0x20 = Alle DDP Kanäle des DDP Teilnehmers gelöscht.

0x21 = Senden von Display-Segmentgrößen (OP/Tachointerne Segmentnummer/0x00/Breite in Pixel High/Breite in Pixel Low/Höhe in Pixel High/Höhe in Pixel Low)

0x23 = Aufforderung zum Senden von Daten für DDP Kanal, Übertragen von Kanal Parametern (OP/Kanalnummer/Kanalstatus [0x00 = gesperrt, 0x01 = Daten erwünscht)

0x25 = Allgemeine Bestätigung

0x27 = Status von DDP Kanal, Übertragen von Kanal Parametern (OP/Kanalnummer/Kanalstatus)

0x2A = DDP Kanal mit Menüeintrag durch Sprung ins Hauptmenü verlassen (OP/Kanalnummer)

0x2B = Fehler (OP/Kanalnummer/Fehlercode)

Fehlercodes:
0x01: Unbekannter Opcode
0x02: Nachricht unvollständig
0x03: Unbekannte Kanalnummer
0x04: Unbekanntes Segment
0x05: Fehler in Displaydaten
0x06: ?
0x07: x Koordinate zu groß fuer Segment
0x08: Y Koordinate zu groß fuer Segment
0x09: Maximum an Kanälen (3) überschritten

0x35 = DDP Teilnehmer abgemeldet (OP)




[size=150]Anmelden eines Datenkanals[/size]

Ein Datenkanal hat verschiedene Parameter:

- Mit / ohne Menüeintrag und Name
- Displaysegment


Nachrichtenaufbau zur Anmeldung eines Datenkanals:

Header:

Byte 0: OP Code Datenkanal erstellen = 0x02

Nachricht:

Byte 0: Mit Menüeintrag = 0x70, Ohne Menüeintrag = 0x71 - 0x85 (Je niedriger desto höher die Priorität)

Byte 1: Geräte ID = 0x3X

Byte 2: Alle Segmente = 0x00, Mittleres Segment = 0x10, Oberes Segment = 0x20, Unteres Segment = 0x30, Oberes + Mittleres Segment = 0x40, Mittleres + Unteres Segment = 0x50

Byte n: Beschriftung Menüeintrag ASCII (wenn Byte 0 = 0x70)


[size=150]Beschreiben eines Datenkanals[/size]

Bei jeder Text-/ Grafiknachricht wird die entsprechende Datenkanalnummer mit übertragen.

Nachrichtenaufbau zur Übertragung von Text- / Grafiknachrichten (gesendet von DDP Teilnehmer):

Header:

Byte 0: OP Code Daten für DDP Kanal senden = 0x09

Byte 1: Datenkanalummer

Nachricht:

Byte 0: Charactergröße: 0x57 (Mittlere Character), 0x69 (große Character), 0x55 (kleine Character)

Byte 1: 0x05 + Länge der nach Byte 6 folgenden Zeichenkette

Byte 2 Bit

0: Aktive Pixel des Characters auf Display toggeln
1: Normale Schrift = 1, Invertierte Schrift = 0
2: Schmale Schrift = 1, Normale Schrift = 0
3: Grafikbausteine = 1, Schriftzeichen = 0
4: Große Schriftzeichen = 1, Normale Schriftzeichen = 0
5: Mittenorientiert = 1, Linksorientiert = 0
6: Displayzeile überschreiben = 1, Display komplett löschen = 0
7: Nicht verwendet

Byte 3: X Position in Pixel Low

Byte 4: X Position in Pixel High

Byte 5: Y Position in Pixel Low

Byte 6: Y Position in Pixel High

Byte n: Pfeildaten 0x00 - 0x74, Textdaten ASCII

Byte n: Abschluss = 0x08


Beispiel:

Die Nachrichten des DDPs werden einfach nacheinander in die 7 Bytes der Nutzdatennachrichten des Transport Protokolls geschrieben.


Eröffnen eines Datenkanals

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 // Mit Menüeintrag (0x70) Name: ABCDE, Segment: Mitte (0x10)
0x6B9 0x11 0x44 0x45

0x699 0xB2
0x699 0x10 0x23 0x04 0x01 // Tacho fragt Kanal an, Kanalnummer = 0x04, Tacho möchte Text/Grafikdaten für diesen Kanal.

0x6B9 0xB1
0x6B9 0xA8

Beschreiben des Datenkanals

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 // Kanalnummer = 0x04, Anzahl der zu übertragenden Zeichen = 5, nichtinvertierte Schrift, X Position = 0x02
0x6B9 0x21 0x03 0x00 0x48 0x41 0x4c 0x4c 0x4f // Y Position = 0x03, Text = HALLO
0x6B9 0x12 0x08 // Abschluss

0x699 0xB3
0x699 0x10 0x27 0x04 0x01 // Statusübermittlung, Datenkanalnummer = 0x04, Tacho möchte weiterhin Daten für diesen Kanal.

0x6B9 0xB1
0x6B9 0xA8

Löschen des Datenkanals

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 // Abmelden, Kanalnummer = 0x04

0x699 0xB1
0x699 0x10 0x25 0x04 // Abgemeldet, Kanalnummer = 0x04

0x6B9 0xB1
0x6B9 0xA8



Allgemeine Anmerkung:

Der Tacho hat ein haufen Zeug zu tun. Das Display ist daher die unwichtigste Funktion dieses Steuergeräts (siehe die hohen Identifier der CAN Kommunikation)

Der Tacho benötigt Zeit um Daten zu verarbeiten. Sendet man Datenpakete zu schnell hintereinander, vergisst er einfach mal eine Datenanfrage zu senden oder zeigt die gesendeten Daten einfach nicht an. Also immer mit der Ruhe.

Das Display ist daher nicht für hohe Aktualisierungsraten geeignet.




[size=150]Der Heartbeat-Ring:[/size]

Die Steuergeräte am Komfort CAN Senden Heartbeatmessages nach einer gewissen Reihenfolge. Ein Steuergerät verweist immer auf das Nächste, das Letzte immer auf das Erste. Ringmaster sind Gateway (Geräte ID 0x00) und Tacho (Geräte ID 0x08).

Unmittelbar nach "Zündung ein" startet das Gateway die Ringinitialisierung. 30ms später beendet der Tacho diese. Innerhalb dieser 30ms sendet jeder verbleibende Ringteilnehmer eine Initialisierungsbotschaft.

Steuergeräte, die sich später in den Ring einbuchen, senden einfach ihre Initialisierungsbotschaft und warten bis ein vorauslaufendes Steuergerät auf sie verweist. Das neue STGR verweist erst einmal auf das Gateway, also 0x00. Falls ein bereits angemeldetes Steuergerät darüber liegt, welches nun übergangen wurde, wird es sich mit einer Neuinitialisierung melden. Auf diese muss das neue Steuergerät hören und beim nächsten Ringdurchlauf dann darauf verweisen.

Die Identifier der Heartbeatmessages bestehen aus der Basis 0x400 addiert mit der Geräte ID.

Im Falle eines DDP Teilnehmers also 0x43X

Die Message besteht aus 6 Bytes.

Das erste Byte enthält bei erkanntem Fehler oder der Anmeldung (also die erste Heartbeatmessage die ein Steuergerät verschickt) die eigene Verweis ID. Bei Geräte ID 0x39 ist die Verweis ID 0x19, bei Geräte ID 0x36 allerdings 0x16.

Byte 0: Verweis ID des nächsten Steuergeräts (0x00 bis 0x1f) / Bei Anmeldung oder Fehler die eigene.

Byte 1: Eigener Status: 0x01 = Normaler Betriebsmodus; 0x02 = Fehler erkannt; 0x11 = Bereit für Standby; 0x31 = Wenn ein Steuergerät erkennt dass es selbst und alle anderen bereit für den Standby sind, legt dieser Wert den Ring für den Standby lahm. Der Ring wird erst wieder aufgeweckt wenn der Ringmaster 0x400 seine Initialisierungsbotschaft schickt.

Byte 3: 0x00 = Normalmodus; 0x80 = Anmeldung



Der beim Polo zugelassene CAN ID Bereich liegt bei: 0x400 - 0x43F

Hi,

super Sache, ich empfehle jedoch das Video im Thema hoch zu laden, da erfahrungsgemäss extern verlinkte Videos nach einiger Zeit nicht mehr gehen.

Viele Grüsse, Rainer

Hi, i'm working on an audi S3 8L (with a red 64*88 FIS) , and develop in VisualBasic an interface to control the FIS. All your inforùmations are perfect, and if i can ask you a little bit more details about the graphical part of the mid-fis. By exemple, how do you write a pixel as the line in your exemple ? To write text, no problem, 57 - nb_byte - options_byte - x_byte - y_byte - data_0_byte - data_1_byte and so on ...
But for the graphic ? 57 - nb_byte - ??? - ??? Please if you can help me ...

GerdJ hat folgendes geschrieben:

Hi Michal, great to see you here again Thank you so much for sharing your information. As far as I know, the newer ICs (like mine with partnumber 932 at the end) don't support Telematik protocol. But for older ICs this information is very helpful BTW, the following picture shows the FIS resolution. Upper dot line normal resolution (64x48 pixel), lower dot line high resolution (128x96 pixel). I call it Subpixel Auf deutsch: das nachfolgende Foto zeigt die FIS Auflösung. Die obere gepunktete Linie in normaler Auflösung (64x48 Pixel), die untere gepunktete Linie in hoher Auflösung (128x96 Pixel). Diese nenne ich Subpixel