[smf]

Hallo zusammen,

bisher habe ich immer nur mitgelesen, vielen Dank an die tollen Beiträge an die jeweiligen Ersteller! Heute möchte ich mich nun mit einer Idee an die Elektronik-Experten hier wenden: könnte man nicht irgendwie die mfx-Rückmeldung (vielen Dank an Gerhard Bertelsmann und Stefan Krauß für die vielen detaillierten Infos!) dazu nutzen, eine Wer-belegt-das-Gleis-Meldung zu einem Gleisabschnitt zu erhalten?

Leider bin ich bei Hochfrequenztechnik nicht gerade begabt und schon gar nicht erfahren, daher habe ich bisher nicht selbst versucht, das mfx-Signal mittels RDS-Chip (z.B. PT2579-S wie im 60175 oder SAA6579T wie in der Gleisbox) oder gar eigener Schaltung auszuwerten. Hat das hier vielleicht schon mal jemand gemacht? Ich stelle mir vor, dass man wie in angehängter Graphik skizziert über einen kleinen Widerstand (0,1 Ohm?) den Spannungsabfall messen könnte und diesen dann wie ein Booster oder die Gleisbox zusätzlich zu diesen selbst auswertet, vielleicht mit einem ATmega. Wenn dieser auch an den CAN-Bus angeschlossen ist, könnte dieser selbständig eine zusätzliche Nachricht auf den Bus legen, und somit würde man bei entsprechender Steuerungssoftware wissen, welche Lok sich wo befindet...

Vielen Dank für jedes Feedback und viele Grüße - Stefan

[bertr2d2]

Hallo Stefan,

Zitat

---

Hallo zusammen,

bisher habe ich immer nur mitgelesen, vielen Dank an die tollen Beiträge an die jeweiligen Ersteller! Heute möchte ich mich nun mit einer Idee an die Elektronik-Experten hier wenden: könnte man nicht irgendwie die mfx-Rückmeldung (vielen Dank an Gerhard Bertelsmann und Stefan Krauß für die vielen detaillierten Infos!) dazu nutzen, eine Wer-belegt-das-Gleis-Meldung zu einem Gleisabschnitt zu erhalten?

Leider bin ich bei Hochfrequenztechnik nicht gerade begabt und schon gar nicht erfahren, daher habe ich bisher nicht selbst versucht, das mfx-Signal mittels RDS-Chip (z.B. PT2579-S wie im 60175 oder SAA6579T wie in der Gleisbox) oder gar eigener Schaltung auszuwerten. Hat das hier vielleicht schon mal jemand gemacht? Ich stelle mir vor, dass man wie in angehängter Graphik skizziert über einen kleinen Widerstand (0,1 Ohm?) den Spannungsabfall messen könnte und diesen dann wie ein Booster oder die Gleisbox zusätzlich zu diesen selbst auswertet, vielleicht mit einem ATmega. Wenn dieser auch an den CAN-Bus angeschlossen ist, könnte dieser selbständig eine zusätzliche Nachricht auf den Bus legen, und somit würde man bei entsprechender Steuerungssoftware wissen, welche Lok sich wo befindet...

Vielen Dank für jedes Feedback und viele Grüße - Stefan

---

hier gibt es einen interessanten Link zu mfx: SRCPD mit mfx und anderen Erweiterungen
Da gibt es einen Schaltplan mit einem RDS Decoder.
Einen Widerstand würde ich nicht verwenden, sondern einen Übertrager wie hier:
http://www.persmodelrailroad.net/mfx_boost.html

Prinzipiell wäre Dein Ansatz denkbar, aber es gibt IMHO ein paar Probleme:
- die Loks müssten permanent Ihre mfx ID senden. Ist das bei den Lok-Decodern vorgesehen ?
- reicht die zur Verfügung stehende "Bandbreite" für einige Loks aus ?
- jeder Abschnitt müsste eine eigene RDS Decodierung haben. D.h. ein mfx Decoder + CAN fähige MCU. Das wird dann bei einer größeren Menge recht teuer.

