[RoPe65]

KI hat schon auch seine Vorteile, aber man muss sich halt im Klaren darüber sein, dass die auch nur wiederkäut, was die Mehrheit im Netz glaubt richtig zu sein. Auch mit KI hat selber denken und kritisch hinterfragen nach wie vor seine Vorzüge.

[Rufus]

Super das es geklappt hat.
Ich hätte mich auch freundlicher ausdrücken können. Leider legen im Moment zu viele Leute vertrauen in die ki-antworten, die insbesondere bei solchen spezifischen Dingen völlig versagen.

Viel Spaß mit dem korrekt laufenden Tacho und dem 5 Zylinder.

[JanGolf3]

Zitat von Rufus

Super das es geklappt hat.
Ich hätte mich auch freundlicher ausdrücken können. Leider legen im Moment zu viele Leute vertrauen in die ki-antworten, die insbesondere bei solchen spezifischen Dingen völlig versagen.

Viel Spaß mit dem korrekt laufenden Tacho und dem 5 Zylinder.

Alles gut . Deine Reaktion war völlig normal. Ihr habt euch dadurch hintergangen gefühlt . Hab als erstes eure Theorie probiert das klappte nu wollte ich aber wissen was bei der ki Antwort passiert und hab das auch probiert. Tja nichts is da passiert aber die ki hat mich den den bau des motor kabelbaums begleitet und der wagen sprang direkt ohne fehler an (bis auf sekundär pumpe Und bremsenelektronik) is ja klar das msg erwartet Daten über can vom Mark 60 abs was nicht mehr vorhanden ist .

Nu werd ich am ende noch sehen ob man die kmh noch etwas mit der k Zahl korrigieren kann . Fahr zwar schon 2 Jahre auf den 17er aber hab da nie wirklich drauf geachtet obs passt

[JanGolf3]

Zitat von RoPe65

KI hat schon auch seine Vorteile, aber man muss sich halt im Klaren darüber sein, dass die auch nur wiederkäut, was die Mehrheit im Netz glaubt richtig zu sein. Auch mit KI hat selber denken und kritisch hinterfragen nach wie vor seine Vorzüge.

Ja beim motorkabelbaum war sie echt hilfreich da passte auch alles was sie mir so erzählt hat . Aber aus Erfahrungen lernt man . Und ich bin euch überaus dankbar für eure Hilfe

[JanGolf3]

Hab grad gesehen das meine Uhr jetzt aber auf 12h is keine 24h wie bekomm ich das auf 24h zurück

[Rufus]

Zitat von JanGolf3

Hab grad gesehen das meine Uhr jetzt aber auf 12h is keine 24h wie bekomm ich das auf 24h zurück

Bei 0x01 sollte "48" stehen.
Vermutlich hast du dort im Moment "40" stehen, obwohl dein ursprünglich ausgelesener EEPROM Dump dort die "48" hatte.

Die Logik dahinter ist wie folgt:
Binäre Codierung:
01000000 - EU
00100000 - Break Test "ja"
00010000 - unbekannt
00001000 - 24h
00000100 - unbekannt
00000010 - °F
00000001 - unbekannt (hat was mit dem Verbrauch der MFA zu tun)

Für deinen brauchst du 24h, Break Test "nein", °C.
Also: 01001000

Umgerechnet von Binär auf Hexadezimal = "48"

[RoPe65]

Zitat von JanGolf3

Nu werd ich am ende noch sehen ob man die kmh noch etwas mit der k Zahl korrigieren kann . Fahr zwar schon 2 Jahre auf den 17er aber hab da nie wirklich drauf geachtet obs passt

Die Speicheradresse für die k-Zahl (oder Wegstreckenzahl) im EEPROM ist die 0x04 und 05, bei Dir steht da „83“ & „5E“.. Die erste Stelle ist irrelevant, der Rest „35E“ ist dezimal 862. Bei VDO musst Du 3000 dazuzählen, dann hast Du die Wegstreckenkennzahl.
Weißt Du, wie die Wegstreckenzahl für Deine Reifendimensionen berechnet wird?

