Die mfx-Rahmenstruktur

Impulsformen

Anfang eines mfx-Rahmens

Der mfx-Rahmen wird von zwei Flags eingeleitet. Jedes von ihnen besteht aus einem kurzen Zustand (50µs)zwischen zwei langen (100µs), dauert also 250µs.
Bei den anschliessend folgenden "Bi-Phase Mark"-codierten Datenbits im mfx-Rahmen wird eine 0 durch einen Zustand einer Dauer von 100µs repräsentiert, eine 1 durch zwei Zustände mit einer Dauer von jeweils 50µs.

Abschluss eines mfx-Rahmens

Der mfx-Rahmen wird von vier Flags beendet.
Die letzten Bits vor den Flags sind die CRC-Bits. Sie werden entsprechend dem Polynom x⁸+ x² + x + 1 erzeugt.

Alternativer Abschluss eines mfx-Rahmens

Würde nach den vier Flags zum Abschluss die Polarität nicht stimmen, kann die abschliessende Flanke des letzten Flags entfallen. Die richtige Ruhepolarität muss insbesondere im Mischbetrieb mit dem MM-Protokoll sichergestellt werden.

Fenster für Bestätigungs- Rückmeldung

Zur Rückmeldung werden dem anfordernden Rahmen zwei Fenster mit jeweils 6ms Dauer angehängt, die unterschiedliche Polarität haben und durch zwei Flags getrennt sind.

Zusätzliche Null-Bits

Nach jeweils 8 Einsen wird auf der Sendeseite eine "sinnlose" Null zur übertragung eingefügt, auch in den CRC-Bits. Diese Null muss auf der Empfangsseite vor dem Auswerten wieder entfernt werden. Der einzig erklärbare Sinn ist, dass der Multiprotokollbetrieb mit DCC berücksichtigt wurde, und diese eingefügten Nullen eine Imitation der DCC-Präambel verhindern sollen.

Paketaufbau

Adressfeld

Alle nachfolgenden Pakete beginnen mit einem Adressfeld, das nach einem der folgenden Formate codiert ist:

1 0 A6 A5 A4 A3 A2 A1 A0	Feldlänge 9 Bits, davon 7 Bits Adresse	Adressen 1 bis 127
1 1 0 A8 A7 A6 A5 A4 A3 A2 A1 A0	Feldlänge 12 Bits, davon 9 Bits Adresse	Adressen 1 bis 511
1 1 1 0 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0	Feldlänge 15 Bits, davon 11 Bits Adresse	Adressen 1 bis 2047
1 1 1 1 A13 A12 A11 A10 A9 A8 A7 A6 A5 A4 A3 A2 A1 A0	Feldlänge 18 Bits, davon 14 Bits Adresse	Adressen 1 bis 16383

Die Möglichkeit mit einer Feldlänge von 9 Bit wird auch für die Pakete mit Broadcast-Adresse verwendet, dabei werden dann A6..A0 auf 0 gesetzt:
1 0 0 0 0 0 0 0 0.
Auch die MS verwendet nur die Codier-Möglichkeit mit einer Adressfeldlänge von 9 Bit.

Datenpakete für Geschwindigkeit und Funktionen

Zweck:	überträgt Fahrtrichtung, Geschwindigkeitsvorgabe und/oder Zustand der Zusatzfunktionen an einen Decoder.
Felder:	Adressfeld optionales Infofeld für Fahrtrichtung und Geschwindigkeit optionales Infofeld für Funktionszustand CRC-Feld
Infofelder:	0 0 0 R V6 V5 V4	Geschwindigkeitstufen 0, 16, ... 112 und Richtung
	0 0 1 R V6 V5 V4 V3 V2 V1 V0	Geschwindigkeitstufen 0 bis 127 und Richtung
	0 1 0 F3 F2 F1 F0	Zustand der ersten vier Funktionen
	0 1 1 0 F7 F6 F5 F4 F3 F2 F1 F0	Zustand der ersten acht Funktionen
	0 1 1 1 F15 F14 F13 F12 F11 F10 F9 F8 F7 F6 F5 F4 F3 F2 F1 F0	Zustand aller sechzehn Funktionen
Gesamtlänge:	[9/12/15/18] + [0/7/11] + [0/7/12/20] Bits + CRC8
Rückmeldung:	nicht erwartet
Beispiel:	100000001.0010.0010100.010.0001.00110101 an Decoder mit mfx-Adresse 1: vorwärts mit Geschwindigkeitsstufe 20, die unteren vier Funktionen auf "0001" gesetzt.
Anmerkung:	Geschwindigkeitsstufe 1 wird als Nothalt interpretiert, die im Decoder eingestellte Bremsverzögerung wird ignoriert

Weitere Pakettypen

BAKE