Ein ähnliches Prinzip wurde im Rocrail Forum diskutiert. Hier hat man RFID Tags unter Loks und Wagons verwendet. Die RFID Tags sind recht erschwinglich und die Leser ebenfalls. Hier muss man aber die RFID-Leser in das Schienenbett einarbeiten.


Gruß

Gerd

[smf]

Hallo Gerd,

vielen Dank für Deine Antwort, die vielen Infos und den Link zu srcpd. Die Gesamt-Bandbreite ist in der Tat ein Problem, ich hatte nur an die Bandbreite in einem relativ kurzen Abschnitt gedacht.

Die RFID-Tags hatte ich auch schon in der Überlegung, habe aber mit den erschwinglichen Komponenten keinen Erfolg bei Märklin H0 gehabt. Auch der Kontakt mit einem Tag-Hersteller, der angeblich "ganz flache Tags" und "auch in metallischen Umgebungen geeignete Tags" herstellt, war erfolglos. Bei RocRail habe ich die RFID-Tag-Beschreibungen gesehen, allerdings nur für größere Spurweiten bzw. nicht an metallischen Fahrzeugen. Eine Lok, die beim Überfahren eines Tags "ich bin jetzt an Tag XY" sendet, wäre der Hit, bei vielen Fahrzeugen und wenig Rückmeldestellen wäre es andersum günstiger und hätte den Vorteil, dass man nichts am Decoder machen muss, sondern "nur" das Tag am Fahrzeug befestigt - allerdings eben mit dem Problem, dass das Tag in Metallnähe nicht gescheit funktioniert. Die Lok hätte ja eigentlich auch eine Energieversorgung, so dass ich aktive Tags auch schon in Erwägung gezogen habe, allerdings habe ich keine günstigen gefunden - die meisten waren viel zu groß für H0, und alle waren im Vergleich zu passigen Tags extrem teuer (>100 Euro pro Stück).

Hm, weiter nachdenken.

Nochmal vielen Dank, die Diskussion hilft.

Viele Grüße - Stefan

[Stefan Krauss]

Hallo, Stefan,

im Prinzip sind deine Überlegungen schon richtig. Man könnte auch die mfx-Rückmeldung dazu verwenden, um festzustellen, welche Lok (genauer: welcher Dekoder) sich auf welchem Gleis befindet. Zur Zeit gibt es dafür aber kein Produkt und meines Wissens auch kein Bastelprojekt.

Technisch muss man jeden überwachten Gleisabschnitt mit einem RDS-Empfänger ausstatten. Die Strommessung über einen Shunt-Widerstand reicht dazu im Allgemeinen nicht aus, man muss das 52,63 kHz-Trägersignal entkoppeln. Das macht man am besten mit einem Stromtrafo, wie Gerd schon richtig angemerkt hat. So machen das auch die mfx-Empfänger in den Zentralen. Genau genommen muss man für diese Anwendung das RDS-Signal gar nicht dekodieren. Es reicht, das Vorhandensein des Trägers zu detektieren. Die dafür notwendigen steilen und genauen Filter sind aber in den RDS-ICs schon ganz gut aufgehoben. Außerdem sollte man das Digitalsignal dekodieren, so dass man das Fenster, in dem das Trägersignal auftreten kann, kennt. Sonst bekommt man zu viele Fehlmeldungen, die man nicht sicher zuordnen kann. Das alles ist nicht unmöglich, aber hat durchaus eine gewisse Komplexität und am Ende auch einen gewissen Preis.