[JanGolf3]

Zitat von Rufus

Bei 0x01 sollte "48" stehen.
Vermutlich hast du dort im Moment "40" stehen, obwohl dein ursprünglich ausgelesener EEPROM Dump dort die "48" hatte.

Die Logik dahinter ist wie folgt:
Binäre Codierung:
01000000 - EU
00100000 - Break Test "ja"
00010000 - unbekannt
00001000 - 24h
00000100 - unbekannt
00000010 - °F
00000001 - unbekannt (hat was mit dem Verbrauch der MFA zu tun)

Für deinen brauchst du 24h, Break Test "nein", °C.
Also: 01001000

Umgerechnet von Binär auf Hexadezimal = "48"

Stimm beim ersten Mal lesen stand da tatsächlich die 48 und beim zweiten mal lesen auf einmal die 00 als ich die daten geändert hatte. Werd das mal korrigieren

Erste mal lesen 0048
Dann hatte ich ich die 1048 ein getragen
Auf 0048 geändert weil ih ja wissen wollte was mir die ki da fürn misst erzählte

Dann wieder gelesen stand da 0000 unddie 0x17 dann wieder auf serie zurück

Aber nur die 0x00 geändert und nicht auf 0x01 geachtet daher vermutlich die falsche Uhr

Danke werd das mal berichtigen

Hab auch mfa wenn ds wichtig ist

[JanGolf3]

Zitat von RoPe65

Die Speicheradresse für die k-Zahl (oder Wegstreckenzahl) im EEPROM ist die 0x04 und 05, bei Dir steht da „83“ & „5E“.. Die erste Stelle ist irrelevant, der Rest „35E“ ist dezimal 862. Bei VDO musst Du 3000 dazuzählen, dann hast Du die Wegstreckenkennzahl.
Weißt Du, wie die Wegstreckenzahl für Deine Reifendimensionen berechnet wird?

Tatsächlich hab ich da keinen blassen schimmer .
Also hab ich aktuell 3862 als wegstreckenzahl . Wen ich deinen Text jetzt folgen konnte ?

Ich müsste tatsächlich mal gucken welche Reifen größe ich habe. Weiß ich aus dem Kopf gerade nicht . Glaube aber 195/40R17 zu haben. (Grad nach gesehen sind tatsächlich 195/40R17)

Grüße

[RoPe65]

Zitat von JanGolf3

Tatsächlich hab ich da keinen blassen schimmer .
Also hab ich aktuell 3862 als wegstreckenzahl . Wen ich deinen Text jetzt folgen konnte ?

Ich müsste tatsächlich mal gucken welche Reifen größe ich habe. Weiß ich aus dem Kopf gerade nicht . Glaube aber 195/40R17 zu haben. (Grad nach gesehen sind tatsächlich 195/40R17)

Grüße

Ja, aktuell hast Du 3862. Bei 195/40 R17 wäre die rechnerische Wegstreckenzahl 3791 minus 3000 = 791, das ist in Hex 317. Die Adressen 0x04 und 05 wären dann „83“ & „17“.
Wenn es Dich interessiert, wie die Zahl zustande kommt: der Geschwindigkeitsgeber liefert pro Radumdrehung 7 Impulse, der Abrollumfang Deiner Räder beträgt 1,8466m.
1000/1,8466x7= 3791 Impulse pro km.
Die aktuell programmierte Wegstreckenzahl kannst Du im versteckten Menü abrufen, das wurde weiter oben schon beschrieben, wie das geht.

[JanGolf3]

Zitat von RoPe65

Ja, aktuell hast Du 3862. Bei 195/40 R17 wäre die rechnerische Wegstreckenzahl 3791 minus 3000 = 791, das ist in Hex 317. Die Adressen 0x04 und 05 wären dann „83“ & „17“.
Wenn es Dich interessiert, wie die Zahl zustande kommt: der Geschwindigkeitsgeber liefert pro Radumdrehung 7 Impulse, der Abrollumfang Deiner Räder beträgt 1,8466m.
1000/1,8466x7= 3791 Impulse pro km.
Die aktuell programmierte Wegstreckenzahl kannst Du im versteckten Menü abrufen, das wurde weiter oben schon beschrieben, wie das geht.

