Ist zufällig, betrifft immer wieder mal eine andere Lok.
Scheint deshalb schon an meiner Implementierung zu liegen.
Gruss
Dani
Ist zufällig, betrifft immer wieder mal eine andere Lok.
Scheint deshalb schon an meiner Implementierung zu liegen.
Gruss
Dani
Beiträge: | 23 |
Registriert am: | 13.09.2017 |
Spurweite | H0 |
Stromart | Digital |
Hallo,
und endlich mal wieder gibt es eine neue Version 2002 des basrcpd auf meiner Gleissignalerzeugungs-Seite.
Die einzige nennenswerte Änderung ist diesmal das Abschalten bei Kommunikationsverlust.
Bei den Tests mit nach außen geführtem CAN-Bus fiel auf, dass es möglich war, das System so zu blockieren, dass es nicht mehr kontrollierbar war. Deshalb gibt es jetzt eine Überwachung, die einen Nothalt auslöst, wenn der Kontakt zum letzten Steuergerät verloren geht. Dazu wird bei CAN-Clients der Ping und bei SRCP-Clients die Anzahl der aktiven Kommandokanäle überwacht.
Wenn durch ausbleibende Pings und verlorene Kommandokanäle die letzte Einflussmöglichkeit verloren zu gehen scheint, wird das wie ein Nothalt behandelt, also der Fahrstrom abgeschaltet, sofern der neue DDL-Parameter "enable_client_checking" auf yes gesetzt ist.
Außen vor bleiben derzeit die Browsersitzungn am maecan-Server, da habe ich noch keine passende Schnittsstelle gefunden, die deren Anzahl ermittelbar macht.
Gruß
Rainer
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo,
für alle, die den basrcpd in Gerds OpenWRT Image verwenden, gibt es seit Juni eine Vereinfachung:
Man muss den basrcpd-Server(1) nicht mehr per Kommandozeile starten und auch das Aktivieren des "presume-ack"-Modus(2) wurde wesentlich vereinfacht (bisher war editieren einer Konfigurationsdatei erforderlich) - das geht jetzt alles über die Luci-Bedienoberfläche im Browser.
Mit dem Start-Knopf sofort einschalten bzw. per (De)aktiviert-Knopf einstellen, dass automatisch bei jedem Start eingeschaltet wird.
Kurzerklärung "presume-ack":
Wenn man ein oder mehrere externe CAN-Geräte mitverwendet, aber die Möglichkeit besteht, dass auch einmal kein aktives CAN-Gerät angeschlossen ist, hilft die Option "presume-ack on", um eine Blockade der internen CAN-Kommunikation zu vermeiden, da der ACK dann nicht mehr erforderlich ist.
Gruß
Rainer
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo BPi-Anwender,
nach fast einem Jahr gibt es wieder eine neue Version 2102 des basrcpd auf meiner Gleissignalerzeugungs-Seite mit folgenden Änderungen:
- Bei einer schnellen Abfolge von Notstopp und Richtungswechsel konnte der Notstopp-Befehl verloren gehen wenn er zum Zeitpunkt des Richtungswechsels noch nicht über das Gleis gesendet war. Dieses Verhalten ist nun korrigiert, sodass auf jeden Fall der Notstopp zuerst rausgeht.
- Desweiteren werden MS1-CAN-Meldungen jetzt ignoriert, da sie teilweise sinnlose Antworten des basrcpd auf dem Bus bewirkten. Und ein paar Compiler-Warnungen habe ich wieder mal beseitigt, denn die Compiler mäkeln mit jedem Update mehr an bestehendem Code rum.
Gruß
Rainer
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo BaPi-Anwender,
ein Lagebericht.
Nachdem mein altes SD-Kärtchen zunehmend Probleme machte, wollte ich nicht mehr die jahrelang upgegradete Version aufspielen, sondern auf das neue Kärtchen auch neue SW: Armbian bot ein Buster-Image vom Mai 21 mit Kernel 5.10.34. Das lief auch ganz gut los, hatte eine für mich gute Paketauswahl an Bord, aber oh Schreck - der im BananaPi eingebaute CAN-Controller wollte nicht.
Nach einigem Suchen fand ich das Problem im Device Tree: da sind im Boardteil die Pingruppennamen geändert worden, aber nicht im CAN-Overlay. Als Anwender eines "offiziellen Armbian-Images auf unterstützter HW" durfte ich eine Fehlermeldung erstellen. Aber erst danach merkte ich, dass die Ursache viel tiefer steckte, schon Ende 2018 hatte das Linux-Kernel-Team die unvollständige Umbenamung angestoßen. Der CAN-Controller des BananaPi dürfte also bei weiteren Distributionen und schon seit einiger Zeit nicht mehr funktionieren. Ausgenommen davon sind natürlich Images mit eigenem Device Tree wie z.B. Gerds OpenWRT-Image.
Zum Glück kann man das CAN-Overlay korrigieren und das falsche damit überschreiben, damit das Image nutzbar wird. Der Fehler lässt die Interpretation des Device Tree scheitern, so dass auch andere Overlays wie z.B. das fürs SPI nicht ausgeführt werden.
Klar ist, dass der originale CAN-Treiber noch kein "presume-ack" kann, aber NOCH lässt sich der von Gerd angepasste compilieren. "NOCH" weil von Kernelseite Ungemach droht, siehe die Änderung von "dlc" nach "len" .
Der SPI-Treiber ist noch der alte mit Loch bei 64 Bytes; keine Ahnung wie man die bekannte Korrektur in den Kernel kriegt. Da muss man halt sehen, dass die SPI-Pakete kürzer oder länger als 64 sind.
Neu dagegen ist, dass die BaPi-UARTs als Type 4 (16550A) mit Fifo 16 statt als Typ 19 (U6_16550A) mit Fifo 64 erkannt werden, Grund ist dass zur Zeitersparnis beim Booten keine Variantenprüfung mehr stattfindet . Hat aber vermutlich bei meinem Projekt keinen Einfluss, trotzdem seltsam was da im Kernel rumgehampelt wird.
Insgesamt läst sich aber erfreulicher Weise feststellen, dass die modellbahnspezifischen SW-Anteile, also das can2udp-paket, der basrcpd, der maecan-server und das ms1relay, unter dem neuen Kernel weiterhin problemlos laufen.
Gruß
Rainer
NB: jetzt gabs einen neuen Kernel 5.10.43, der hat dann bei der Installation mein korrigiertes CAN-Overlay wieder mit dem fehlerhaften überschrieben!
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo,
es gibt mal wieder eine neue Version 2110 des basrcpd auf meiner Gleissignalerzeugungs-Seite mit folgenden Änderungen, die hauptsächlich die "inneren Werte" der Software betreffen:
- Korrekturen bei TERM- und LOCK-Funktionalitäten via SRCP
- geringfügige Überarbeitung der mfx-Paketerzeugung
- Bearbeitung des "mfx Seek"-Systemkommandos zur Kommunikation mit externen Boostern
- Vorbereitung für die Anschaltung eines RDS-Empfängers über UART-Schnittstelle
- Korrekturen an "common"-Variablen, da deren Verwendung von gcc-10 pingeliger geprüft wird
- Beseitigung von cppcheck-Warnungen
Für den dritten und vierten Punkt habe ich auch die SRCPD-Parameterübersicht angepasst, da diese Funktionen explizit über die Konfigurationsdatei aktiviert werden müssen.
Gruß
Rainer
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Rainer,
Zitat von Rainer Müller im Beitrag #56ist das die Idee eines lokalen mfx-Detektors? Gibt es schon ein Schaltungsbeispiel oder gar mfx-Detektor-PCBs?
- Vorbereitung für die Anschaltung eines RDS-Empfängers über UART-Schnittstelle.
im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix
Beiträge: | 6.353 |
Registriert am: | 23.10.2011 |
Gleise | M, C u. K. |
Spurweite | H0, N |
Stromart | Digital, Analog |
Hallo Vik,
Zitat von vikr im Beitrag #57
Hallo Rainer, ist das die Idee eines lokalen mfx-Detektors? Gibt es schon ein Schaltungsbeispiel oder gar mfx-Detektor-PCBs?
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Rainer, Danke für die Info!
Zitat von Rainer Müller im Beitrag #58Wie händeln denn ESU, Märklin, Uhlenbrock (Piko) und Zimo das? Wie bekommen die mfx codiert bzw. decodiert, wenn RDS-Bausteine so rar sind? Oder modellieren die das auch selbst in der Firmware nach? Für "mfx" wurde ja nie ein Patent erteilt.
"mfx-Rückmeldeempfänger ohne exotische Bauelemente"
im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix
Beiträge: | 6.353 |
Registriert am: | 23.10.2011 |
Gleise | M, C u. K. |
Spurweite | H0, N |
Stromart | Digital, Analog |
Hallo Vik,
Zitat von vikr im Beitrag #59
Hallo Rainer, Danke für die Info!Zitat von Rainer Müller im Beitrag #58Wie händeln denn ESU, Märklin, Uhlenbrock (Piko) und Zimo das?
"mfx-Rückmeldeempfänger ohne exotische Bauelemente"
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Rainer,
Zitat von Rainer Müller im Beitrag #60es gibt ja ein paar interessante Programme zum Download auf https://www.ukwtv.de/cms/
Außer bei Märklin, die laut Karstens Analyse für den Booster 60175 den schon vor Jahren abgekündigten PT2579 verwenden, den sie oder ihr Auftragsfertiger wohl eingelagert haben, keine Ahnung.
Vor ziemlich genau vier Jahren habe ich mich schon mal im Beitrag 18 diesen Threads über die Verfügbarkeit ausgelassen, heute hat vom letzten Typ LC72725KV zwar Mouser noch ein paar in der Kiste, vermerkt aber "Gilt als veraltet und wurde vom Hersteller abgekündigt".
Alle anderen mfx-Aufgaben außer der RDS-Decodierung sind relativ einfach in Firmware zu lösen.
im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix
Beiträge: | 6.353 |
Registriert am: | 23.10.2011 |
Gleise | M, C u. K. |
Spurweite | H0, N |
Stromart | Digital, Analog |
Hallo Vik,
willst du wirklich einen Windows-PC neben jeder Zentrale und jedem Booster?
Zitat von vikr im Beitrag #61
es gibt ja ein paar interessante Programme zum Download auf https://www.ukwtv.de/cms/
genauer auf:
https://www.ukwtv.de/cms/downloads-aside...s-software.html
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Rainer,
Zitat von Rainer Müller im Beitrag #62
willst du wirklich einen Windows-PC neben jeder Zentrale und jedem Booster?
...
Zitat von Rainer Müller im Beitrag #62Ja, aber wie RDS, d.h. auch der Chip arbeitet ist ja gut dokuentiert. Ich dachte bisher immer die Geschwindigkeit ist das Limitierende.
In den Anleitungen findet man, wie man für den PC die Signale am RDS-Chip abgreifen kann, aber genau den will ich ja ersetzen. Lediglich das erste (RDS Spy) bietet auch einen Modus für die Soundkarte statt RDS-Chip, stellt dafür aber an diese spezielle Ansprüche (z.B. Samplingrate von 192 kHz).
im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix
Beiträge: | 6.353 |
Registriert am: | 23.10.2011 |
Gleise | M, C u. K. |
Spurweite | H0, N |
Stromart | Digital, Analog |
Hallo,
es gibt mal wieder eine neue Version 2112 des basrcpd auf meiner Gleissignalerzeugungs-Seite.
Dieses Mal ohne neue Leistungsmerkmale, es ist eine reine Korrekturausgabe gegen die Auswirkungen der Korrektur des Jahr-2038-Problems, bei dem der Sekundenzähler bei 32-Bit-Zeitstempeln ins Vorzeichenbit überläuft.
Bei neueren Kerneln werden deshalb auch bei 32-Bit-Linuxen die Zeitstempel auf 64 Bit aufgebläht, so z.B. bei dem von Gerd auf dem BananaPi eingesetzten OpenWrt. Dass das ab Kernel 5.6 so sein soll findet man zwar im Internet, aber für BaPi- und RaPi-Distributionen (mit Kernel 5.10.xx) gilt das wohl nicht unbedingt, deshalb gab es unter Armbian beim Test keine Probleme, dagegen unter OpenWrt: da waren srcp-Meldungen mit Zeitstempeln so verfälscht, dass ein srcp-Client nicht mehr synchronisiert wurde, wenn ein anderer Client Zustände im basrcpd änderte.
Dies ist mit der Version 2112 nun behoben, korrekte Funktion sollte jetzt mit 32- und 64-Bit-Zeitstempeln gegeben sein.
Gruß
Rainer
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Mitleser,
Zitat von Rainer Müller im Beitrag #64
Dies ist mit der Version 2112 nun behoben, korrekte Funktion sollte jetzt mit 32- und 64-Bit-Zeitstempeln gegeben sein.
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Mitleser,
Zitat von Rainer Müller im Beitrag #58
Hallo Vik,Zitat von vikr im Beitrag #57
Hallo Rainer, ist das die Idee eines lokalen mfx-Detektors? Gibt es schon ein Schaltungsbeispiel oder gar mfx-Detektor-PCBs?
seit Längerem beschäftigt mich das Thema "mfx-Rückmeldeempfänger ohne exotische Bauelemente", nachdem sich ja die RDS-Chips nur noch schwer beschaffen lassen und deshalb nicht so recht für einen Bastelvorschlag taugen. Dieser Detektor kann dann einen "dummen Booster" um die mfx-Erkennung erweitern oder auch sonst die mfx-Rückmeldungen mit Hilfe eines weiteren Prozessors auswerten. Leider macht das Projekt bislang nur wenige Fortschritte.
Nach derzeitigem Stand soll im Zentrum ein PIC16F1705 stehen, dessen beiden OpAmps mit ein paar Widerständen und Kondensatoren einen zweistufigen aktiven Bandpass für den mfx-Träger bilden. Die interne Programmierung des PICs soll das Signal decodieren und das Ergebnis per UART ausgeben, so dass es mit wenig Aufwand (1 Draht) an den Zielprozessor geführt werden kann.
Im BPi-Fall würde also dieses Signal von einem der internen UARTs empfangen und ggf mit den Meldungen über "mfx Seek" kombiniert ausgewertet. Die UART-Ansteuerung habe ich jetzt im basrcpd eingebaut, die Auswertung fehlt noch.
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo,
es gibt mal wieder eine neue Version 2208 des basrcpd auf meiner Gleissignalerzeugungs-Seite, im Wesentlichen eine wip-Version.
Naja, "work in progress" bedeutet ja genau genommen, dass man etwas angefangen hat, was noch nicht komplett fertig ist. So geht zwar das Ermitteln einer mfx-UID mit meinem mfx-Rückmeldeempfänger problemlos, aber das Auslesen von Konfigurationsvariablen damit ist leider noch eine Katastrophe. Die Auswertung der Phasensprünge ist sehr fehlerbehaftet.
Beim "Lokzyklus beenden"-Kommando zeigte sich beim Testen, dass die entsprechende Lok aus der Verwaltung genommen wurde, aber nicht aus dem Refresh-Puffer. Da dieses Problem beim originalen srcpd schon seit 20 Jahren existiert und noch niemand sich daran gestört hat, habe ich das nicht mit höchster Priorität angegangen.
Eingebrachte Änderungen in Version 2208 im Detail:
- Auslesen der mfx-UID mit Hilfe eines RDS-Empfängers über UART-Schnittstelle
- Überarbeitung der Wiederholungen bei 32 Funktionen
- Schnelleres Rückschalten von schnellem auf normalen Refresh
- Bearbeitung des "Lokzyklus beenden"-Kommandos über CAN hinzugefügt
- Beseitigung von Rechteproblemen durch Abfrage auf effektiven User geändert
Für den ersten Punkt habe ich auch die SRCPD-Parameterübersicht angepasst, da diese Funktion explizit über die Konfigurationsdatei aktiviert werden muss.
Gruß
Rainer
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Rainer,
Zitat von Rainer Müller im Beitrag #67grundsätzliche Frage: wäre nach Beenden des wip-status mit Deinem mfx-Rückmeldeempfänger ein lokaler Rückmelder in einem Gleisabschnitt möglich, mit dem man in relativ kurzer Zeit auslesen kann, welche mfx-Lok-Adresse(n) sich gerade dort befindet/befinden?
So geht zwar das Ermitteln einer mfx-UID mit meinem mfx-Rückmeldeempfänger problemlos, aber das Auslesen von Konfigurationsvariablen damit ist leider noch eine Katastrophe. Die Auswertung der Phasensprünge ist sehr fehlerbehaftet.
im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix
Beiträge: | 6.353 |
Registriert am: | 23.10.2011 |
Gleise | M, C u. K. |
Spurweite | H0, N |
Stromart | Digital, Analog |
Hallo Vik,
Zitat von vikr im Beitrag #68
grundsätzliche Frage: wäre nach Beenden des wip-status mit Deinem mfx-Rückmeldeempfänger ein lokaler Rückmelder in einem Gleisabschnitt möglich, mit dem man in relativ kurzer Zeit auslesen kann, welche mfx-Lok-Adresse(n) sich gerade dort befindet/befinden?
Beiträge: | 313 |
Registriert am: | 29.06.2006 |
Homepage: | Link |
Ort: | Korntal |
Gleise | Mä: K und M |
Spurweite | H0 |
Steuerung | basrcpd |
Stromart | Digital |
Hallo Rainer, Danke für die Info.
Zitat von Rainer Müller im Beitrag #69Die Hoffnung, dass Herr Lindner doch ein Broadcast-Kommando versteckt hatte, stirbt zuletzt...
Ein Broadcast-Kommando an alle mfx-Decoder, sichfür die zu identifizieren, haben die Entwickler vor 20 Jahren vermutlich nicht vorgesehen oder es ist ihnen gelungen, das bis heute geheim zu halten. Damit könnte man dann die Decoder z.B. jede Sekunde veranlassen, sich zu melden. Öfters sollte es nicht sein, weil sonst die Rückmeldestufe zu viel Wärme erzeugt, was weder ihr noch dem Fahrzeug drum rum gut tut.
Zitat von Rainer Müller im Beitrag #69Ja, dies entspricht - in etwa - der bei Railcom geübten Kanal-2-Rückmeldung. Da passiert es auch, dass - bei genügend Fahrzeugen im Refresh - der Zug den Abschnitt schon Sekunden verlassen hat, bis die Zentrale den ACK vom betreffenden Decoder endlich bekommt. Zur Notbremsung - z.B. wenn der Fahrdraht endet - zumindest bei einem ICE läßt es sich jedenfalls nicht sinnvoll verwenden. Für eine Lokalisierung der Startbedingungen ist es aber sicher hilfreich.
Vermutlich einzige Möglichkeit ist, alle bekannten Decoder zyklisch anzupingen und den ACK auszuwerten: ein ACK in einem Abschnitt bedeutet dann, dass die letzte angepingte Adresse die des Decoders im Abschnitt war. Bei einem Ping alle 250ms wären da dann bei 20 mfx-Loks 5s maximale Erkennungszeit. Zur dynamischen Verfolgung eher nicht geeignet, aber um bei Betriebsstart die Positionen zu verifizieren würde das evtl. genügen.
im Übrigen - Märklin am liebsten ohne Pukos, z.B. als Trix
Beiträge: | 6.353 |
Registriert am: | 23.10.2011 |
Gleise | M, C u. K. |
Spurweite | H0, N |
Stromart | Digital, Analog |
Hallo zusammen
Habe nun einen PIKO GIRUNO. Bei diesem hat zwar noch die MFX Anmeldung knapp (mit Mühe) funktioniert, aber kein Auslesen von Daten.
Schlussendlich musste ich feststellen, dass der PIKO Decoder mit ca. 8kHz anstelle 52kHz antwortet
Das selbe Verhalten habe ich dann auch noch bei einem neu gekauften ESU Lokpilot 5 Dekoder beobachtet.
Gibt es da eine MFX Änderung die das elraubt oder verstösst PIKO / ESU gegen das Proktokoll und es funktioniert z.T. einfach mehr oder weniger
Zufällig? Weiss jemand mehr?
Gruss
Dani
Beiträge: | 23 |
Registriert am: | 13.09.2017 |
Spurweite | H0 |
Stromart | Digital |
Hallo Dani,
die 8kHz könnten aber auch von der Motor-Endstufe kommen!
Wie hast du denn das mit den 8kHz gemessen?
Gruß est2fe
Beiträge: | 1.451 |
Registriert am: | 07.06.2007 |
Gleise | C + M |
Spurweite | H0 |
Steuerung | 6021 IB1 MS1 MS2 CS2 CS3 |
Stromart | Digital |
Kein Motor war in diesem Moment an. 8kHz genau da sichtbar, wo ich das 52kHz Signal erwarte, vorher und nachher nicht mehr.
Gruss Dani
Beiträge: | 23 |
Registriert am: | 13.09.2017 |
Spurweite | H0 |
Stromart | Digital |
Habe noch ein paar Messungen:
Maerklin_OK.png: Antwort eines Märklin Dekoders, 52kHz gut sichtbar
Maerklin_OK_Zoom.png: Antwort eines Märklin Dekoders, mit Messung 52kHz
PIKO_NOK_Zoom.png: Gleiche Situation bei PIKO Dekoder, nichts von 52kHz zu sehen sondern nur etwas im Bereich 7.5-8KHz, es war KEIN Motor an.
Beiträge: | 23 |
Registriert am: | 13.09.2017 |
Spurweite | H0 |
Stromart | Digital |
Hallo, Dani!
Zitat von Sigg im Beitrag #71
Gibt es da eine MFX Änderung die das elraubt oder verstösst PIKO / ESU gegen das Proktokoll und es funktioniert z.T. einfach mehr oder weniger
Zufällig? Weiss jemand mehr?
Beiträge: | 577 |
Registriert am: | 11.09.2012 |
Homepage: | Link |
Spurweite | H0 |
Stromart | AC, Digital |
Einfach ein eigenes Forum erstellen |