[fantux]

Hallo Digital-Stummis,

ich versuche über die Feiertage, alte Märklin-Weichenstellpulte (die blauen mit den ewig klemmenden Tasten) mit Hilfe eines ESP32 als Retro-Weichenstellpulte für meine MS2 anzubinden. Leider funktioniert die Kommunikation auf dem CAN aber noch nicht so ganz wie erhofft.

Ich habe einen BananaPi mit [user]bertr2d2[/user]'s Platine als "Debugger" an den CAN-Bus gehängt und schaue mir mit can-monitor an, was auf dem Bus so los ist. Wenn ich ein bisschen auf meinen Geräten herumdrücke, sieht man dort folgendes:

1
2
3
4
5
6
7
 

16:13:25.535   CAN  0x00169B07  [6] 00 00 30 00 00 01       Zubehör Schalten Lok unbekannt-0 Stellung 0 Strom 1
16:13:25.805   CAN  0x00169B07  [6] 00 00 30 00 00 00       Zubehör Schalten Lok unbekannt-0 Stellung 0 Strom 0
 
16:22:37.626   CAN  0x0016180A  [6] 00 00 30 00 00 01
16:22:37.887   CAN  0x0016180A  [6] 00 00 30 00 00 00
 
 

Bei den ersten beiden Zeilen habe ich den "Weiche Stellen"-Knopf auf meiner MS2 gedrückt. can-monitor hat das Paket wie erwartet decodiert. Wenn das Gleissignal an ist, schaltet meine Testweiche auch.

Bei den letzten beiden Zeilen habe ich den "Weiche Stellen"-Knopf auf dem Weichenstellpult am ESP32 gedrückt. Wenn ich die Bitschieberei von Märklin im CAN-Identifier richtig interpretiere sieht man hier, das Command und die Payload identisch sind. Lediglich der eingetragene Hash unterscheidet sich.

Wenn ich meinen Code anpasse und darin den Hash meiner MS2 spoofe, wird das Paket von can-monitor decodiert und Gleisbox schaltet meine Weiche wie erwartet. Wirklich überzeugt bin ich von diese "Lösung" aber nicht. Neben der offensichtlichen technischen Unschönheit wird auch die Anzeige der Weichenstellung in der MS2 nicht angepasst.

Entlang der Doku des Märklin-CS2-Protokoll V2 gehe ich so vor, um meinen Hash zu berechnen:
* Meinem ESP32 eine UID geben. In der Protokoll-spezifikation ist der Bereich 0x00001800 bis 0x00001BFF frei für Privatanwender. Ich habe 0x000018A0 gewählt.
* Hash berechnen, indem die oberen und unteren Bytes der UID ge-XOR't werden: 0x0000 ^ 0x18A0 = 0x18A0 (zugegeben, ein etwas langweiliges Ergebnis dieser Rechenoperation...)
* Hash ins Paket schreiben.

Bin ich bei der Hash-Berechnung auf dem Holzweg? Gibt es etwas (außer dem Hash) das ich falsch mache?

Gruß,
fantux

[bertr2d2]

Hallo fantux,

Zitat von fantux im Beitrag #1

---

Bin ich bei der Hash-Berechnung auf dem Holzweg? Gibt es etwas (außer dem Hash) das ich falsch mache?

---

Deine Hash-Berechnung ist fehlerhaft. 0x180A ist kein gültiger Hash. CAN Pakete mit falschem Hash ignoriert die Gleisbox. Hier eine funktionierende Implementierung:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 

/*
  CS2 CAN hash generation
  hash' = highword ^ lowword
  
  xxxxxxx11 0xxxxxxxx
  ^^^^^^^    ^^^^^^^^
   \\\   ||||||||
    \\\-- ||||||||
     \\\ ||||||||
  000xxxxxx xxxxxxxxx
 */
uint16_t generateHash(uint32_t uid) {
    uint16_t hash, highword, lowword;
 
    highword = uid >> 16;
    lowword = uid & 0xFFFF;
    hash = highword ^ lowword;
    hash = (((hash << 3) & 0xFF00) | 0x0300) | (hash & 0x7F);
    return hash;
}
 
 