Danke für deine ausführliche Auflistung werd das mal mit GPS ab gleichen wenn der fahren darf und dann ggf nach bessern. Vielen Dank wegen dem Menü scrollnich noch mal im Beitrag nach. Danke auf alle fälle

[kay_algeciras]

Super interessant was hier alles schon rausgefunden wurde! Ich habe einen Caddy 9KV und der hat auch den Golf3 Tacho. Ich habe hier einen von VDO und das Eeprom ist in der DIP8 Bauform. Ich moechte das Eeprom NICHT ausloeten. Ich kenne meine Staerken und Schwaechen und das Ausloeten geht im Zweifellsfall nicht gut aus.

Ich suche jetzt verzweifelt eine Klammer, finde aber immer nur Klammern fuer die SOP8 Form. Es gibt bei Ebay was aus China aber von da was zu bestellen ist fuer mich in Spanien nicht sinnvoll, da fallen ueber 30 Euro Gebuehren fuer ein paar Cent Abgaben an. Programmer mit besagter SOP8 Klammer ist vorhanden...... Kennt jemand da was?

[RoPe65]

Eine DIP8-Klammer zu finden ist tatsächlich nicht so einfach. Alternativ kannst Du beim VDO-Tacho aber relativ problemlos Litzen an die EEPROM-Kontakte anlöten, da der Chip frei zugänglich auf der Rückseite sitzt.
Da ich relativ viel an Platinen herumlöte, habe ich mir eine beheizte Entlötpumpe für 15EUR zugelegt, das funktioniert super und empfehle ich jedem weiter, der ab und zu was auslöten muss.
Wenn ich an einem Golf3-VDO-Tacho was machen muss, löte ich den EEPROM immer aus und setze einen Sockel ein.

[VladLup]

Hallo zusammen,

ich wollte dieses Topic hier ein bisschen zum Leben erwecken.

Ich habe früher schon einige Mercedes-KIs von VDO reverse-engineered. Ich habe auch noch ein altes Vento, das in meiner Heimat auf mich wartet. Vor Kurzem habe ich entschieden, dass die Karre unbedingt ein KI-Upgrade braucht , und habe ein VDO-KI vom Golf 4 Cabrio gekauft.
Dann wollte ich herausfinden, wie dort alles gespeichert ist, wie man die K-Zahl anpasst usw.

Erstmal vielen Dank an alle Beteiligten, die hier schon vieles herausgefunden haben. Ich habe hier aber ein paar Sachen gesehen, die mich ein bisschen gestört haben. Zum Beispiel hat GTFahrer herausgefunden, wie man das Plateau entfernt, aber die Reihenfolge der Bytes sah merkwürdig aus. Ich will versuchen zu erklären, warum das so ist, und dann noch ein paar Sachen mitzuteilen, die, glaube ich, noch nicht bekannt waren, z. B. wie man das geheime Menü um weitere Werte erweitern kann.

Zuerst: Die Entscheidung, alle Bytes im Dump zu swappen, war nicht so gut. Nicht böse gemeint — sorry, Deutsch ist nicht meine Muttersprache. Am Anfang denkt man, dass es besser wird, wenn man alle Bytes swappt, weil man Werte wie K-Zahl, Kilometerstand usw. dann besser sieht. Das gilt aber nur für 2-Byte-Werte. Dabei macht man die 1-Byte-Werte, insbesondere Arrays, kaputt. Der Grund dafür ist, dass die CPU eine Little-Endian-Architektur hat. Deswegen werde ich hier die originalen Dumps ohne Swapping zeigen, und man sieht, dass viele Sachen sofort klarer werden.

Hier ist ein Screenshot von der App ImHex. Damit kann man die Werte in der Binärdatei sehr einfach mit einem Pattern hervorheben.