Zweck:	verbreitet die ID der Zentrale, um Decoder, die von einer anderen Zentrale ihre Adresse erhalten haben, zur Neuanmeldung zu veranlassen. Eine Änderung der ID der Zentrale veranlasst die mfx-Decoder zum sofortigen Abschalten sämtlicher Ausgänge. Die selbe Auswirkung hat eine Änderung des Neuanmeldezählers; mit ihm kann die Zentrale alle mfx-Decoder wieder in den Anmeldezustand zwingen.
Parameter:	Broadcast-Adressfeld	"100000000"
	Typ-Kennung	"1111.01"
	ID der Zentrale	32 Bit
	Neuanmeldezähler	16 Bit
Gesamtlänge:	63 Bit + CRC8
Rückmeldung:	nicht erwartet
Beispiel:	100000000.1111.01.00000000000000100000010001011111.0000000000000000.10001111 Bake von Zentrale 0x2045F, Neuanmeldezähler 0x0.

SUCH

Zweck:	Das SUCH-Paket fordert Decoder auf, sich bei der Zentrale zu melden.
Parameter:	Broadcast-Adressfeld	"100000000"
	Typ-Kennung	"1110.10"
	Anzahl auszuwertender Bits	6 Bit
	Decoder-ID	32 Bit
Gesamtlänge:	53 Bit + CRC8
Rückmeldung:	2 Fenster zu je 6ms
Beispiel:	100000000.1110.10.011000.11111111111111101011001000000000.10101101 bisher ermittelte 24 Bits der Decoder-ID 0xFFFEB200 prüfen.

NADR

Zweck:	Das NADR-Paket ordnet einem Decoder eine neue mfx-Adresse zu.
Parameter:	Broadcast-Adressfeld	"100000000"
	Typ-Kennung	"1110.11"
	Neu zugewiesene mfx-Adresse	14 Bit
	Decoder-ID	32 Bit
Gesamtlänge:	61 Bit + CRC8
Rückmeldung:	nicht erwartet
Beispiel:	100000000.1110.11.00000000000001.11111111111111101011001011111001.01011000 Decoder mit ID 0xFFFEB2F9 erhält neue Adresse 1.

PING

Zweck:	Mit diesem Paket wird eine Rückmeldung des Decoders angefordert. Hiermit kann die Zuordnung zwischen mfx-Adresse und Decoder-ID dauerhaft geprüft werden.
Parameter:	Decoder-Adressfeld	9/12/15/18 Bit
	Typ-Kennung	"1111.00"
	Decoder-ID	32 Bit
Gesamtlänge:	47 Bit + CRC8 bei 9Bit-Adressfeldformat
Rückmeldung:	2 Fenster zu je 6ms
Beispiel:	100000001.1111.00.11111111111111101011001011111001.00001100 Rückmeldung angefordert von Decoder mit Adresse 1 und ID 0xFFFEB2F9.

READ

Zweck:	Das READ-Paket startet den Auslesevorgang je eines der in einem mfx-Decoder gespeicherten Parameter.
Parameter:	Decoder-Adressfeld	9/12/15/18 Bit
	Typ-Kennung	"1110.00"
	zu lesender Konfigurationsstring	10 Bit
	erstes zu lesendes Element	6 Bit
	Anzahl zu lesender Elemente	2 Bit (00 -> 1 Byte, 01 -> 2 Bytes, 10 -> 4 Bytes)
Gesamtlänge:	33 Bit + CRC8 bei 9Bit-Adressfeldformat
Rückmeldung:	ja (Details noch unklar)
Beispiel:	100000001.1110.00.0010001100.000001.01.10110000 Auslesen von 2 Bytes des Konfigurationsstrings 0x8C ab dem Element 1 aus dem Decoder mit Adresse 1.

PROG

Zweck:	dient zur Programmierung eines Parameters in einem mfx-Decoder.
Parameter:	Decoder-Adressfeld	9/12/15/18 Bit
	Typ-Kennung	"1110.01"
	zu progr. Konfigurationsstring	10 Bit
	zu programmierendes Element	6 Bit
	Anzahl zu lesender Elemente	2 Bit (immer 00 -> 1 Byte)
	Neuer Wert	8 Bit
Gesamtlänge:	41 Bit + CRC8 bei 9Bit-Adressfeldformat
Rückmeldung:	nicht erwartet
Beispiel:	100000001.1110.01.000100111100001000.11100110.00100100 In Decoder mit Adresse 1 Höchstgeschwindigkeit (CVS=4f, Element 2) auf 230 (=90% von 255) setzen.

Verarbeitungszustände

Einige der Pakete bewirken Zustandsänderungen im mfx-Decoder. Von dem dadurch erreichten Zustand kann die Auswirkung nachfolgender Pakete abhängen.