Gruß

Gerd

PS: Im can-monitor habe ich 'Zubehör Schalten Lok unbekannt' korrigiert

[fantux]

Hallo,

das war jetzt ein ziemlich klarer Kopf -> Tisch Moment. Da hätte ich wohl wirklich mal gründlicher lesen können. Allerdings funktioniert dein Code-Schnipsel bei mir nicht. Für mich kommt als Hash nur 0x000A heraus.

Was dagegen funktioniert ist der folgende Ausschnitt (GPLv3, falls den jemand benutzen möchte):

1
2
3
4
5
6
 

uint32_t uid = ((uid >> 3) & 0xFFFFFF00) | (uid & 0x7F);
uint16_t lowBytes = uid;
uint16_t highBytes = (uid >> 16);
uint16_t hash = lowBytes ^ highBytes;
 
 

Die Testweiche schaltet nun erfolgreich! Vielen Dank, Weihnachten ist gerettet

Ein weiteres Mysterium (bzw. "ich bin zu doof die Spec zu lesen") habe ich aber noch. Laut der Beschreibung von Märklin soll das "Prio"-Feld im CAN-Identifier für Zubehörartikel auf 4 gesetzt werden. Die MS2 setzt das Feld aber auf 0. Setze ich selbst das Feld auf 4, interpretiert die Gleisbox den Befehl (Weiche schaltet, Acknowledgement-Paket ist auf dem Bus zu sehen). Die MS2 zeigt im Menü aber nicht an, dass die Weiche umgeschaltet wurde.

Setze ich selbst das Feld auf 0, interpretiert die Gleisbox den Befehl *und* die MS2 zeigt die geänderte Weichenstellung an. Was habe ich hier für einen Verständnisfehler?

Zitat

---

PS: Im can-monitor habe ich 'Zubehör Schalten Lok unbekannt' korrigiert

---

Gibt es dafür schon ein neu gebautes Image auf deiner Webseite? Dem Downloadlink ist das leider nicht anzusehen. Ich schlage vor, eine Versionsnummer oder Buildnummer bei deinen Downloadlinks einzuführen

Gruß,
fantux

[bertr2d2]

Hallo fantux,

Zitat von fantux im Beitrag #3

---

Hallo,

das war jetzt ein ziemlich klarer Kopf -> Tisch Moment. Da hätte ich wohl wirklich mal gründlicher lesen können. Allerdings funktioniert dein Code-Schnipsel bei mir nicht. Für mich kommt als Hash nur 0x000A heraus.

---

hmm, hier mein Test-Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 

#include <stdio.h>t;
#include <stdint.h>
 
/*
  CS2 CAN hash generation
  hash' = highword ^ lowword
  xxxxxxx11 0xxxxxxxx
  ^^^^^^^    ^^^^^^^^
   \\\   ||||||||
    \\\-- ||||||||
     \\\ ||||||||
  000xxxxxx xxxxxxxxx
 */
uint16_t generateHash(uint32_t uid) {
    uint16_t hash, highword, lowword;
 
    highword = uid >> 16;
    lowword = uid & 0xFFFF;
    hash = highword ^ lowword;
    hash = (((hash << 3) & 0xFF00) | 0x0300) | (hash & 0x7F);
    return hash;
}
 
int main(int argc, char **argv) {
    uint32_t uid;
    uint16_t hash;
 
    if (argc != 2) {
        printf("error: usage %s hex_uid\n", argv[0]);
        return -1;
    }
    sscanf(argv[1], "%x", &uid);
    printf("uid 0x%08x > hash 0x%04x\n", uid, generateHash(uid));
}
 

sieht für mich ok aus:

1
2
3
 

gcc -o get_mhash get_mhash.c
./get_mhash 18a0
uid 0x000018a0 > hash 0xc720
 

Zitat

---