Wir achten jetzt auf die Arrays 0x2C–0x30, 0x31–0x35 und 0x36–0x3A.

50 76 97 B9 F0
82 6B 5A 4B 32
E3 95 95 95 30

Man kann schon sehen, dass ohne Swapping die Werte im ersten Array kontinuierlich steigen und im zweiten und dritten Array sinken.
Wenn man sich das zweite Array noch genauer anschaut, sieht man dort folgende Dezimalwerte: 130, 107, 90, 75, 50. Das sind doch die Temperaturwerte! Ich weiß nicht, wofür sie hier benötigt werden, weil keine Temperatur auf dem LCD angezeigt wird, aber egal — sehr wahrscheinlich werden sie für uns noch unbekannte Zwecke benutzt.

Array 3 zeigt genau das, was GTFahrer und andere schon vermutet haben: Schrittmotorwerte für die jeweilige Temperatur aus Array 2. Man kann jetzt aber sehr gut diese Plateau-„Funktion“ erkennen: 95 95 95. Der Maximalwert 0xE3 passt auch logisch gut: Für 130 Grad braucht der Zeiger mehr Ausschlag als für 50 Grad.

Was noch bleibt, ist Array 1. Das sind die ADC-Werte für den Temperatursensor. Die MCU kann den Widerstand nicht direkt messen, aber sie kann mithilfe des ADC die Spannung messen. Ich habe dann die Platine getraced und folgendes Schema herausgefunden:



Der Sensorwiderstand bildet dann zusammen mit den zwei anderen Widerständen auf der Platine die vom ADC gemessene Spannung.

Ich habe kein Datenblatt für den Mikrocontroller gefunden, aber ich ging davon aus, dass dort ein 8-Bit-ADC eingebaut ist, weil der Controller schon ziemlich alt ist.

Der maximale Wert des ADC wäre also 255 bzw. 0xFF. 0 würde 0 V bedeuten und 0xFF 5 V … dachte ich mir am Anfang

Laut verfügbarer Info hat der Sensor bei 130 Grad ca. 50 Ohm und bei 90 Grad ca. 120 Ohm. Das kann von Sensor zu Sensor variieren, weil sie nicht exakt gleich sind.

Also haben wir drei Widerstände: 50, 174 und 523 Ohm sowie 5 V. Das ergibt 1,04 V.

Der ADC-Wert müsste dann 1,04 / 5 * 255 = 53 sein, was in Hex 0x35 ist — nicht 0x50. Wenn man aber statt 5 V 3,3 V nimmt, dann ergibt 1,04 / 3,3 * 255 = 80, also 0x50. Dann passt alles. Ich habe es zuerst über einen anderen Weg herausgefunden, den ich hier überspringe. Wenn man später also 3,1 V in Kommentaren sieht — nicht wundern. Ich habe dann auch die Spannungen an allen MCU-Pins gemessen und 3,0 V bzw. 3,3 V gesehen.

Übrigens: Um alles zu testen, hatte ich kein 500-Ohm-Poti, sondern nur ein 10-kOhm-Poti. Das ist für diesen Zweck nicht gut geeignet, weil für uns der Bereich zwischen 50 und 300 Ohm interessant ist. Ich habe es dann aber so gelöst, dass ich die zwei Widerstände mit 174 und 523 Ohm ausgelötet und dort das 10-kOhm-Poti eingelötet habe. Somit kann ich eine beliebige Spannung von 0 bis 5 V an den ADC senden. Ich habe dann alle Werte noch einmal geprüft, und es passt alles.

Also funktioniert es so: Der Sensor bildet zusammen mit den zwei Widerständen eine Spannung, die vom ADC gemessen wird. Das erste und dritte Array bilden eine interpolierte Kennlinie für ADC → Schrittmotorwerte, und das zweite und dritte Array für ADC → Temperaturwerte.

