LIN Protokoll -> Intelligenter Batteriesensor

Reinhard schrieb:

> ein Kunde von uns will einen LIN Intelligenter Batteriesensor ausgelesen
> haben. Wir arbeiten an sich immer mit CAN Bus somit = 0 Erfahrung mit
> LIN. Die HW und der physical layer sind mal an sich klar beim Protokoll
> stellen sich aber uns vorab ein paar Fragen. Gibt es im LIN Standards?

Die Hardware- und Transportschicht sind standardisiert, genau wie bei 
CAN. Die Norm ist öffentlich herunterladbar: 
https://www.cs-group.de/wp-content/uploads/2016/11/LIN_Specification_Package_2.2A.pdf

Beim LIN gibt es nur Remote Frames. D.h. der Header mit der ID wird 
immer vom Master gesendet, und der zuständige Teilnehmer (Master oder 
einer der Slaves) hängt dann die 1-8 Nutzdatenbytes an. Was in den 
Nutzdaten nun drinsteht und in welcher Form ist komplett freigestellt.

Du brauchst zu Deinem Sensor also eine Beschreibung der LIN-Frames. 
Entweder als *.ldf-File (das ist *.dbc für LIN) oder in Prosa zum selber 
nachbauen.

Andrew T. schrieb:
> Vector informatik LIN tools genutzt, funktioniert am Batteriesensor sehr
> gut.
>
> Preiswerter evtl. dies hier:
> Beitrag "LIN-Bus mit Arduino"

Wir haben uns von Peak nen Analyzer bestellt, aber der ist noch nicht da 
und deshalb kann ich mir die SW auch nicht anschauen. Heißt das dort 
sind die von

soul e. schrieb:
> Du brauchst zu Deinem Sensor also eine Beschreibung der LIN-Frames.
> Entweder als *.ldf-File (das ist *.dbc für LIN) oder in Prosa zum selber
> nachbauen.

beschriebenen LDF Infos bereits hinterlegt? Unser Endkunde hat ein paar 
Mercedes Batteriesensoren gekauft und uns gesagt wir sollen sie 
auslesen, dh wenn die LDF Infos nicht hinterlegt sind, müsste ich bei 
Mercedes anrufen und um das LDF bitten.. Die werden wohl eher nicht mit 
der Nase rümpfen wenn wir 100 Stk im Jahr kaufen...

Reinhard schrieb:

> beschriebenen LDF Infos bereits hinterlegt?

Wie soll das da hinterlegt sein? Die LDF-Files sind projektspezifisch. 
Da stehen die verwendeten IDs drin, das Format der Nutzdaten, und deren 
Definiton: "ID 0x26 byte 0 und 1 sind ein uInt16_t mit dem Wert XYZ, 
wobei ein bit 15,73 mV entspricht". Ausserdem so globale Dinge wie 
welche Baudrate verwendet wird, welche Protokollversion, welcher 
Teilnehmer sendet auf welchen IDs, usw.

Bei einem MP3-Player brauchst Du auch genau die Musikdatei, die zu dem 
Lied passt dass Du hören willst. Sonst spielt der das nicht ab.

Die zu Deinem Sensor passende Datei bekommst Du von dem Hersteller genau 
dieses Sensors. Bei Automobilanwendungen üblicherweise im Rahmen eines 
Entwicklungsauftrags nach Unterzeichnung der entsprechenden 
Geheimhaltungsvereinbarung.

Reinhard schrieb:
> Unser Endkunde hat ein paar Mercedes Batteriesensoren gekauft
> und uns gesagt wir sollen sie auslesen,

Die kann man nicht mal eben so auslesen.

LIN kennt nur einen Master.
Das bedeutet jegliche Kommunikation wird vom Master initiiert,
es gibt keinen Fall in dem ein Slave einfach so Daten sendet.

Man kann zwar die paar IDs durchprobieren und schauen auf welche der 
Slave antwortet, dann weiß man aber noch lange nicht auf welche IDs der 
Slave lauscht und was in den Daten überhaupt drin steht.

Ich habe hier ein .ldf von einem Batterie-Sensor und dafür sowohl schon 
den Master als auch einen Slave zur Simulation programmiert.

Das Ding kennt neun Botschaften.
Zwei sind Botschaften die an den Slave gesendet werden, entsprechend 
sind 7 Botschaften welche auf die der Slave nach dem Header mit Daten 
antwortet.

Ohne das .ldf oder auch nur eine .xls dazu kommt man da nirgendwo hin.

Rudolph schrieb:
> Ich habe hier ein .ldf von einem Batterie-Sensor und dafür sowohl schon
> den Master als auch einen Slave zur Simulation programmiert.

Teilst du das File für einen gratis 3D Druck oder so :)

Nein, sorry, das kann ich nicht raus geben.
Aber die Sensoren für die das ist sind ohnehin nicht von Mercedes.
Das .ldf kommt auch direkt vom OEM und nicht etwa vom Zulieferer.