RKS+CAN Adapter für CAN-Bus Sniffing
CAN-Interface
Info und Bestellung
CANhack.de - CAN Hardware, CAN Software, CAN Protokolle - Das CAN-Bus Forum.

Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen


FehlerdatenbankSuchen  LesezeichenLesezeichen  Garage - FahrzeugeFahrzeuge  InfoFAQ und Impressum
RSS-NewsfeedRSS-Newsfeed  RegistrierenRegistrieren  LoginLogin
 
Neues Thema beginnen   Auf Beitrag antworten      Weitergeben, Thema teilen   Lesezeichen setzen   Druckansicht    CANhack.de - Übersicht » Fahrzeugspezifische Hardware und Pinbelegungen Vorheriges Thema anzeigen :: Nächstes Thema anzeigen
Autor Nachricht
GerdJ
CAN-Profi
CAN-Profi


CAN Hacker seit: 08.09.2014
Beiträge: 41
Karma: +10 / -0   Danke, gefällt mir!


Premium Support

CAN-Diagnose gefällt das.
Beitrag28-07-2016, 13:02    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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 icon_smile.gif

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 icon_smile.gif

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 icon_smile.gif

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.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
shavenne
CAN-Profi
CAN-Profi


CAN Hacker seit: 27.04.2015
Beiträge: 32
Karma: +5 / -0   Danke, gefällt mir!
Wohnort: Paderborn

CAN Support

Beitrag28-07-2016, 20:27    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

Hallo 8pa icon_razz.gif

Find ich sogar als Nicht-Audi-Fahrer interessant wie das bei anderen Marken funktioniert icon_smile_thumb_up.gif. 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.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
GerdJ
CAN-Profi
CAN-Profi


CAN Hacker seit: 08.09.2014
Beiträge: 41
Karma: +10 / -0   Danke, gefällt mir!


Premium Support

CAN-Diagnose gefällt das.
Beitrag28-07-2016, 21:25    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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 icon_smile.gif
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.



image.jpeg
 Beschreibung:
 Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen
 Dateigröße:  105,4 KB
 Angeschaut:  4423 mal

image.jpeg



Zuletzt bearbeitet am 28-07-2016, 21:36, insgesamt 4-mal bearbeitet.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
candev
Gast




 


Kostenloser Account, kein CAN Entwicklungs-Support

Beitrag28-07-2016, 22:46    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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
Nach oben
 
GerdJ
CAN-Profi
CAN-Profi


CAN Hacker seit: 08.09.2014
Beiträge: 41
Karma: +10 / -0   Danke, gefällt mir!


Premium Support

Beitrag29-07-2016, 5:50    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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 icon_smile.gif
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
candev
Gast




 


Kostenloser Account, kein CAN Entwicklungs-Support

Beitrag30-07-2016, 17:21    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

Danke für die Rückmeldung!
Nach oben
 
Deko



CAN Hacker seit: 11.05.2016
Beiträge: 7
Karma: +2 / -0   Danke, gefällt mir!


Kostenloser Account, kein CAN Entwicklungs-Support

Beitrag01-08-2016, 5:27    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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! icon_smile_thumb_up.gif

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.
Project: Audi R4
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
GerdJ
CAN-Profi
CAN-Profi


CAN Hacker seit: 08.09.2014
Beiträge: 41
Karma: +10 / -0   Danke, gefällt mir!


Premium Support

Beitrag01-08-2016, 5:36    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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


Zuletzt bearbeitet am 01-08-2016, 5:51, insgesamt 1-mal bearbeitet.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
GerdJ
CAN-Profi
CAN-Profi


CAN Hacker seit: 08.09.2014
Beiträge: 41
Karma: +10 / -0   Danke, gefällt mir!


Premium Support

modernsoft gefällt das.
Beitrag01-08-2016, 9:35    Titel: Beispielcode für Textausgabe Antworten mit Zitat

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



FIS_Test.jpg
 Beschreibung:
 Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen
 Dateigröße:  119,17 KB
 Angeschaut:  2020 mal

FIS_Test.jpg



Zuletzt bearbeitet am 01-08-2016, 11:14, insgesamt 7-mal bearbeitet.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
Surfjenser



CAN Hacker seit: 04.01.2012
Beiträge: 38
Karma: +0 / -0   Danke, gefällt mir!
Wohnort: Hannover

Kostenloser Account, kein CAN Entwicklungs-Support

Beitrag01-08-2016, 23:04    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

Als Transportprotokoll wird übrigens TP2.0 verwendet.
http://jazdw.net/tp20
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
majonez
CAN-Profi
CAN-Profi