Bei mfx meldet sich die Lok nicht von sich aus, sie muss "angefragt" werden. Das kann man über die Software antriggern. Die Software braucht man sowieso, denn irgendwer muss die gewonnen Informationen ja auch auswerten. Die Software/Zentrale kennt alle angemeldeten Loks und kann diese reihum abfragen. Das dauert natürlich (ca. 20 ms pro Lok) und löst somit u.U. ein gewisses Bandbreitenproblem aus. Allerdings dürfte sich das in Grenzen halten, wenn die Software die Abfragen entsprechend gestaltet. Solange die Loks stehen, also zum Beispiel nach dem Einschalten und im Schattenbahnhof, ist das kein Problem, auch wenn man viele Loks hat. Hier reicht eine Abfrage in einem längeren Zeitraum. Fahrende Loks müssen häufiger abgefragt werden, damit sie auch in kürzeren Abschnitten sicher erkannt werden. Allerdings fahren zur selben Zeit eben meist auch nur wenige Loks und diese sind der Zentrale/Software bekannt. Ein Bandbreitenthema ist es trotzdem. Eine Abfrage pro Sekunde bei 10 fahrenden Loks kostet eben 20% der gesamten Kommunikationsbandbreite auf der Schiene (ganz grob abgeschätzt).

Wäre schon ein interessantes Projekt. Aber meine Liste dieser Projekte ist lang ...

Grüße
Stefan

[smf]

Hallo Stefan,

auch Dir vielen herzlichen Dank für Deine Antwort. Seltenes Abfragen der Loks wäre inhaltlich nicht das Problem, mit der Abfrage aller Abschnitte beim Einschalten der Anlage oder "auf Kommando" käme ich durchaus zurecht...

Der RDS-Empfänger an sich macht mir preislich auch keine Sorgen, den aktuell in den Boostern verbauten bekommt man ja schon für weniger als 2 Dollar. Auch die Programmierung stört mich nicht, mit ATmegas habe das eine oder andere durchaus schon hinbekommen, so dass auch das vollständige Auswerten (hoffentlich) nicht so das Problem wäre. Wie auch immer, der elektrotechnische Teil ist meine Schwachstelle. So habe ich zum Beispiel an anderer Front aktuell das Problem, dass mir ein Märklin-Booster an einer Märklin-Gleisbox mit der selbstgeschriebenen Software (angeschlossen per TinyCAN) zwar brav das Schienensignal erzeugt (angemeldete mfx-Lok fährt), aber leider keine Rückmeldungen über den CAN zurückschickt (weder zur Anmeldung noch beim Auslesen der CVs). Ich weiß nicht, ob der Booster den falschen Input bekommt, das falsche ausgibt, den Anmelde-Trigger nicht verschickt oder nur nichts zurückschickt. Das werde ich mal mit einem Oszilloskop schauen, so ich denn ein passendes auftreibe... ops: Ähnliche, aber doch andere Baustelle, sorry für OT.

Was ich noch nicht verstanden habe:

Zitat

---

Genau genommen muss man für diese Anwendung das RDS-Signal gar nicht dekodieren.

---

Wie würde man ohne eigene Decodierung des Signals zuordnen können, welche Lok auf welchem Abschnitt steht?

Nochmals besten Dank und viele Grüße - Stefan

[Stefan Krauss]

Hallo, Stefan,

Zitat

---

Was ich noch nicht verstanden habe:

Zitat

---

Genau genommen muss man für diese Anwendung das RDS-Signal gar nicht dekodieren.

---

Wie würde man ohne eigene Decodierung des Signals zuordnen können, welche Lok auf welchem Abschnitt steht?

---

die mfx-Rückmeldung kennt zwei Arten von Rückmeldung: eine einfache Quittierung und eine echte Rückmeldung von Daten. Bei ersterer meldet der Dekoder lediglich durch ein angelegtes Trägersignal sein "Ok" zurück. Es reicht daher für diese Art der Rückmeldung, zu erkennen, ob das Trägersignal anliegt oder nicht. Die Rückmeldung von Daten (also ganzen Bytes) wird nur beim Auslesen von CVs benötigt. Diese Daten sind im Trägersignal durch Phasensprünge enthalten, eben wie im RDS-Signal. Diese muss man dann auch entsprechend detektieren und auswerten.

Also: Für diese Anwendung reicht das Erkennen der Quittierung eines Befehls, also das einfache Erkennen des Trägersignals. Das funktioniert dann so: Die Zentrale schickt den Befehl "Bist du da?" an eine bestimmte mfx-Lok. Empfängt diese Lok den Befehl, quittiert sie ihn mit der einfachen Rückmeldung. Wenn man nun an verschiedenen Gleisen lauscht, wo die Rückmeldung herkommt, weiß man, wo die Lok steht. Da der Befehl nur an genau eine Lok geht, muss man ihn für alle an der Zentrale angemeldeten mfx-Loks wiederholen.

