4 Bit Prio
8 Bit Kommando
1 Bit Res-ponse-Status (sorry für die Schreibweise, das korrekte Wort wird vom Board als Spam gewertet...??)
16 Bit Kollisionsauflösung
4 Bit Anzahl folgender Datenbytes (immer 8)
8 Byte Datenbytes (nach Märklin unterteilt in 4 Byte Adresse und 4 Byte Wert)
Jetzt lese ich die CC-Schnitte aus und bekomme schön 13 Bytes, wie es scheint, die Datenbytes schön in die letzten acht Stellen sortiert.
Aber die ersten Bits sind doch ein total krummer Wert???
4 + 8 + 1 + 16 + 4 sind 33 Bit.
Für fünf vollständige Bytes fehlen mir 7 Bit (7 Bit * 0,3l * 4,8% entspricht etwa 100g Alkohol, das ist schon relevant ;-) )
Spass beiseite: Wo kommen diese Bits her? Irgendwoher müssen sie ja kommen, wenn die restlichen Bytes vollständig sind.
LG Klaus
TS12, DX7, Tyros, VL70-m, Polysix, i3, Microwave, blofeld, TG77, Versi II, Rockkordeon, Loverock, Telecaster, GPC-16E, Grand Royale, APX500 BL und noch so ein paar
Hi Wilde13,
Danke für den Link, aber der Satz hilft nicht. UDP ist für Ethernet, ich zapfe die Serielle Schnittstelle an. Die cc-Schnitte simuliert irgendwie einen COM-Port.
Trotzdem ist der Link für die Befehle recht hilfreich.
Zweite Frage wäre, ob in dem Datenfluss aus dem COM-Port die Stuffing-Bits noch enthalten sind oder ob der ftdi-Treiber diese schon entfernt...
Lg klaus
TS12, DX7, Tyros, VL70-m, Polysix, i3, Microwave, blofeld, TG77, Versi II, Rockkordeon, Loverock, Telecaster, GPC-16E, Grand Royale, APX500 BL und noch so ein paar
hlag schrieb:... aber der Satz hilft nicht. UDP ist für Ethernet, ich zapfe die Serielle Schnittstelle an. Die cc-Schnitte simuliert irgendwie einen COM-Port.
Ganz im Gegenteil hilft der Link schon weiter.
Auf dem CAN Bus hast du das folgende Format:
32 Bit CAN Id
8 Bit DLC (Anzahl der verwendeten Datenbytes)
8 Byte CAN Daten
Das sind dann in der Summe 13 Bytes.
Über die CC-Schnitte empfängst du genau diese 13 Byte.
Die Märklin CAN Doku beschreibt genau den Aufbau dieser 13 Bytes, die dann auch per UDP versendet werden. Das, was Märklin als Meldungskennung beschreibt, ist die CAN Id mit 32 Bytes. Gefolgt von DLC und den 8 Datenbytes.
Wenn du etwas C kannst, kanst du auch aus meiner Software mrsystem die entsprechenden Teile als Beispiel entnehmen.
erstmal vielen Dank, ich hab jetzt was länger gebraucht, um da so weit durchzusteigen...
Mein C ist eher rudimentär.
Immerhin, der aktuelle Status ist: ich kann Meldungen aus der CC-Schnitte empfangen und welche senden.
Ist noch eher rudimentär, aber immerhin kann ich Weichen ansprechen, diese stellen und die Antwort auswerten.
Es kommen in der Tat genau 13 bytes.
Die ersten vier (die Can-ID) hab ich noch nicht verstanden.
Wenn ich das richtig sehe, ist das zwar ein Block von vier Bytes, die aber als einzelne Bits in Gruppen zusammenhängen und nicht als die Bytes, als die sie gesendet werden (äh, klar ausgedrückt...?):
Die höheren vier bit der ersten Bytes sind die Prio
Meldung[0] >>4 = Prio
die 8 Bit command verteilen sich auf die niedrigen 4 bits des ersten Byte und die höheren 4 Bit des zweiten Bytes
Meldung[0] << 4 + Meldung[1] >> 4
Dann versteckt sich irgendwo das Res-ponse-Bit, anschließend 16 Bit Hash und die letzten drei Bit des letzten Bytes sind Abfall,
Ist das so richtig ?
lg Klaus
TS12, DX7, Tyros, VL70-m, Polysix, i3, Microwave, blofeld, TG77, Versi II, Rockkordeon, Loverock, Telecaster, GPC-16E, Grand Royale, APX500 BL und noch so ein paarBearbeitet von hlag am 02.04.2020 23:03
Ich steuere meine Märklin Bahn ebenfalls von einem PC aus, Software Visual Basic 2019.
Habe hier mal 6 Telegramme aufgeführt, um den Aufbau zu erläutern:
Ping
Ping Echo
Lfn R 294 f0== 1Licht
Lfn Echo R 294 f0== 1Licht
Lok R 294 v==6
Lok Echo R 294 v==6
Diese 6 Telegramme sehen wie folgt aus
(die Bindestriche sind nur hinzugefügt, um die Telegramme leichter lesen zu können)
Zu sehen sind somit 13 Bytes (mit hexadezimaler Schreibweise)
Weitere Erläuterungen:
1. Byte: ist die Prio, immer "00"
2. Byte: Kennung, "08" z. B. signalisiert dem System einen Lokbefehl
Von der Anlage kommt jeweils ein Echo, und in diesem Telegramm ist das unterste Bit dann gesetzt: "09". Somit wird beim Echo aus "08" dann "09"
3. und 4. Byte: entsprechen dem HA-SH Wert,hier habe ich noch keine weiteren Kenntnisse gesammelt
5. Byte: DLC gibt an, wieviele folgende Datenbytes danach relevant sind
6./7./8./ und 9. Byte: geben die Adresse wieder
9.) - 13.): Byte sind dann die Datenbefehle
Ich hoffe diese Ausführungen helfen, weitere Infos sind dann über die o. g. Druckschrift von Märklin zu entnehmen. Diese ist für den Telegrammaufbau bzw. Inhalt sehr wichtig.
b) die Beschreibung meiner Telegramme ist vielleicht noch nützlich:
An meine Rangierlok BR 294 sende ich den Befehl: F0 einschalten, entspricht hier dem Fahrlicht
Lfn R 294 f0== 1Licht
An meine Rangierlok BR 294 sende ich den Befehl Geschwindigkeitsstufe 6
Lok R 294 v==6
Ich hoffe diese Erläuterungen helfen weiter ...
Tschau
Und ganz zum Schluss noch ein Bild mit dem Telegrammaufbau. Hierbei wird aber eine andere Lok (andere Adresse) angesteuert. Adresse in hex == "17", also die Adresse (1*16) +7==23.
Hallo Ulli,
Das Lebenzseichentelegramm (Ping) wird ja auf der Märklin Seite (ich denke von der Märklin Mobile Station) erzeugt und auf der Märklinseite wiederum (ich denke von der Gleisbox) beantwortet (Ping Echo).
Das erste Telegramm wird mit dem HASH Wert "9F 6E" erzeugt, die Antwort mit dem HASH Wert "CB 7F".
Von daher habe ich für meine Telegramme, die ich zur Anlage vom PC sende auch den HASH Wert "9F 6E " übernommen. Ohne dieses weiter zu hinterfragen.
Da die Kommunikation sehr stabil funktioniert, habe ich nicht weiter geforscht und die Werte so belassen. Wenn es eine andere Vorgabe/ Hinweis/ Ratschlag gibt,würde ich mich über ein Echo sehr freuen.
Eingetragen am 09.03.2020 01:08
v6.01.13 © 2003-2005