Ein weiteres Mysterium (bzw. "ich bin zu doof die Spec zu lesen") habe ich aber noch. Laut der Beschreibung von Märklin soll das "Prio"-Feld im CAN-Identifier für Zubehörartikel auf 4 gesetzt werden. Die MS2 setzt das Feld aber auf 0. Setze ich selbst das Feld auf 4, interpretiert die Gleisbox den Befehl (Weiche schaltet, Acknowledgement-Paket ist auf dem Bus zu sehen). Die MS2 zeigt im Menü aber nicht an, dass die Weiche umgeschaltet wurde.

Setze ich selbst das Feld auf 0, interpretiert die Gleisbox den Befehl *und* die MS2 zeigt die geänderte Weichenstellung an. Was habe ich hier für einen Verständnisfehler?

---

Mein Tipp: Vergiss die Prios. Sie sind zwar teilweise dokumentiert, funktionieren aber oft nicht. Oft werden die Befehle mit gesetzter Prio schlicht ignoriert.

Zitat

---

Zitat

---

PS: Im can-monitor habe ich 'Zubehör Schalten Lok unbekannt' korrigiert

---

Gibt es dafür schon ein neu gebautes Image auf deiner Webseite? Dem Downloadlink ist das leider nicht anzusehen. Ich schlage vor, eine Versionsnummer oder Buildnummer bei deinen Downloadlinks einzuführen 8)

---

Mittels 'opkg update; opkg install can2udp' kann man auch ein Update durchführen. can-monitor ist Teil des can2udp Pakets.

Gruß

Gerd

[Happy Feet]

Zitat

---

Ein weiteres Mysterium (bzw. "ich bin zu doof die Spec zu lesen") habe ich aber noch. Laut der Beschreibung von Märklin soll das "Prio"-Feld im CAN-Identifier für Zubehörartikel auf 4 gesetzt werden. Die MS2 setzt das Feld aber auf 0. Setze ich selbst das Feld auf 4, interpretiert die Gleisbox den Befehl (Weiche schaltet, Acknowledgement-Paket ist auf dem Bus zu sehen). Die MS2 zeigt im Menü aber nicht an, dass die Weiche umgeschaltet wurde.

---

Hallo fantux,
im ECoS / MS1 / CS1 CAN-Protokoll Stand 2009) sind die PRIO Bits beschrieben und werden in diesem Protokoll
auch verwendet. Du beziehst Dich wohl auf den Hinweis in der Märklin-Version vom 7.2.2012 auf Seite 5 (PRIO 4 Lok/Zubehörbefehle),
das scheint ein Überbleibsel aus dem ECos-CAN-Protokoll zu sein

Wie Gerd schreibt sind bei der MS2 die PRIO-Bits immer Null. Ich habe die CAN-Kommunikation der
MS2 für alle CAN-ID's im Wertebereich 0x00-0x37 aufgezeichnet, die PRIO-Bits sind immer Null.

Was den HASH anbelangt kannst die Gleisbox mit dem "Universal-Hash" 0x0300 überlisten, da sie diesen Hash akzeptiert.
0x0300 entspricht der UID 0x00 00 00 00.

Gruß Werner

[fantux]

Hallo Stummis,

ein Jahr später, gleiches Projekt, neues Problem
Dank eurer Hilfe hat mein ESP32 letzte Weihnachten mit den Märklin-Stellpulten prima funktioniert. Aber: Kaum geht mal was, will man natürlich noch mehr. Neues Projekt: Loks steuern!

Ich bin mit der CAN-Doku von Märklin soweit gekommen, dass ich von meiner Master-MS2 (Software v2.55) die Liste der Loknamen und daraus folgend eine Lok herunterladen kann (Konfigurationselement "[lokomotive]"). Was ich den Daten entnehmen kann sind die Daten zu Gleisprotokoll und Adresse, was wahrscheinlich ausreichen müsste, um Kontrollpakete für die betreffende Lok zu generieren.

Was ich aber noch Suche sind Informationen zum aktuellen Zustand der Lok: aktuelle Geschwindigkeit, Fahrtrichtung, aktive Funktionen. In den Daten, die die MS2 schickt, sind die Felder ".velocity", ".direction" und viele viele ".fkt"-Datensets zu erkennen. Annahme: Das sind genau diese Daten. Allerdings: wenn ich an der MS2 eine Fahrstufe != 0 einstelle, ist die velocity bei einem erneuten Download der Lok immer noch auf 0 .