Um die Plateau-Funktion zu entfernen, muss man einfach das zweite und vierte 0x95 durch den richtigen interpolierten Wert ersetzen. Laut meiner Berechnung ergibt das dann folgendes Array 3:

E3 B4 95 77 30

Ich habe es geflasht und mit dem Poti geprüft — funktioniert super. Die Werte sind auch ähnlich wie die, die GTFahrer berechnet hat.

Es wurden dann auch die Werte für die Warnleuchte bei hoher Temperatur herausgefunden. Es gibt zwei davon: Byte 0x44 und 0x45. 0x44 ist der ADC-Wert, bei dem die Leuchte angeht, und 0x45 der Wert, bei dem sie wieder ausgeht. Das bildet also eine Hysterese.

Mit der Temperaturanzeige sind wir fertig. Jetzt kommt die Tankanzeige.

Die Arrays 0x1C–0x20, 0x21–0x25 und 0x26–0x2A wurden ebenfalls herausgefunden. Gleiches Spiel …

Die Widerstände für die Tankanzeige sind in diesem Fall 255 Ohm an 5 V und 2,61 kOhm an GND.

Die Spritmenge wird im Bereich 0x21–0x25 in Viertellitern dargestellt. Ein Wert von 4 bedeutet also 1 Liter.

Dann wurde herausgefunden, dass Byte 0x2B die Spritmenge definiert, bei der die Tankleuchte angeht. Auch hier in 1/4 Litern. 0x1C bedeutet also 7 Liter, was mit allem zusammenpasst.

Nächstes Thema: Kühlmittelmengen-Warnleuchte.

Der Sensor dafür ist sehr genial! Es sind einfach zwei Elektroden, die im Kühlwasserbehälter eingebaut sind. Eine ist mit Masse verbunden, die zweite geht zum KI

Ah … es misst einfach den Widerstand des Wassers, ähnlich wie bei der Temperatur- und Tankanzeige. Wenn der Wasserstand stimmt, ist der Widerstand niedriger, und umgekehrt.

Es ist aber nicht so einfach, wie ich zuerst dachte.

Das Schaltbild sieht wie folgt aus:



Die MCU erzeugt ein Signal mit einer Periode von 200 ms. Dieses geht durch einen Widerstand zum Kondensator und dann noch durch einen weiteren Widerstand zum ADC-Pin der MCU. Die andere Seite des Kondensators geht zur Elektrode und wird über das Kühlmittel mit Masse verbunden.

Wenn dort keine Verbindung besteht, sieht das Signal am Kondensator so aus:



Und so sieht es aus, wenn es komplett mit Masse verbunden ist:



Die MCU achtet auf die positive Flanke des Signals. Noch einmal vergrößert:

Ohne Masse:



Mit Masse:



Die Spannung wird 2 ms, nachdem die MCU den High-Level eingeschaltet hat, vom ADC der MCU gemessen.

Man sieht: Im ersten Beispiel ist die Spannung >4 V. Das ist mehr, als der 3,3-V-ADC messen kann, deswegen wird der Wert 255 sein. Im zweiten Beispiel sieht man eine Spannung von ca. 1,7 V. Das ergibt einen ADC-Wert von 131.

Dieser Wert wird mit Byte 0x43 verglichen. Wenn er nach einer bestimmten Zeit größer ist, blinkt die Kühlwasserwarnleuchte.

Wie habe ich das zuerst herausgefunden? Diesen Wert sieht man im erweiterten Geheimmenü — dazu später mehr. Ich habe dann bemerkt, dass dort zuerst 255 angezeigt wurde. Später sah ich 132. Dann habe ich den verantwortlichen Pin herausgefunden, und dann ging es los.

Danach habe ich herausgefunden, wie das Verbrauchssignal funktioniert, sowie auch die Konstante dafür im EEPROM.

Das Motorsteuergerät sendet positive Impulse an das KI. Das KI berechnet das Tastverhältnis, und dieses wird mit einer Konstante für 100 % Tastverhältnis multipliziert. Die Konstante befindet sich bei Byte 0x1D und wird in 2 ml/s dargestellt. 0x0D bedeutet also 26 ml/s oder 93,6 l/h — der maximal mögliche Verbrauch. Bei einem Tastverhältnis von 1 % beträgt der Verbrauch 0,936 l/h usw.

