[Alter Thread] Beschreiben der MFA+ Oel-Temp + Ladedruck

[Nico84]

Ne, lpcexpresso. Ist eigentlich Eclipse.

[-creez-]

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.



Transport Protokoll 1.6


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





Aufbau des Kommunikationskanals



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





Austauschen von protokollbedingten Daten



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





Senden von Nutzdaten



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.



Das Display Datenprotokoll:


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.


OP Codes der DDP Nachrichten

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)




Anmelden eines Datenkanals

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)


Beschreiben eines Datenkanals

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+1: 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.




Der Heartbeat-Ring:

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

[Nico84]

Super Tutorial

Wer noch mehr über TP1.6 und 2.0 erfahren möchte dem empfehle ich:
Bussysteme in der Fahrzeugtechnik: Protokolle, Standards und Softwarearchitektur


ISBN-10: 3834809071
ISBN-13: 978-3834809070

[-creez-]

isda des obd zeug auch erklärt?

Gesendet von meinem XT1052 mit Tapatalk



Edit: frage hat sich beantwortet )

[SHT]

Ab wann kann man das bei dir käuflich erwerben?

[-creez-]

Wenn Du so n Ding willst kannst mirs jetzt schon mitteilen, ich muss die Platine und die Bauteile dafür bestellen.

[-creez-]

Das Modul ist fertig


Weitere Infos im Original Post

[RollinCrew]

Ich will auch so'n Teil!

[Nuerne89]

Sehr geil!

Wenn du das auch für das Seat Ibiza KI mit der kleinen MFA zum laufen bekommst, ist das sofort gekauft, gerne auch 10 Sätze! Ich hab keine Lust auf Zusatzinstrumente, so wäre das perfekt!

Bild vom Ibiza KI: http://www.ibiza6l.de/wordpress/wp-cont ... HL-003.jpg

Links kann man alle Werte durchschalten.

Man hat zwar nur vier Ziffern, Doppelpunkt, Komma, °C, etc zur Verfügung, aber das reicht.

Bspw...

OL:93 °C für Öltemperatur 93°C
H2:89 °C für Wassertemperatur 89°C
LL:42 °C für Ladelufttemperatur 42°C
A930 °C für Abgastemperatur 923°C
P1:85 für Ladedruck 1,85bar absolut
L0:83 für Lambda 0,83 (Benziner)
E56,6 für Einspritzmenge 56,6mg/str. (Diesel)

[-creez-]

Wie du richtig erkannt hast hat die kleine MFA Anzeigesegmente und keine Pixel . Die kleine MFA wird bei MM Tachos direkt vom Microcontroller angesteuert, bei VDO über nen Phillips LCD Treiber.

Da es bei der kleinen MFA nicht möglich ist eine Kommunikation aufzubauen, und wenn dies ginge auch das DDP anders wäre, muss zwischen Display und Tachoplatine ne kleine Leiterplatte eingefügt werden, die entweder die Signale des Tachos weitergibt, oder eigene Werte anzeigen lässt.

Es ist möglich aber sehr schwierig. Werde mich der Sache mal annehmen.


Wäre cool dafür nen VDO Tacho mit Login zu bekommen, welcher beim Motor BMS läuft.

Aber hey, diese Sache ist ein heftigerer Brocken als das FIS zu beschreiben

Gesendet von meinem XT1052 mit Tapatalk

[Nuerne89]

Ah ok, verstehe. Hm, wäre es dann nicht einfacher nur ein kleines LCD in die leere Mitte vom Ibiza KI zu stopfen und das autark nebenher laufen zu lassen? Die Fläche reicht ja aus, um alle gewünschten Werte anzuzeigen. Falls man doch was durchschalten wöllte, ginge das sicher auch über einen kleinen Taster.

Dennoch top, dass du dich auch mal mit dem Ibiza beschäftigen würdest
Das ist wirklich noch ne große Marktlücke

[-creez-]

wäre ne bessere Lösung, mit nem 8x2 Alphanummerischen display