Grüße
Stefan

[smf]

Hallo Stefan,

ok, das klingt ja in der Tat noch viel einfacher. Zwar hatte ich von dieser Rückmeldeoption in Deinem mfx-Dokument schon gelesen, ehrlich gesagt aber den Zusammenhang mit der expliziten Quittierung auf mfx-Anfragen noch nicht hergestellt bzw. offensichtlich nicht richtig verstanden. Dann werde ich mich in dieser Richtung versuchen.

Nochmals besten Dank, viele Grüße
Stefan

[TT800]

[quote="Stefan Krauss" post_id=1655082 time=1487021603 user_id=15567]
Für diese Anwendung reicht das Erkennen der Quittierung eines Befehls, also das einfache Erkennen des Trägersignals. Das funktioniert dann so: Die Zentrale schickt den Befehl "Bist du da?" an eine bestimmte mfx-Lok. Empfängt diese Lok den Befehl, quittiert sie ihn mit der einfachen Rückmeldung. Wenn man nun an verschiedenen Gleisen lauscht, wo die Rückmeldung herkommt, weiß man, wo die Lok steht.[/quote]
Den gesamten Gleisbereich eines Boosters kann man ja schon jetzt aus dem Hashwert des Rückmelde-CAN-Befehls zuordnen. Der GFP fügt ihn ein. Das nur zum Lauschen abgespeckt für jeden Melde-Gleisabschnitt zur Verfügung zu stellen erzeugt dann auf dem CAN-Bus viel zu viel zusätzlichen Verkehr. Um solchen Engpässen zu entgehen, hat man ja den L88 entwickelt, um die gesamte durch S88 Abfragen generierte Rückmeldekommunikation vom CAN-Bus fernzuhalten und nur mehr die Veränderungen an den CAN-Bus zu melden.

[smf]

Vielen Dank auch für diesen Hinweis, allerdings zielte meine Frage ja explizit darauf ab, dass man etwas feingranulareres hat als die Booster-Bereich-Einteilung. Außerdem würde ich nach überschlägigem Durchrechnen davon ausgehen, dass der CAN-Bus reichlich Reserven hat, wenn man einmal in die Runde fragt und jede Lok ein Paket schickt. Selbst wenn man über hundert Loks hat, dürfte das insgesamt deutlich schneller gehen als zum Beispiel das mehrere Sekunden andauernde "ganz normale Hängenbleiben" der CS2 ein paar Sekunden nach dem Start (SW-Version 4.1.2). Aber selbst wenn nicht: wenn man nach dem gefühlt "ewigen" Hochfahren der CS2 noch ein paar Sekunden wartet, bis alle Loks einem (kleinen) Bereich zugeordnet sind, wäre das zumindest für mich akzeptabel. Ich will ja nicht (unbedingt) die Zugverfolgung über die Rückmeldung machen, sondern in einem (statischen) Zustand abfragen können, wer welches Gleis belegt.

[Stefan Krauss]

Hallo, Ste(f|ph)an!

Zunächst: Für das hier angedachte Rückmeldemodul existiert natürlich überhaupt kein CAN-Befehl. Man müsste also einen "erfinden" - ob das der Weisheit letzter Schluss ist, lass ich mal dahingestellt. Man könnte für den Informationsfluss von einem solchen Rückmeldebaustein zur Steuer-Software, die Zentrale kann damit ja sowieso nichts anfangen, auch einen anderen Weg (USB, Ethernet, Buschtrommel, ...) wählen.

