Eine Hürde ist, dass die PID nicht standardisiert sind.
Es gibt 63 mögliche ID, die in jedem Fahrzeug bzw. in jedem Bussystem anders verwendet werden.
Der Master bekommt ein LDF (ein LIN Description File) von seinem Programmierer mitgegeben.
Da drin steht, welche ID in dem konkreten Netz welche Bedeutung haben soll.

Bei uns im Nugget z.B. scheint PID 0x25 zu bedeuten, dass der "SoC" gefragt ist. Und der Batteriesensor weiss, dass mit PID 0x25 er gemeint ist und liefert den gefragten Wert.

Das kann aber bedeuten, dass ein ansonsten baugleicher Batteriesensor aus einem Opel vielleicht dort auf PID 0x42 reagiert. Und bei BMW auf PID 0x28.
Nur mal so als fiktives Beispiel.

Wenn man so durch's Internet geistert, dann scheinen die Hella IBS grundsätzlich PID 0x25 zu nutzen.
Und mit Frame 0x26 teilt man dem IBS anscheinend die verbaute Batteriekapazität in den Bits 32-39 mit (0 .. 250 Ah = Wert 0 .. 250).

Nur sowas herauszufinden ist mühsam.
Ich hatte die Hoffnung, diese LDF aus dem Dometic-Firmwareimage herauszubekommen. Da würde all das gesammelt drinstehen.

Das Hella IBS hast zwei Adressen und is gut Dokumentiert: 0x21-0x26 und 0x27-0x2C, sodass zwei parallele Verbindungen hergestellt werden können. Im Nugget wird die erste Variante verwendet.

github.com/mestrode/IBS-Sensor-Library/b...S_Sensor.cpp#L24-L37

Der IBS des Fahrzeugbatterie ist von einem anderen Hersteller und z. B. einer anderen Adresse bekannt.

Tja. Welches Gerät hätte sich von der ID 0x15 angesprochen gefühlt?

Hallo Chili,

Sie haben een Denkfehler gemacht. Die Spuren sehen anders aus als meine, hier sind die Stoppbits 2 Bits lang und bei mir 1 Bit lang. Dass erster Byte nach der Break ist ein Sync-Byte 0x55. Was der Decoder als 0x15 bedeutet, ist 0x55. Der Decoder wandelt die ProtectedID in die ID um.

Im der erster Trace ist die PID 0x42 und die ID0x02. Im zweiter Trace ist PID=0x85 und ID=0x05.

War die Dometic-Controller isoliert? Dies bedeutet, dass der Master für ID=0x05 ein Payload enthält. Das ist interessant zu wissen.

Siehe hier for mehr information über dat LIN Protocol:
www.electronics-lab.com/lin-protocol-one...motive-applications/
www.kvaser.com/about-can/can-standards/linbus/

FrankB schrieb:

Das Hella IBS hast zwei Adressen und is gut Dokumentiert: 0x21-0x26 und 0x27-0x2C, sodass zwei parallele Verbindungen hergestellt werden können.

In der LIN Bus Topologie gibt es keine "Verbindungen" und auch keine Geräteadressen.
Das ist leider Nonsens.

Chili schrieb:

FrankB schrieb:

Das Hella IBS hast zwei Adressen und is gut Dokumentiert: 0x21-0x26 und 0x27-0x2C, sodass zwei parallele Verbindungen hergestellt werden können.

In der LIN Bus Topologie gibt es keine "Verbindungen" und auch keine Geräteadressen.
Das ist leider Nonsens.

Ich bitte um mehr Verständnis, da mir Übersetzungen ins Deutsche schwer fallen.

Mit "Verbindungen" meinte ich, dass physikalisch zwei IBS-Sensoren an den LIN-Bus angeschlossen werden könnten.

Offensichtlich weiß ich, dass die Adresse nicht existiert. Es heißt Identifier und ich verwende normalerweise ID oder Protected ID.

Ich habe zwei weitere Artikel auf meinem Blog veröffentlicht.
Kühlbox
Heizung

Bei der Kühlbox war ich etwas überrascht, dass der Temperatursensor nicht in NTC-Werten, sondern in umgerechneten Temperaturen angibt. Andernfalls wäre die Beziehung nicht sehr linear.

Ich habe keinen 39-Ohm-Widerstand und meine Kühlbox ist nur auf Stufe 1 nutzbar. Ich frage mich, was mit meiner beobachteten Beziehung passiert, wenn dieser zusätzliche Widerstand vorhanden wäre. Wenn es linear genug ist, könnte es einfach mit einer neuen linearen Anpassung kalibriert werden. Das ist ein schönes zukünftiges Experiment.

Hi Frank,

vielen Dank für deine Forschungen zum Nugget LIN-Bus. Sehr gute Arbeit. Das war die die Basis für mich, um eine Fernsteuerung für die Standheizung zu entwickeln.

Ciao Mario