Und jetzt kommen wir zum Erweitern des versteckten Menüs. Um es zu aktivieren, muss man bei Byte 0x02 ein Bit mit der Bitmaske 0x80 hinzufügen. Wenn dort also 0x0E steht, muss es 0x8E werden. Und das war’s.

Man geht in das Menü, in dem K-Zahl usw. stehen, und plötzlich sieht man neue Werte unter den Nummern 9, 10 und 11:

9  - Tankinhalt in L
10 - digitaler Tacho in km/h oder mph, abhängig von der K-Zahl
11 - ADC-Wert für den Kühlmittelniveausensor

Als Letztes würde ich noch zwei 16-Bit-Werte beschreiben: die Bytes 0x04–0x05 und 0x06–0x07. Das sind genau die Werte, die die Tacho- und RPM-Skala definieren. Es wird ungefähr so umgerechnet: Impulsmenge vom Geber / K-Zahl * Skalawert

Das ergibt die Position des Zeigers. Die K-Zahl ist natürlich nur für den Tacho relevant. RPM habe ich noch nicht getestet. Vielleicht ist es von der Zylinderanzahl abhängig.

Es gibt noch andere kleine Sachen, die ich in der Pattern-Datei für ImHex beschrieben habe und hier nicht erwähnt habe. Ich habe versucht, dort alles zu sammeln, was ich auch von anderen in diesem Forum gefunden habe. Manche Sachen habe ich aber noch nicht getestet. Und es gibt natürlich noch mehr zu entdecken.

Zum Schluss wollte ich noch erzählen, dass ich das Protokoll von VDO.EXE reverse-engineered habe, aber darüber vielleicht später mehr. Es hat schon viel Zeit gekostet, das alles zu beschreiben Aber einfach zur Info: Ich habe es hinbekommen, die Bytes mit einem Arduino zu schreiben und zu lesen. Leider darf man bei SW-Version 3.9 im Bereich von 0x5C bis zum Ende nicht schreiben, also kann man den Kilometerstand nicht ändern

Ich werde versuchen, später ein GitHub-Repo zu eröffnen, in das ich den Arduino-Code sowie diese Pattern-Datei hochlade, damit wir es zusammen erweitern können — falls sich überhaupt noch jemand für solche alten Autos interessiert

Ich hoffe, es war interessant und hilfreich

VG
Vlad

Und hier ist Pattern-Datei:

bitfield RegionalConfig_t {
    unk_1: 1;
    use_fahrenheit_2: 1;
    unk_4: 1;
    use_24h_clock_8: 1;
    unk_10: 1;
    brake_test_20: 1;
    is_eu_40: 1;
    unk_80: 1;
};
RegionalConfig_t reg_config @ 0x0;

bitfield CyllinderCountAndElse_t {
    unk: 4;
    eng_cyl_count_minus_4: 4;
};
CyllinderCountAndElse_t cyllinder_count_and_else @ 0x1;

bitfield Configuration_2_t {
    unk_1: 1;
    unk_2: 1;
    // If low oil pressure switch is not connected to GND
    // when engine is not running
    // and this test is activated
    // oil pressure lamp will blink
    // maybe somewhere there is RPM value stored
    // that defines engine not running rpm threshold
    oil_pres_low_switch_diag_enabled_4: 1;
    // If disabled - fuel lamp tuns on for 2 sec when ignition turns on
    // Maybe affects something else too
    reserve_fuel_lamp_test_on_ign_on_disabled_8: 1;
    unk_10: 1;
    unk_20: 1;
    unk_40: 1;
    // If enabled it activates 3 more items in hidden menu
    // number in menu | value on LCD  |  meaning
    // ---------------|---------------|-----------
    // 9              | 3             | fuel amount in litres
    // 10             | trip and ".0" | Digital speedometer
    // 11             | 255 or 153    | coolant level sensor raw ADC value
    // Position 11 is probably RAW ADC Value for coolant level sensor
    // Coolat level sensor works by measuring conductivity of coolant relative to ground
    // If T28/2 is not connected - open circuit - coolant level low
    // ADC value in this case is 255
    // If it is connected to ground ADC value is about 153
    // Position 9 is fuel amount in litres
    // It starts from 3 and ends with 52 at full
    hidden_menu_activate_more_items_80: 1; 
};
Configuration_2_t config_2 @ 0x2;