Beispielsweise wird ein SUCH-Paket nur im Zustand 1 bearbeitet. Dieser wird erreicht durch geänderte Parameter im BAKE-Paket, und verlassen durch ein NADR-Paket. Ein PING-Paket mit der korrekten Decoder-ID wird nur vom Decoder beantwortet, wenn seit dem letzten Spannungseinschalten zuvor mindestens zwei BAKE-Pakete empfangen wurden. Auch nach kurzer Unterbrechung (schechter Gleis-Kontakt) fängt der Decoder erst nach zwei empfangenen Baken wieder an, die Pings zu beantworten. Eine falsche Decoder-ID in einem PING-Paket schaltet sofort alle Decoderausgänge ab und erzwingt eine Neuanmeldung.

Rückmeldungen

Wenn auf ein Paket eine Rückmeldung erwartet wird, folgen diesem 22 Flags und eine 0011-Datenfolge. Die 22 Flags dienen wohl nur dazu, dem Decoder genügend Zeit zu geben um seine Antwort vorzubereiten. Die 0011-Folge veranlasst im Decoder, die Ausgangsstufe für das Rückmeldesignal einzuschalten. Beim Empfang eines Flags wird diese Ausgangsstufe wieder abgeschaltet.
Achtung: Die Ausgangsstufe im Decoder ist nicht für Dauerbetrieb ausgelegt!

Bestätigung

SUCH- und PING-Pakete werden im JA-Fall durch einfaches Anschalten des 52,6kHz- Rückmeldeträgers vom Decoder quittiert. Der Rückmeldeträger ist dabei etwa für 6ms erkennbar.

Die SUCH-Pakete werden zur Anmeldung verwendet.

Gelesene Daten

Zur Rückmeldung gelesener Daten als Antwort auf ein READ-Paket wird der Rückmeldeträger mit einer Übertragungsrate von 912µs/Bit RDS-ähnlich phasenmoduliert. Der Takt wird von der Zentrale vorgegeben, indem sie regelmäßig 25µs-Impulse ausgibt, und zwar die ersten 23 im 912µs-Abstand, die restlichen 30 + 16 * D im Abstand von jeweils 456µs. Dabei ist D die Anzahl der zu lesenden Datenbytes. Die Rückmeldung ist also für ein 1-Byte-Lesen für etwa 42ms aktiviert.

Siehe auch Kapitel "Lesen von mfx-Daten".

Konfigurationsdaten

Die Konfigurationsvariablen sind bei mfx in Konfigurationsstrings mit jeweils mehreren Elemente gegliedert und zu Blöcken gruppiert. Die erste Variable jedes Konfigurationsstrings kennzeichnet die Bedeutung des Strings.

Genauer ist dies im Kapitel "Der mfx-Zugriff auf Konfigurationsdaten" beschrieben.

Wechsel zwischen mfx- und MM-Code

Die Entscheidung, ob der Decoder seine MM-Adresse ignoriert, fällt etwa 3s (geschätzt) nach Spannungsanlegen. Werden in dieser Zeit mfx-Pakete (die nicht mal für den Decoder selber sein müssen) erkannt, werden nur noch mfx-Pakete akzeptiert. Sobald aber die Spannung kurz unterbrochen wird, vergisst er, dass er mal mit mfx gestartet wurde und lässt sich nach der 3-sekündigen Neuerkennungsphase mit MM weiterbetreiben. Dazu reicht eine Unterbrechung von 50ms.
Wird nach mehr als 3s Betrieb mit MM auf mfx umgeschaltet, ignoriert der Decoder sofort alle MM-Pakete. Weder muss seine Adresse oder ein Broadcast in den mfx-Paketen enthalten sein, noch wartet er die 3 Sekunden. Also sofort nach Erkennen des mfx-Protokolls Umschalten nach mfx, und nach 3s mfx Verhindern des Rückschaltens nach MM auch wenn später kein mfx mehr kommt.
Es scheint also, dass ein mfx-Decoder bei Empfang beliebiger mfx-Pakete nicht mehr mit MM zu steuern ist.

Unklarheiten

Alle bisher bekannten Adressfeldformate haben als erstes Bit immer eine 1. Wofür dienen Adressfelder, die mit 0 beginnen, falls sie existieren?
Typcodes 10xx, 110x, und 1111.1x wurden bisher nicht beobachtet. Existieren sie, und wenn ja welche Bedeutung haben sie?
Rückmeldungen wurden bisher nur teilweise ausgewertet. Details sind daher nur unvollständig bekannt.

Ausgabenübersicht:

Ausgabe 0.3 vom Juli 2006
Ausgabe 0.2 vom Februar 2006
Ausgabe 0.1 vom August 2005

Zum Menü