Hallo Mitleser,
in der Zwischenzeit habe ich einen Mitschnitt des CAN-Bus gemäß meiner im letzten Beitrag genannten Wünsche erhalten, nochmals vielen Dank dafür. Nachdem ich den analysiert habe, ist mir nun auch klar, wie die Kommunikation zwischen GFP und externen Boostern bezüglich des mfx-Rückmeldesignals erfolgt:
-> recht kompliziert per "mfx Seek" CAN-Frame.
Dieses "mfx Seek" ist in der pdf-CAN-Protokollbeschreibung gar nicht und in der html-Version nicht korrekt beschrieben:
- es wird als Systembefehl mit CAN-ID 0 gesendet, das Response Bit ist nie gesetzt, auch nicht bei einer "gefühlten" Antwort.
- nie kommt der in der Doku angegebene DLC 5 vor, sondern wenn das Kommando vom GFP kommt 6 oder 7, wenn es vom Booster kommt 7 oder 8.
- die UID ist die der Quelle und nicht des Zielgerätes, wird aber vermutlich nicht ausgewertet. *) s.u.
- Datenbyte 5 enthält das "mfx Seek"-Subkommando, dementsprechend variieren die nachfolgenden Bytes:
1
2
3
4
5
6
7
8
9
10
GFP -> BOOSTER (UID = GFP)
D5/D6
00 -- Warten beenden
01 -- auf 1-Byte-Antwort warten
02 NN auf NN Datenbytes warten
BOOSTER -> GFP (UID = BOOSTER)
D5/D6/D7
82 II DD Index II und Wert DD des Datenbytes bzw. CRC
83 VV -- ASK-Wert VV
Der Ablauf ist nun folgender:
Bei einem Abfragekommando an einen Dekoder, das nur eine JA/NEIN-Antwort erfordert, läuft über den CAN-Bus
- GFP->BOOSTER "auf 1-Byte-Antwort warten" bei Absenden des Kommandos aufs Gleis
- BOOSTER->GFP "ASK-Wert" wenn im Booster-Abschnitt ein mfx-Rückmeldesignal erkannt wird, mitgeliefert wird die Höhe des Amplitudenhubs (ASK)
- GFP->BOOSTER "Warten beenden" wenn von irgendwem ein mfx-Rückmeldesignal erkannt wurde oder die zulässige Zeitspanne abgelaufen ist.
Beim Werte-Lesen aus einem Decoder sieht das dann auf dem CAN-Bus so aus:
- GFP->BOOSTER "auf NN Datenbytes warten" mit NN = 1, 2 oder 4, passend zum Lesekommando übers Gleis.
- BOOSTER->GFP "Index II und Wert", wobei der Index bei 0 startet und hochgezählt wird
- ...
- BOOSTER->GFP "Index II und Wert" so lange bis die angeforderte Anzahl Datenbytes plus eines für den CRC übertragen wurden
- GFP->BOOSTER "Warten beenden" wenn von irgendwem ein mfx-Datenpaket erkannt wurde oder die zulässige Zeitspanne abgelaufen ist.
Erstaunt hat mich, dass bei "Read Config" der Booster nicht direkt dem Bedienprozessor antworten darf, sondern erst dem GFP, der dann die offiziellen Antworten für den Bedienprozessor als "Read Config"-Response-Pakete generiert.
*) Über die Quell-UID lässt sich bei einem Paket von einem Booster herausfinden, von welchem es kommt, falls man mehrere Booster hat; eine Art Primitiv-Ortung denn man sieht daran, in welchem Boosterbereich sich der antwortende Decoder befindet.
Die Dekodierung der "mfx Seek"-Paktete ist im CAN-Monitor in Gerds Repo bereits entsprechend eingearbeitet.
Gruß
Rainer