CAN Hacker seit: 31.07.2013
Beiträge: 35
Karma: +9 / -0   Danke, gefällt mir!
Wohnort: Wrocław

CAN Support

GerdJ gefällt das.
Beitrag02-08-2016, 11:47    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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.



20160802_123920.jpg
 Beschreibung:
 Red FIS display
 Dateigröße:  105,69 KB
 Angeschaut:  1953 mal

20160802_123920.jpg



Zuletzt bearbeitet am 02-08-2016, 12:10, insgesamt 5-mal bearbeitet.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
GerdJ
CAN-Profi
CAN-Profi


CAN Hacker seit: 08.09.2014
Beiträge: 41
Karma: +10 / -0   Danke, gefällt mir!


Premium Support

Beitrag02-08-2016, 12:05    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

Hi Michal,
great to see you here again icon_smile.gif

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 icon_smile_thumb_up.gif

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 icon_smile.gif

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 icon_smile.gif



FIS_Dot_Test.PNG
 Beschreibung:
 Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen
 Dateigröße:  594,91 KB
 Angeschaut:  1608 mal

FIS_Dot_Test.PNG



Zuletzt bearbeitet am 02-08-2016, 13:06, insgesamt 2-mal bearbeitet.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
majonez
CAN-Profi
CAN-Profi


CAN Hacker seit: 31.07.2013
Beiträge: 35
Karma: +9 / -0   Danke, gefällt mir!
Wohnort: Wrocław

CAN Support

Beitrag02-08-2016, 13:04    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

GerdJ, thank you icon_smile.gif
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.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
modernsoft



CAN Hacker seit: 13.08.2016
Beiträge: 1
Karma: +0 / -0   Danke, gefällt mir!
Wohnort: Warszawa

Kostenloser Account, kein CAN Entwicklungs-Support

Beitrag29-01-2017, 13:51    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden Gehe in Dein Profil um mehr über die Verlinkung Deiner Webseite zu erfahren.  
-creez-



CAN Hacker seit: 25.12.2013
Beiträge: 1
Karma: +0 / -0   Danke, gefällt mir!
Wohnort: Westerstetten
2007 Volkswagen Polo
Kostenloser Account, kein CAN Entwicklungs-Support

Beitrag20-02-2017, 14:44    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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 nicon_smile_thumb_up.gif: 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


Zuletzt bearbeitet am 20-02-2017, 14:49, insgesamt 2-mal bearbeitet.
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden   Fahrzeuge des Benutzers ansehen  
CAN-Diagnose
Administrator
Administrator
Avatar-CAN-Diagnose

CAN Hacker seit: 07.06.2011
Beiträge: 352
Karma: +14 / -0   Danke, gefällt mir!
Wohnort: Ländle



Beitrag20-02-2017, 19:03    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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
Dipl.-Ing. (FH) Rainer Kaufmann - Kaufmann Automotive GmbH
CAN-Bus Interface kaufen: CAN auf USB, CANhack.de CAN-Interface
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden Website dieses Benutzers besuchen  
shorty54



CAN Hacker seit: 22.11.2012
Beiträge: 3
Karma: +0 / -0   Danke, gefällt mir!
Wohnort: France Est

Kostenloser Account, kein CAN Entwicklungs-Support

Beitrag16-03-2017, 10:06    Titel: Audi A3 8P mittleren FIS Bereich beschreiben, Grundlagen Antworten mit Zitat

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 icon_smile.gif

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 icon_smile_thumb_up.gif

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 icon_smile.gif

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 icon_smile.gif
Nach oben
CAN Hacker - Profil anzeigen Private Nachricht senden    
Neues Thema beginnen   Auf Beitrag antworten      Weitergeben, Thema teilen   Lesezeichen setzen   Druckansicht    CANhack.de - Übersicht » Fahrzeugspezifische Hardware und Pinbelegungen Seite 1 von 1
Ähnliche Fachartikel und Themen
Thema Community Bereich
Keine neuen Beiträge Highline MFA beschreiben Innenraum- / Komfort CAN
Keine neuen Beiträge OPEL Display (TID/MID/GID) beschreiben? Fahrzeugspezifische Hardware und Pinbelegungen
Keine neuen Beiträge Hier: Audi CAN-Bus Identifier (allgemein) direkt von Audi. Allgemein
Keine neuen Beiträge CAN Daten Audi A2 und Audi A3 - Wer kann helfen ? Innenraum- / Komfort CAN
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst Deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst Deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten.
Du kannst Dateien in diesem Forum herunterladen.