bitfield KZahlAndRPMCharacter_t {
    kzahl : 12; // Add 3000 to get real value
    rpm_character  : 4;
    // 2, 6500-7000rpm, VR6
    // 4, 4700-5000rpm, Diesel
    // 6, 6900-7500rpm, 16V
    // 8, 6200-7000rpm, bis 85kW
    // E, 5500-6500rpm, bis 55kW
};
le KZahlAndRPMCharacter_t k_zahl_and_rpm_character @ 0x4;


// 0x95D8 - 7000rpm
// Havent tested yet, but most likely it's true
// Because next param - speedo works
le u16 rpm_stepper_arrow_factor @ 0x6;

// 0x958E - 0-220kmh scale
// 0x7D65 - 0-260kmh scale
le u16 speedo_stepper_arrow_factor @ 0x8;


// Layout data (probably just for information, does not do anything)
// In case of value 32270 (decimal)
// 22 means 220kmh speedo (22*10)
// 70 means 7000rpm (70*100)
// 3 is unknown, maybe 1 is for cluster that starts with 20kmh,
// and 3 for cluster that starts with 0kmh
le u16 layout_data @ 0x12;


/*
CONSUMPTION FACTOR

Defines maximum possible consumption rate
at theoretical 100% duty cycle of consumption signal

For example in my dump 0x0D means: 13 * 2 = 26 ml/s or 93.6 l/h

So signal with 1% duty cycle would be 0.26 ml/s or 0.936 l/h

That can be checked in hidden MFA menu which shows consumption in l/h
*/
u8 consumption_factor_in_2ml_s @ 0x1B;


/*
COOLANT SENSOR RELATED

Temperature resistor is connected from ADC input node to GND,
in parallel with the existing 523 ohm resistor.

Circuit:
5V -- 174R -- ADC node -- 523R -- GND
                      |
                      +-- Rtemp -- GND

ADC values are based on VRef ~3.1V (3.1V => 0XFF ADC raw)

Formula:
Rbottom = 523 || Rtemp
Vadc = 5.0 * Rbottom / (174 + Rbottom)
ADC8 = round(Vadc / 3.1 * 255)

This table is based on resistance to temperature plot

Temp C | Input resistance ohm | ADC voltage V | Raw ADC
-------|----------------------|---------------|---------
  50   | 362                  | 2.757         | 0xE3
  55   | 300                  | 2.614         | 0xD7
  60   | 251                  | 2.468         | 0xCB
  65   | 211                  | 2.318         | 0xBF
  70   | 178                  | 2.164         | 0xB2
  75   | 151                  | 2.012         | 0xA6
  80   | 128                  | 1.857         | 0x99
  85   | 110                  | 1.716         | 0x8D
  90   | 94                   | 1.570         | 0x81
  95   | 81                   | 1.436         | 0x76
 100   | 70                   | 1.309         | 0x6C
 105   | 61                   | 1.195         | 0x62
 110   | 53                   | 1.083         | 0x59
 115   | 46                   | 0.977         | 0x50
 120   | 41                   | 0.897         | 0x4A
 
This table is based on measuerments with my EEPROM data
 

ADC voltage V | Arrow position                    | ADC
--------------|-----------------------------------|--------
2.76          | starts moving from 1st line cold  | 0xE3
2.74          | 2nd line cold                     | 0xE1
2.68          | 3rd line cold                     | 0xDC
2.60          | 4th line cold                     | 0xD6
2.51          | a bit less than 70 C              | 0xCE
2.46          | 70 C                              | 0xCA
2.30          | 80 C                              | 0xBD
2.20          | 90 C                              | 0xB5
1.40          | starts moving from 90 C           | 0x73
1.30          | 100 C                             | 0x6B
1.20          | 110 C                             | 0x63
1.10          | almost 120 C                      | 0x5A
0.96          | 130 C                             | 0x4F
<0.45         | goes to 0 C                       | <0x25

 
 After discovery of coolant_celcius_temperature_value_interpolation_table
 here are values and calculated resistance

Raw ADC | Vadc V | Temp C | Rtemp ohm
--------|--------|--------|----------
0x50    | 0.973  | 130    | 45.7
0x76    | 1.435  | 107    | 80.8
0x97    | 1.836  | 90     | 125.1
0xB9    | 2.249  | 75     | 195.4
0xF0    | 2.918  | 50     | 456.7

Arrow raw value to displayed temp:

0x30 -> 50deg
0x6B -> 70deg
0x77 -> 75deg
0x81 -> 80deg
0x95 -> 90deg
0xA8 -> 100deg
0xB4 -> 107deg
0xBA -> 110deg
0xCE -> 120deg
0xE3 -> 130deg

Arrow positions without plateau:

E3 B4 95 77 30

*/ 
// Values are in reverse
// First     value is for max temp
// Last value is for min temp
u8 coolant_adc_raw_value_interpolation_table[5] @ 0x2C;
u8 coolant_celcius_temperature_value_interpolation_table[5] @ 0x31;
u8 coolant_arrow_value_interpolation_table[5] @ 0x36;