is die einfachste Variante

mach ich gerne

Gesendet von meinem XT1052 mit Tapatalk

[Andis 9N]

Sehr geil!

Wo genau, kann man das Modul verstauen, ohne das es umherfliegt?
Kann man auch einstellen was man wo angezeigt haben möchte?

Wie schaut es mit Updates aus?

LG, Andi

[-creez-]

Das verstaust irgendwo unterm armaturenbrett. vorzugsweise hinterm radio oder hinterm tacho. Updates wirds geben, brauchst halt n programmieradapter für 11 euro aus ebay

Gesendet von meinem XT1052 mit Tapatalk

[Andis 9N]

Ist hinterm Tacho noch Platz?
Bzw, wo würdest du es verstauen?
Bei meinem Radio ist alles voll, die Kabel liegen sogar hinter der Climatronic

Braucht man dann nur die Code File bzw. die einzelnen Files zu tauschen?
Oder wie wird das funktionieren?

Kann man sich die Anzeigen so legen wie man möchte?
Oder sind die fix vorprogrammiert?

[-creez-]

Hinterm Armaturenbrett is überall noch Platz (direkt unterm Tacho am Relaisträger oder BNSTG)

Ich will des später über VCDS codieren können.

Ja is so: ich hab mit der Programmierung angefangen als ich von TP 1.6 noch nicht so viel verstanden hab. Aus dem Grund ist die Software in dieser Sache recht unflexibel. Läuft Stabil, dennoch kann man was Diagnose angeht keine Kopfsprünge machen.

Es gibt natürlich mehrere Möglichkeiten das zu konfigurieren: Ein File ins EEPROM flashen, per Dipschalter vorprogrammierte Layouts wählen oder mehrere Firmware Versionen zur Verfügung stellen. Ich denke die EEPROM Variante ist ist die Beste, ich bevorzuge allerdings die VCDS Variante.

Momentan muss ichs fest einprogrammieren

Gesendet von meinem XT1052 mit Tapatalk

[Andis 9N]

Okay, also das heißt das wenn man ein Modul jetzt im frühen Zustand kauft, ist es auf jeden Fall immer mit wenigen IT-Kenntnissen updatefähig, falls es was neues gibt?
Werden die Updates dann zur Verfügung gestellt?

Gibt es noch andere Abfragen oder nur die, die man auf den Fotos sieht?
Ist es möglich anstatt des Ladedrucks, auch den Saugrohrdruck für Sauger anzeigen zu lassen?

[-creez-]

Was bisher alles möglich ist (bereits realisiert und geplant) steht im Originalpost.

Du kannst dir allerdings andere Werte anzeigen, wenn du zusätzliche Sensoren verbaust. Das ist aber ein ziemlich großer Aufwand, da man die Software darauf anpassen muss


Wenn der Wert für Saugrohrdruck an der gleichen Stelle zu finden ist und exakt so umgerechnet wird (was ich allerdings ned glaub)

da bräuchte ich nen Sauger an dem ich die Werte neu ermitteln kann

Da das Modul immer das gleiche bleibt und sich nur die Software ändert kann man es updaten, da ich neue Versionen auf einer Cloud zur Verfügung stell.

Updaten kann man durch nen Programmieradapter den man für 11€ bei eBay bekommt, und dem Programm AVR Dude.

Gesendet von meinem XT1052 mit Tapatalk

[cycleracer88]

Wenn ich das richtig verstanden habe, sind mit der EDC17 so gut wie alle Werte anzeigbar? ...also auch Abgastemperatur, Ansaugtemperatur und Differenzdruck vom DPF?

Noch ein Grund mehr die EDC17 mit dem ASZ zu verheiraten

[-creez-]

Ich hab doch garnix von diff.druck, und abgastemperatur geschrieben

Es ist alles anzeigbar was durch die zyklischen CAN Botschaften vom Motorsteuergerät übertragen wird Ansaugtemperatur geht glaub ich.

Gesendet von meinem XT1562 mit Tapatalk