Nehmen wir also mal unseren erfundenen Zusatz-CAN-Befehl an. Am CAN-Bus hingen dann viele der hier skizzierten Rückmeldemodule, die entsprechend viele Gleisabschnitte überwachen. Sie erkennen einen "Bist du da?"-Befehl, schauen, ob in dessen Rückmeldefenster der RDS-Träger anliegt und melden nur dann ein "Auf meinem Gleis steht die Lok". Auf dem CAN sieht man dann bei jeder "Bist du da?"-Abfrage:
- 1 x das Auslösen dieser Abfrage von der Software (über die Zentrale an den GFP geschickt), CAN-Befehl 0x0006xxxx.
- n x die Antwort auf diese Abfrage von jedem GFP, also von der Zentrale und jedem mfx-Booster, CAN-Befehl 0x0007xxxx. Aus der Antwort lässt sich entnehmen, ob die Lok im entsprechenden Booster-Abschnitt steht.
- 1 x die Antwort der hier skizzierten Rückmelder mit erfundenem CAN-Befehl. Es antwortet nur der Rückmelder, der die Lok in seinem Abschnitt erkannt hat. Also nur eine CAN-Botschaft, egal wie viele Rückmelder.

Im einfachsten Fall (nur Zentrale, keine Booster verwendet) werden aus zwei CAN-Befehlen drei CAN-Befehle. Zum Vergleich: Das Schienensignal ist dadurch gut 15 ms belegt, selbst ein langer CAN-Befehl ist nur etwa eine halbe ms lang.

Eine Überlastung des CAN-Busses würde ich daher nicht befürchten.

Grüße
Stefan

[Egon]

Hallo zusammen,

ich lese interessiert mit und vergleiche das mal mit meiner Anlage und meiner PC Steuerung.
Ganz allgemein fährt doch ein Modellbahner einen Zug von A nach B. Entweder macht er das händisch/optisch und hat den Regler in der Hand. Oder er fährt automatisch und "sagt" der Steuerung "fahre den Zug 99 von "A" (dort wo er gerade steht) nach "B" und die Steuerung erledigt das (Stellt die Fahrstraße und lässt den Zug 99 fahren, stoppt ihn dann am RM in "B". Etwas vereinfacht, es soll ja kein Roman werden.) Im Regelfall reicht das aus, der Zug 99 steht in 99,9% aller Fälle korrekt in "B". Im Störfall geht meine Steuerung auf Notstopp. Der/Ein Zug ist in einem Block angekommen wo kein Zug ankommen darf. Lohnt es den Aufwand neben der Zugverfolgung per Steuerung noch zu verfizieren das es tatsächlich Zug 99 ist der da im Block angekommen ist? Und was hilft es mir wenn ich weiss Zug 99 steht im Block "C"? Muss ich nicht idR aktiv werden um das Problem zu beheben?
Je höher der Aufwand umso anfälliger wird etwas. Etwas was gar nicht vorhanden ist kann auch keinen Einfluss nehmen.
Gruß
Egon

[smf]

Hallo Egon,

das sehe ich genauso wie Du, auch meine (ebenfalls selbst geschriebene) Steuerung verfolgt die Züge. Nur beim Einschalten der Anlage stehe ich des öfteren vor dem Problem, dass nach dem Abschalten der Anlage "jemand" Züge entfernt oder hinzugefügt hat. Wenn man dann nach dem Einschalten verifizieren könnte, dass sich die an der jeweiligen Stelle vermutete Lok auch dort befindet, wäre das meines Erachtens eine deutliche Hilfe.

Viele Grüße - Stefan

[Egon]

Zitat

---

Hallo Egon,

.....Nur beim Einschalten der Anlage stehe ich des öfteren vor dem Problem, dass nach dem Abschalten der Anlage "jemand" Züge entfernt oder hinzugefügt hat. Wenn man dann nach dem Einschalten verifizieren könnte, dass sich die an der jeweiligen Stelle vermutete Lok auch dort befindet, wäre das meines Erachtens eine deutliche Hilfe.

Viele Grüße - Stefan

---

Hallo Stefan,
wer macht den so etwas ?
DAS wäre tatsächlich ein Grund für eine Überprüfung, das ist ein gutes Argument - geht ja so ohne weiteres nicht, nur mühsam per Auge und Hand.

Gruß
Egon