// On golf cabrio 4 dump it's 0x20, on seat it's 0x44
u8 collant_maybe_unk_maybe_bitfield @ 0x3B;

bitfield TempDampingAndElse_t {
    // Values more than 8 disable temp arrow
    // If 0, arrow moves very fast, 8 - very slow
    temp_damping: 4;
    unk: 4;
};
TempDampingAndElse_t temp_damping_and_else @ 0x3C;

u8 coolant_adc_overheat_lamp_on_value @ 0x44;
u8 coolant_adc_overheat_lamp_off_value @ 0x45;


u8 coolant_level_sensor_adc_warn_threshold @ 0x43;

/**  FUEL LEVEL RELATED STUFF
When entering hidden menu - fuel lvl arrow is not damped anymore and updates very fast.

 ADC hex   Voltage   Rfuel calc   Fuel L   Gauge pos
 ----------------------------------------------------
 0x39      0.69 V    ~42 ohm      52 L     Full
 0x52      1.00 V    ~65 ohm      39 L     3/4
 0x6B      1.30 V    ~93 ohm      26 L     1/2
 0x90      1.75 V    ~145 ohm     13 L     1/4
 0xD5      2.59 V    ~306 ohm      3 L     Empty
 
0x1C corresponds to 7l of reserve fuel

*/

u8 fuel_lvl_raw_adc_interpolation_table[5] @ 0x1c;
// real fuel value in 1/4 liter values
u8 fuel_lvl_quarter_liter_value_interpolation_table[5] @ 0x21;
u8 fuel_lvl_arrow_position_interpolation_table[5] @ 0x26;

u8 fuel_lvl_reserve_fuel_in_quarter_liter @ 0x2B;


// Service settings
// Did not check yet
le u16 oel_time_setting_in_12h @ 0x52;
le u16 in01_km_setting_in_100km @ 0x54;
le u16 in01_time_setting_in_12h @ 0x56;
le u16 in02_km_setting_in_100km @ 0x5A;

// Service counters
// Did not check yet
le u16 oel_time_counter_in_12h @ 0x4A;
le u16 in01_time_counter_in_12h @ 0x4C;
le u16 in01_km_counter_in_100km @ 0x4E;
le u16 in02_km_counter_in_100km @ 0x50;


le u16 mileage[16] @ 0x60;