Ist das ein eurer Erfahrung nach bekanntes Problem, dass die MS2 diese Daten über "[lokomotive]" nicht herausrückt? Falls ja, gibt es einen Weg, diese Daten über andere Anfragen aus der MS2 herauszukitzeln, oder muss ich einfach dauerhaft auf dem Bus mitlauschen, was für Befehle von der MS2 an alle Loks geschickt wurden?

Dank & Gruß,
fantux

[bertr2d2]

Hallo fantux,

Zitat

---

Hallo Stummis,

ein Jahr später, gleiches Projekt, neues Problem
Dank eurer Hilfe hat mein ESP32 letzte Weihnachten mit den Märklin-Stellpulten prima funktioniert.

---

das klingt sehr interessant. Gibt es dazu einen Doku/Link ?

Gruß

Gerd

[Happy Feet]

[/quote]
das klingt sehr interessant. Gibt es dazu einen Doku/Link ?

Gruß

Gruß
[/quote]

Hallo,

Seite 51 Märklin Kommunukationsprotokoll

Grüße

[fantux]

Hallo bertr2d2,

gibt es. Den poste ich aber nur, wenn ihr mir alle versprecht, nicht drauf zu klicken. Da ich die meiste Zeit an diesem Projekt damit verbringe, die CAN-Kommunikation zu entschlüsseln, lässt sich das Softwaredesign am ehesten durch folgenden Smiley beschreiben: ops: .

Wer meinen Prototypenboard sehen möchte, klicke auf das Thumbnail. Bitte entschuldigt die Bildqualität, im Winter ist das mit dem Tageslicht immer etwas schwieriger...


Ein Schaltregler macht die 3.3V für das ganze Brett. Oben fast rechts sieht man den ESP32 mit CAN-Transceiver und einem Stromtreiber für die Stellpulte. Da der ESP32 einfach keine hunderte GPIOs hat, verwende ich einen S88-Bus, der mit 3.3V läuft. Da ich letztes Jahr über die Feiertage nicht genug S88-Module parat hatte, habe ich mir halt ein paar Atmegas als S88-Rückmelder mit 16 Eingängen programmiert. Trotz der eher... mutigen EMV meiner S88-Verdrahtung funktioniert der Bus total zuverlässig. Wenn man übrigens S88-Module mit CMOS-Bausteinen einsetzt, funktionieren auch die kommerziell erhältlichen Module. Mein Prototyp vom Prototyp war mit einem LDT-Modul gebaut.

Unten Rechts ist die Neuerung von diesem Jahr zu sehen: Ein 128x64-Pixel-Display, per I2C angesteuert, ein Encoder, und ein haufen Drucktaster (Stop, Shift, F0-F4 - ein Schelm, wer sich an den FREDI erinnert fühlt )

Im Moment läuft der ESP32 nur mit CAN. Ich habe letztes Jahr schonmal mit WiFi experimentiert (ESP32 im WLAN, Bpi mit can2lan als Brücke zum CAN). Das funktioniert prinzipiell, allerdings wird der ESP32 dann sehr Stromhungrig und geht bei meinem Setup oft in den Brownout. Das zum laufen zu bekommen ist noch Zukunftsmusik (Blockkondensatoren könnten vielleicht helfen, aber wer hat schon Zeit für Hasenfutter...).

Die Platine mit Buttons und Display ist in KiCAD designed und bei Aisler geätzt. Davor hatte ich ein Breadboard, da war aber nutz Platz für zwei Buttons.

War es das? Ah ja, der Link. Nicht hauen: https://github.com/deltaphi/RR32CanController.

Gruß,
fantux

[bertr2d2]

Hallo fantux,

vielen Dank für die Beschreibung. Ich schaue mir das mal in Ruhe an

Gruß

Gerd

[st-oldie]

Hallo fantux,

