die Bussysteme stellen ein echtes Wirrwarr in Bezug auf die Möglichkeiten dar:
LocoNet - da gibt es eine Menge an Open Source Software für und auch viele Anleitungen XpressNet - eigentlich nur für Handregler zum Steuern und Schalten, man findet aber auch inoffizielle Erweiterungen CAN - gutes Bussystem, kenne ich schon ewig aus der Industrie, aber man findet dazu keine weiteren Unterlagen zum Protokoll BiDiB - unter "Open" verstehe ich etwas anders, als das was ich auf opendcc.de usw. lese. SX-Bus - technisch eine schöne Sache wie CAN, müsste man mal etwas modernisieren
Ich habe nicht vor, eine PC-Steuerung einzusetzen. Ich finde kleine Stellpulte mit Gleisplan einfach schöner, durchaus aber mit Belegtmeldungen, vielleicht sogar mit digitaler Anzeige der Loknummer, also Railcom. Hier steht nun aber, dass außer BiDiB alle anderen Rückmeldesysteme viel zu langsam für Railcom wären. Wie macht Lenz das ohne BiDiB?
Mir schwebt schon vor, da ziemlich viel selbst zu bauen, halt Elektronik ;-). Die ersten Experimente mit DCC-Ex und der Z21PG verlaufen bzgl. der Steuerung der Loks ziemlich gut. Nur bei den Bussystemen bin ich mir echt nicht schlüssig, ob ich eines der vorhandenen nehme oder ganz was eigenes mache. Es geht ja nur um die Ansteuerung von Signalen und Weichen über einen Taster in einem Stellpult, der Rückmeldung von Endstellungen durch eine LED und evtl. der Anzeige der Loknummer per Railcom (das könnte für den Schattenbahnhof sinnig sein) auf einer kleinen Anlage.
BiDiB setzt ja auf eine zentrale Komponente (PC), XpressNet und CAN sind für die Anwendung aussen vor (außer, ich baue etwas selbst, das könnte dann auf der elektrischen Ebene durchaus CAN sein, wegen Erfahrung, Verfügbarkeit von CAN-Controllern usw.), SX-Bus lasse ich auch mal beiseite.
Im Moment tendiere ich zu LocoNet, schon alleine wegen dem dezentralen Ansatz. Ich könnte natürlich auch einfach LAN/W-LAN an jeden Controller hängen und über Sockets die Daten hin- und her senden. W-LAN hat aber nun mal keine zugesicherten Zeiten und beim LAN ist dann noch ein Switch erforderlich. Nicht umsonst wird in der Industrie mit CAN und RS485 gearbeitet, bzw. Industrial-Ethernet.
Was meinen die Experten hier so? Für den Anwendungsfall einfach LocoNet nehmen?
irgendwie fehlen mir hier die genaueren Anforderungen, und die sollte man schon klären, bevor man sich in die Niederungen der Umsetzung hinabsteigt. BiDiB ist wirklich dazu gedacht, mit einer zentralen Instanz alle Vorgänge zu überwachen und abzusichern. Die dortige Implementierung setzt auch strikt auf Quittierung der Datenübertragungen, so dass eine hohe Fehlertoleranz realisiert werden kann. Ein Eingabegerät fragt bei der zentralen Instanz an, wenn es etwas tun möchte. Verlaufen alle Prüfungen erfolgreich, wird die Aktion ausgelöst.
CAN kann keine Quittierung in Hardware; wird das gesendete Telegramm von irgendeinem Empfänger als richtig erkannt, ist der Sender zufrieden. Im Prinzip ist das so, als ob man das Fenster aufmacht und etwas hinausruft. Alle können es hören, ob der richtige Empfänger reagiert, ist unklar. Kann man nur dann merken, wenn der eigene Sprößling vom Spielplatz nach Hause kommt. Also muss man für eine quittierte Datenübertragung selbst ein Protokoll aufsetzen. In meinem Auto sendet der Motorcontroller aller 10ms ein Telegramm mit Zustandsdaten in die Welt. Geht mal eins verloren, ist das völig egal, kommt ja gleich das Nächste daher. Das wäre jetzt bei einem Nothaltbefehl einer DCC-Zentrale nicht ganz so toll.
Wenn man dezentral arbeiten will, ist Loconet eine mögliche Lösung. Man muss eben damit leben, dass es keine Instanz gibt, die die gegebenen Kommandos auf Zulässigkeit prüft. Genaus so ist es beim Xpressnet. Alle Busteilnehmer sind gleichberechtigt und wenn eben einer meint, die Weiche auf Anzweig zu stellen, ein anderer aber gerne die Weiche auf gerade stellt, gewinnt der, dessen Kommando zuletzt durch die Zentrale ausgegeben wird. Man kann auch einem anderen Teilnehmer die gesteuerte Lok "klauen" und selber bedienen. Die Hersteller haben das auch erkannt und Lenz zum Beispiel bietet bei den neuen Handreglern einen Clubmodus an. Im Fremo wird das mit Loconet so gelöst, dass ein Handregler fest mit einer Lok verknüpft ist - Fehlbedieung ausgeschlossen. Multimäuse sind dagegen die Büchse der Pandora und der Alptraum eines jeden Betreibers mit vielen gleichzeitigen Nutzern. Bei meiner eigenen Software für das Lenz LW100 habe ich mir mit der Krücke geholfen, dass beim Stellen einer (softwaremäßig) durch eine Fahrstraße verriegelten Weiche das Stellpult einen Nothalt in der Zentrale auslöst. Ist eben die Konsequenz einer fehlenden zentralen Instanz.
Xpressnet ist auch ausschließlich ein Bussystem für Eingabegeräte; die Erweiterungen von Roco sind eine Art Vergewaltigung der Idee. Auch begrenzt die Anzahl der elektrisch möglichen Busteilnehmer den sinnvollen Einsatz.
Lenz macht das ganz einfach: Der lokale Detektor ist nicht an irgendein Bussystem angeschlossen, sondern zeigt die Railcom-Daten schlicht und ergreifend nur an - fertig. Der globale Detektor sitzt in der LZV und kann dann von dort aus Daten auf Anforderung verteilen. Lenz hat auch kein für solche Datenübertragungen geeignetes Bussystem. Xpressnet ist dafür nicht vorgesehen/geeignet und der RS-Bus kann das prinzipiell nicht.
Klar, man kann mit entsprechenden Kenntnissen alles selber bauen. Allerdings sagt mir meine Lebenserfahrung, dass irgendwann die Anzahl der Baustellen die eigene Leistungsfähigkeit übersteigt und auf Dauer der Spaß auf der Strecke bleibt.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
Zitat von topla im Beitrag #2 irgendwie fehlen mir hier die genaueren Anforderungen, und die sollte man schon klären, bevor man sich in die Niederungen der Umsetzung hinabsteigt.
ich hatte es doch im Text erwähnt:
- ohne PC - kleine Stellpulte mit Gleisplan, Tastern, LEDs - Rückmeldungen - Handregler, Eigenbau oder z.B. Multimaus
Mehr ist es nicht.
Zitat von topla im Beitrag #2 CAN kann keine Quittierung in Hardware; wird das gesendete Telegramm von irgendeinem Empfänger als richtig erkannt, ist der Sender zufrieden. [...] Also muss man für eine quittierte Datenübertragung selbst ein Protokoll aufsetzen.
Ich weiß, ich habe schon einiges an Software für CAN entwickelt.
Zitat von topla im Beitrag #2 Multimäuse sind dagegen die Büchse der Pandora und der Alptraum eines jeden Betreibers mit vielen gleichzeitigen Nutzern.
Es wird nicht mehr Teilnehmer/Benutzer geben. Macht auf einer kleinen Anlage einfach keinen Sinn und ich habe auch keinerlei Ambitionen dazu. Ich bin nicht der Betriebsbahner, genauso wie ich im anderen Hobby Amateurfunk nicht derjenige bin, der Wettbewerbe oder sowas mitmacht. Ich mag mich im Hobby nicht irgendwelchen Regularien unterwerfen, Betrieb nach Vorschrift, Funkabwicklung nach Vorschrift (im Wettbewerb) und all solchen Dingen. Für mich steht das Basteln im Vordergrund, die Beschäftigung mit der Technik, mit vielen unterschiedlichen Materialen und der Austausch dazu. Ob das nun das selbstgebaute Funkgerät ist, digitale Modellbahnsteuerung oder die Holzbearbeitung.
Zitat von topla im Beitrag #2 Klar, man kann mit entsprechenden Kenntnissen alles selber bauen. Allerdings sagt mir meine Lebenserfahrung, dass irgendwann die Anzahl der Baustellen die eigene Leistungsfähigkeit übersteigt und auf Dauer der Spaß auf der Strecke bleibt.
jo, das hatte ich schon gelesen, allerdings waren die weiteren Ausführungen für mich dann nicht so richtig konsistent. BiDiB ist also raus und wenn man nur alleine Betrieb macht, ist auch die Rückmeldung von Railcom-Daten nwahrscheinlich nicht ganz oben auf der Liste. Echte Rückmeldungen kann der RS-Bus von Lenz mit den entsprechenden Decodern (LS100 für Weichen, Belegtmelder diverser Anbieter (Blücher)), Loconet kann das natürlich auch. Der dritte Punkt deutet auf mehr als ein Schaltpult hin, da kommt die Sache mit der Zentralinstanz wieder ins Spiel, wenn zwei Stellpulte kommunizieren sollen, zum Beispiel eine eingleisige Strecke zwischen zwei Betriebsstellen mit eigenem Stellpult. Dürfte auf Loconet hinauslaufen, wenn man nicht schon Bestände anderer Herstellen/System hat.
Ich habe dann mal aufgegeben, alles was ich selber bauen könnte, auch selbst zu bauen. Klar, das macht Spaß, aber am Ende will ich mal etwas richtig fahren sehen und nicht nur Kabel und Bits dressieren.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
ZitatRückmeldung von Railcom-Daten nwahrscheinlich
Guten Morgen,
ich hatte Weichenrückmeldung per RailCom mit Switchpiloten ausprobiert und war vom Ergebnis nicht begeistert.
Mal stimmte die Rückmeldung und mal auch nicht. Jedenfalls bei meiner damaligen M-Gleis Anlage keine Grundlage für sicheren Betrieb per Traincontroller.
Habt ihr da bessere Erfahrungen?
Viele Grüße Bernhard
Analog und Digital, PC-Steuerung, Planungsprogramme
Rückmeldungen mit Railcom sehe ich nur im Schattenbahnhof für die Belegtmeldung. Für Weichen und Signale würde ich eher einen Endschalter am Antrieb bevorzugen.
Der Knackpunkt ist Steuern und Melden ohne eine zentrale Instanz, bzw. ohne Rechner. Ich will nicht erst einen Rechner booten müssen, der dann noch meint, eine halbe Stunde Updates zu machen, bei dem ich Software und OS pflegen muss. Das ist der Job mit dem ich meinen Lebensunterhalt bestreite, das muss ich im Hobby nicht haben. Im Hobby ist der Rechner nur ein Werkzeug wie ein Hammer. Das soll auch weiterhin so sein, ich habe lange benötigt, dahin zu kommen und das strikt vom beruflichen zu trennen und auch privat nicht ständig Admin zu sein (bei jedem Treffen irgendwo kam immer die Frage: Hey Du bist doch Admin, mein Rechner spinnt, kannst Du mal eben schauen? Das nervt einfach auf Dauer). Microcontroller und Elektronik gehören heute aber zu meinen Hobbys.
Ansonsten sehe ich aktuell nur LocoNet (CSMA/CD) oder CAN (CSMA/CR). RS485 wird aufwändig, mehr als 256 Teilnehmer (mit 1/8 Transceivern) sind problematisch (was bei mir ganz sicher locker genügen würde) und LAN/W-LAN ist zwar heute auf der Hardwareseite günstig zu machen, aber mindestens LAN benötigt einen Switch und so ein 72 Port Switch unter der Anlage, naja ;-).
CAN ist mit den verfügbaren Buscontrollern auch keine Raketentechnik, aber das Datenprotokoll muss man selbst machen. Jedenfalls habe ich da keine Spezifikation für Modellbahnsteuerung gefunden.
Im Moment passt meiner Meinung nach für den dezentralen Ansatz mit Stellpulten und Rückmeldeanzeigen am Stellpult am besten Loconet. Und es wäre keine Sache, die man von Null an beginnt.
Aber die Frage habe ich ja gestellt, um vielleicht neue Erkenntnisse zu gewinnen ;-)
Ein anderer Ansatz wäre natürlich, gänzlich ohne Bussystem zu arbeiten, das gibt dann aber eine Verdrahtungswüste. Muss ja auch nicht sein, so ein paar kleine Controller, die sich einfach unterhalten, erleichtern das doch enorm.
Railcom für Zubehör habe ich nie probiert und bei Lokdecodern scheint es leidlich für PoM zu funktionieren, allein ist mir das Prinzip einfach zu störanfällig. Kann man aufheben, indem man die gesamte Zubehörseite extra verkabelt (eigene Zentrale) und damit den Problemen eines Rad-/Schienesystems mit den dabei auftretenden Störungen im System umgeht. Da die Lenz LS100 gebraucht immer mal wieder recht preiswert zu haben sind und ich ohnehin als Zentrale eine LZV und als Stellwerk LW100 einsetze, war für mich der RS-Bus die beste Lösung. Gibt bis jetzt auch keine Probleme. Da RS485 im Gegensatz zu CAN keine Kollisionserkennung in Hardware besitzt, musst Du da auch wieder softwareseitig Aufwand treiben oder man setzt halt einen Master ein, der den ganzen Zirkus zeitlich domptiert und hat damit wieder eine Zentralinstanz. Wird wohl bei Deinen Bedingungen auf Loconet hinauslaufen.
Thomas
Das Schöne an einheitlichen Standards ist es, dass es so viele verschiedene davon gibt. Toleranz ist die Erkenntnis, dass es sinnlos ist, sich aufzuregen.
meine Belegtmeldung erfolgt per Stromfühler (LDT RM-GB-8) und S88 (alt) Bus an der ECoS. Funktioniert ohne Probleme bei elektrotechnisch "sauberer" Verlegung der Leitungen mit zentralem Massepunkt und ohne (!) Ringleitung.
TrainController wertet die BM über die ECoS aus und stellt die Fahrwege für die Zugfahrten.
Kurz: Ich brauch kein RailCom, auch weil der TC per BM prüft, ob der Zug die Blöcke im Fahrweg erreicht. Ist das nicht der Fall, erfolgt ein Nothalt aller Zugfahrten.
Viele Grüße Bernhard
Analog und Digital, PC-Steuerung, Planungsprogramme
... SX-Bus - technisch eine schöne Sache wie CAN, müsste man mal etwas modernisieren ...
Hallo Tom,
das ist bereits vor vielen Jahren passiert: Das RMX-System hatte ich selbst bis zum Wechsel zur Modulbauweise in Verbindung mit dem TC erfolgreich im Einsatz (incl. Belegtmelder, Weichen- und Signalsteuerung). Danach habe ich einige Komponenten für die Steuerung der Weichen im Hafen mit einem Stellpult zunächst weiter verwenden können. Mittlerweile bevorzuge ich eine denzentrale Steuerung der Bedienelemente. Dennoch habe ich mit RMX eigentlich nur positive Erfahrungen gemacht, zumal es da eine recht agile Community gibt, die das System stetig weiter entwickelt.
verwendet eigentlich jemand CBUS vom MERG als Bussystem?
Das basiert auf CAN, die Dokumentation und Spezifikation ist frei, alles unterliegt der CC BY-ND Lizenz. Die Spezifikation ist bei Github zu finden. Es gibt einige Schaltungen und auch auf der Seite von RocRail gibt es einiges an Hard- und Software.
Ich hatte eigentlich vor mit einem Raspberry und dem IFNet zu arbeiten, aber leider musste ich mich von BiDiB verabschieden, da ich keine Selbstbauprojekte inkl. Code, wenn dieser Bestandteile von anderen Bastlern, Entwicklern enthält, auf meiner Seite veröffentlichen kann und mir das schon wichtig ist, meine Bastelprojekte vollständig zu veröffentlichen.
für Selbstbauprojekte ist S88 ganz gut: Es ist praktisch ein SPI, der in den meisten Mikrocontrollern hardwaremäßig unterstützt wird, mit zwei zusätzlichen Leitungen für Load und Reset. Wenn man ihn als Ring verdrahtet, lassen sich sogar in beide Richtungen Daten übertragen: S88-Module für die Gleisbesetztmelder die über den Bus TPIC6B595 im Stellpult füttern, und schon hast du deine Anzeige. Da du in den Schattenbahnhof schauen kannst, braucht du eigentlich keine Zugnummernanzeige.
naja, zwischen der Bitschieberei per Schieberegister des S88 und SPI gibt es ja wohl noch ein paar gravierende Unterschiede.
Mir geht es um ein Bussystem, das alles unterstützt, von Rückmeldern, Steuerungen für Weichen und Signale bis zu Handreglern. Zugnummernanzeige ist in der Tat kein Kriterium mehr, Belegtmeldung aber schon. Ich glaube, ich habe auch nicht alle Modelle mit Railcom fähigen Dekodern ausgerüstet.
habe gerade diesen Strang gelesen. Was mich interessiert wäre ein Modul welches mir anzeigt welcher Zug/welches Triebfahrzeug im Schattenbahnhof steht auch wenn im Zug/Fahrzeug ein Decoder verbaut ist der kein Railcom kann; also ein Abfragemodul, welches erkennt da ist ein Decoder im Meldebereich und dann die Adresse anzeigt. Der Einsatz einer PC-Steuerung kommt für mich nicht in Betracht (und darüber diskutiere ich auch nicht!)
ohne Computer für die Anzeige der Zugnummern wird es schwierig, das würde nur mit einer Menge lokaler Displays gehen.
Letztendlich aber ein ganz anderes umfangreiches Thema, von Barcodes und RFID bis zu Railcom. Daher möchte ich Dich bitten dazu einen eigenen Thread zu eröffnen, das würde das Thema Bussysteme total verwässern.
naja, zwischen der Bitschieberei per Schieberegister des S88 und SPI gibt es ja wohl noch ein paar gravierende Unterschiede.
Mir geht es um ein Bussystem, das alles unterstützt, von Rückmeldern, Steuerungen für Weichen und Signale bis zu Handreglern. Zugnummernanzeige ist in der Tat kein Kriterium mehr, Belegtmeldung aber schon. Ich glaube, ich habe auch nicht alle Modelle mit Railcom fähigen Dekodern ausgerüstet.
Die Suche geht also weiter ...
Gruß Tom
Ich habe alle diese Anforderungen erfolgreich mit Loconet erschlagen und baue mir die Komponenten dazu auch mit Arduino günstig selbst. Ich kann es wirklich empfehlen.
Ich wollte dann auch mal aus purer Neugier schauen, was LoDi, CAN, BiDiB usw. alles können, aber bei der Recherche kam nichts raus, das meine Meinung nochmal geändert hätte. Loconet betreibe ich mittlerweile auch ohne Zentrale. Der Knotenpunkt besteht aus einer Einspeisung und einem Pullup. Der Rest sind gleichberechtige Busteilnehmer. Flexibler geht's dann eigentlich nicht mehr.
Loconet hatte ich mir natürlich auch angeschaut. Aber, das arbeitet nur mit 16.6kBit/s, eine vollständige Dokumentation gibt es nicht (das von Digitrax kenne ich) und Arduino Module möchte ich nicht verwenden, ich mag diese Bibliotheken mit dem riesigen Overhead nicht.
Ich habe gestern einen Prototypen zusammen "gebraten", mit einem PIC18F47Q83 und fange gerade damit an, Versuche mit dem CAN Bus zu machen. Der CAN Bus arbeitet dabei mit 125kBit/s. Auf der Seite von Rocrail gibt es zum CAN Bus einiges, dann der CBUS von MERG, darauf basiert wohl auch das System bei Rocrail. Ich habe mir eine Mitgliedschaft beim MERG gegönnt. Das ist in Deutschland wohl kaum verbreitet, aber in UK schon. Jedenfalls gibt es für den CBUS massenhaft Dokumentation, alles unterliegt der CC-BY-NC-SA und GPL Lizenz, auch die Schaltungen und der Quellcode und ist wirklich sauber dokumentiert. Vom CBUS gibt es eine neuere Erweiterung, nennt sich dann VLCB, abwärtskompatibel zum CBUS. Alles in allem scheint es mir das Paradies für Selbstbauer zu sein, ohne das man alles von Grund auf selbst entwickelt. In den bestehenden Schaltungen werden noch ältere PIC Controller verwendet, ich bin auf ein neueres Modell gegangen. Ich nutze aktuell die MPLAB IDE von Microchip. Vielleicht spendiere ich dem Ganzen dann noch eine XpressNet Schnittstelle für Lenz Handregler. CAN/CBUS wird von Rocrail und JMRI unterstützt, da ich nur Linux Software einsetze passt das auch.
Zitat von topla im Beitrag #2Klar, man kann mit entsprechenden Kenntnissen alles selber bauen. Allerdings sagt mir meine Lebenserfahrung, dass irgendwann die Anzahl der Baustellen die eigene Leistungsfähigkeit übersteigt und auf Dauer der Spaß auf der Strecke bleibt.
viele starten da sehr enthusiastisch, müssen diese Erfahrung dann auch recht schnell machen und stoppen dann plötzlich ihre Moba Aktivitäten ganz oder konzentrieren sich schleichend - nach und nach - auf Kauf und Probefahrt neuer Fahrzeug-Modelle. Du scheinst eher zu den Beharrlichen zu gehören.
Zitat von DL7BJ im Beitrag #17Ich werde mal schauen, wie sich das entwickelt.
hast Du eventuell ein aktuelles Update oder gar schon ein praktikables Fazit für hoffnungsvolle Wiedereinsteiger im Jahr 2026?
Zitat von vikr im Beitrag #18 hast Du eventuell ein aktuelles Update oder gar schon ein praktikables Fazit für hoffnungsvolle Wiedereinsteiger im Jahr 2026?
im Moment ist die Lage etwas angespannt, so dass ich den Kopf nicht so richtig frei habe, fürs Hobby. Das wird sich aber (hoffentlich) ab Mitte März wieder bessern.
Aber es gibt durchaus Neuigkeiten, ich hatte dazu doch bereits was geschrieben, hier im Forum, aber doppelt hält besser
Mein CANUSB4-ISO Adapter läuft, ich hatte beim MERG noch ein I/O Modul geordert, das läuft auch. Ich bin nicht ganz glücklich mit der Software JMRI und Rocrail. JMRI ist ja ein riesiger Baukasten, nichts, was man einfach mal eben so anwenden könnte. Rocrail ist zwar toll, aber die Einstiegshürde, insbesondere bei den CAN Modulen, ist recht hoch.
Ich bin ja Befürworter von KISS, so habe ich mich noch ein wenig umgeschaut und habe Traintastic gefunden. Es gibt bereits einen Branch für die Implementierung von CBUS/VLCB. Reinder hat sehr schnell die Basis dafür geschaffen, ich komme da aktuell gar nicht hinterher. Aber die nächsten Schritt sind die weitere Implementierung der einzelnen Ereignisse für die Steuerung. Ich übernehme dabei den Part der Hardwareanbindung, der Tests, Debugging und auch die Umsetzung von Events zur Hardwaresteuerung, während Reinder das Design der Software macht, ich bin im C++ Design nicht so bewandert, ich bin eher immer dicht an der Hardware in C & Assembler. Zur Software gibt es bei Discourse eine Art Forum: https://discourse.traintastic.org/ und hier speziell für CBUS/VLCB.
Das Ziel, eine ganz einfache Steuerung, die man selbst bauen kann, aber nicht muss, wo auch jeder Modellbahner die Platinen gelötet bekommt und eine Software, die einfach ist, nicht überladen und simpel zu bedienen ist, lauffähig unter allen wesentlichen Betriebssystemen sehe ich durchaus in der Kombination CBUS/VLCB, Traintastic und Raspberry und alles zum Hobbypreis¹ Für eine kleine Anlage wie bei mir benötige ich keines dieser Softwarepakete wie Traincontroller (hat sich sowieso erledigt) oder so, das wäre völlig überladen, mit Kanonen auf Spatzen und ich glaube das ist bei ganz vielen so, gleiches gilt für die Multiprotokollzentralen.
Lange Rede, kurzer Sinn - es geht voran, im Moment etwas gebremst, aber nicht gestoppt.
Gruß Tom
¹ ein 16 Kanal I/O Modul mit 8 Eingängen und 8 Ausgängen und das USB Interface kostet jeweils ungefähr 14€, die DCC Zentrale mit 1A Booster liegt bei 25€, ein Booster für 4-5A ebenfalls, der Handregler bei 35€ - eine MERG Mitgliedschaft ist allerdings Voraussetzung für den Bezug der Kits und es kommen noch 19% Einfuhrumsatzsteuer drauf, da Lieferung aus UK. Man kann aber auch alles selbst bauen, liegt alles öffentlich bei Github. Es gibt eine Menge an Kits, von I/O bis Servosteuerung, Belegtmelder usw. - eigentlich alles, was man benötigt.
Thema drucken
Antworten
H0-Modellbahnforum.de - das Forum mit der Forumbahn!
»
Technik und Steuerung von Fahrzeugen und Anlage
»
Digitaltechnik
»
Steuer- und Rückmeldebus - was für ein Wirrwarr
17.12.2022 15:32 (zuletzt bearbeitet: 17.12.2022 15:34)
