Habe das Problem gefunden und vielleicht gelöst...
für alle die per 'Suche' mal auf dieses Thema stoßen:
1. Es waren zwei aufeinander folgende Blöcke nicht 100%ig getrennt. Scheinbar gab es da hin und wieder mal eine Meldung, wen eine Lok darüber gefahren ist.
2. ST-Train hat scheinbar auch ne Macke, aber habe das nicht weiter untersucht.
Das Gleisbild zeigt die Loknummer korrekt in den Blöcken an, ABER wenn 2 Loks auf einem Block stehen dann gibts nur noch wilde Meldungen, aber das ist vollkommen logisch. Jedoch werden Korrekturen die vom BM kommen SCHEINBAR nicht abgefangen. (wenn es nur angezeigt werden soll, dann völlig vertretbar)
3. Meine Software hatte größere Probleme da die Belegtmeldungen und Loknummermeldungen nicht korrekt verarbeitet wurden.
Problemstellung:
Block 1 (B1) <-> Block 2 (B2) <-> Block 3 (B3)
alle 3 Blöcken hintereinander auf der Strecke und am gleichen BM angeschlossen.
Lok 1 (L1) und Lok 2 (L2) werden genutzt.
Alles Ok, wenn:
- L1 fährt von B1 zu B2
- L1 von B2 zurück zu B1
- L2 von B3 zu B2
- L2 von B2 zurück zu B3
jetzt kommt die Fehlmeldung:
- L1 fährt auf B2
an dieser Stelle meldet der BM das Block 2,3 belegt sind. In der Zusatzadresse, wird gemeldet "Einfahrt B2", ABER in der Rückmelderadresse kommt nun die Adresse für L2, welche zuletzt vom BM detektiert wurde.
Diese Fehlmeldung wird sofort korrigiert, denn gleich danach, wechselt der Wert in der Rückmelderadresse auf die Adresse von Zug 1!
Die Korrektur wird dadurch quittiert, dass in der Zusatzadresse (BM Addresse +1) die selben Werte stehen als zuvor, somit ist auch die Sequenznummer, welche im Bit 6 und 7 stehen, die selbe.
Normalerweise schaltet die Sequenznr immer weiter, aber für die Korrektur bleibt sie auf dem selben Wert.
Meine Software-Lösung:
Nach der Meldung erstelle ich mein Datenpaket, d.h. "Zug x - enter/exit - Block y". Dieses Paket wird gespeichert / gechachet. Sobald eine weitere Meldung kommt (oder ein Timeout erreicht ist), wird das Paket an den Client geschickt (dieser würde dann reagieren und z.b. den Belegtstatus visuell darstellen).
Wenn es eine Korrektur gibt, dann wird das Datenpaket korrigiert (im Beispiel die Loknummer) und dann sofort gesendet.
-> Problem daran: man muss warten, ob es eine Korrektur gibt. Ich habe eine Verzögerung von 250ms gewählt, da ich in meinem Testaufbau immer ca. 90ms warten musste, bis die Korrektur kam. (die hohen Zahlen sind Schuld meiner Implementierung (sicherlich nicht unbedingt der D&H Komponenten)
Aktuell komme ich damit klar, bis sich vielleicht zeigt das auch dies nicht zu 100% funktioniert.
Warum der ganze Spaß? Ich möchte die Strecke "programmieren" und per Belegtmeldungen + Rückmeldung auf die Züge reagieren.
Ein Einmessen und Stoppen per zeitlicher Messung wird natürlich massiv erschwert in der Kombination mit der verzögerten Korrektur.
Fazit: Finger weg! Oder viel Zeit und Wille eine Art der Steurung zu realisieren, die sich bis heute nicht bewährt hat (oder doch?)
Edit: das alles ist keine Kritik an D&H oder ST-Train! Mich ärgert nur die "dünne" Doku zum BM 8i... denn auch die Einstellung "Erkenungszeit" ändert nichts an der Problematik, es wird einfach nur später gesendet. Vielleicht gibts diese Einstellung für "Wackelkontake", aber dokumentiert ist dies eben leider nicht. Auch der Aufbau der Daten in den Adressen für den BM konnte ich nicht finden.