Zitat

---

Was ich aber noch Suche sind Informationen zum aktuellen Zustand der Lok: aktuelle Geschwindigkeit, Fahrtrichtung, aktive Funktionen. In den Daten, die die MS2 schickt, sind die Felder ".velocity", ".direction" und viele viele ".fkt"-Datensets zu erkennen. Annahme: Das sind genau diese Daten. Allerdings: wenn ich an der MS2 eine Fahrstufe != 0 einstelle, ist die velocity bei einem erneuten Download der Lok immer noch auf 0 .

Ist das ein eurer Erfahrung nach bekanntes Problem, dass die MS2 diese Daten über "[lokomotive]" nicht herausrückt? Falls ja, gibt es einen Weg, diese Daten über andere Anfragen aus der MS2 herauszukitzeln, oder muss ich einfach dauerhaft auf dem Bus mitlauschen, was für Befehle von der MS2 an alle Loks geschickt wurden?

---

Soweit mir bekannt ist, werden diese Werte wohl nicht gespeichert. Ich könnte bei mir mal einen Test machen und eine Lok steuern, die Loksinfos der MS2 anfordern und dann die Werte prüfen. Ich hab aber tatsächlich bisher nicht genauer auf diese Werte in der lokomotive.cs2 geschaut.

Es gibt bei der CS2 noch eine Statusdatei lokomotive.sr2.

Meine Software liest am Bus mit.

Tschüß
Michael

[vikr]

Hallo michael.
,

Zitat

---

Soweit mir bekannt ist, werden diese Werte wohl nicht gespeichert. Ich könnte bei mir mal einen Test machen und eine Lok steuern, die Loksinfos der MS2 anfordern und dann die Werte prüfen. Ich hab aber tatsächlich bisher nicht genauer auf diese Werte in der lokomotive.cs2 geschaut.

Es gibt bei der CS2 noch eine Statusdatei lokomotive.sr2.

Meine Software liest am Bus mit.

---

Funktioniert Dein System auch mit Rocrail(mbus)?
Auf: http://www.mbernstein.de/modellbahn/can/software/index.htm scheinst Du es ausdrücklich auf "mcs2 und mgbox" einzuschränken.

MfG

vik

[fantux]

Hallo Michael,

Sowas ähnliches habe ich schon gemacht. Ich habe gerade kein Gleis an der MS2, aber eine DCC-Fahrstufe kann man trotzdem einstellen. Leider bleiben die Werte in der Konfigurationsdatei unverändert auf 0.

Ich habe inzwischen implementiert, dass die Fahrstufe und Richtung nochmal explizit beim master angefragt werden, damit komme ich an die notwendigen Infos. Für die Funktioken steht das noch aus, da wartet noch Tipparbeit auf mich...

Mit dem Download der Komplettliste werde ich mich wohl auch früher oder später auseinandersetzen müssen, da die neueste MS2-Firmwarw die Informationen wohl nur noch in diesem Format rausrückt.

Gruß,
Fantux

[st-oldie]

Hallo vik,

Zitat

---

Funktioniert Dein System auch mit Rocrail(mbus)?
Auf: http://www.mbernstein.de/modellbahn/can/software/index.htm scheinst Du es ausdrücklich auf "mcs2 und mgbox" einzuschränken.

---

Das funktioniert auch mit mbus, da mbus ja auch die Funktionalität von mcs2 mit enthält. Ich hatte allerdings nur mit einer selbstcompilierten Version getestet, die schon älter ist und mbus nicht kennt. Deshalb ist mbus bei Rocrail in der Liste der Programme, mit denen ich die Kommunikation getestet hab, nicht aufgeführt. Bei einem Bekannten hatten wir vor ein paar Wochen Rocrail aktualisiert und erst einmal mit mbus keine Probleme gesehen. Die Liste ist ja keine Einschränkung sondern sagt nur, mit welcher Software ich schon die Kommunikation getestet hab. Meine Software sollte mit jeder Software funktionieren, die mit der CS2 Ethernet Schnittstelle kommuniziert.

Tschüß
Michael