Anzeige:
THEMA: RailCom -- was geht schon, was noch nicht
nach mehr als 2 Jahren Abstinenz von der Modellbahn, habe ich heute Morgen versucht, den Themenkomplex intelligente Rückmelder zu studieren. Zu RailCom habe ich folgende Fragen:
1) RailCom ist aktuell (noch) nicht in der Lage, einer Zentrale oder einem Rechner zu melden, wo sich eine Lok gerade aufhält, richtig?
2) Das heißt dann, falls das stimmt, nach wie vor muss die Zentrale oder der Rechner die eingerichteten Blockstrecken sehr gut kennen, um die Lok nach einmaliger Positionsangabe weiterverfolgen zu können?
3) Soweit ich mich erinnere, hatte Fleischmann (Trainnavigation) ebenso wie Uhlenbrock (Lissy) ein System entwickelt, um bestimmen zu können, wo sich ein Lok aufhält.
Würdet Ihr die Anschaffung solcher Systeme heute noch empfehlen?
4) Oder sollte man schon mit RailCom beginnen?
Das heutige System ist dann bislang im Prinzip ein reines (unintelligentes) Rückmeldesystem, wenn man einmal davon absieht, dass es wohl diesen Anzeigebaustein gibt, der mir sagt, dass eine bestimmte Lok gerade im kontrollierten Abschnitt war?
Wäre toll, wenn Ihr mich erhellen könntet,
viele Grüße,
Boris.
vergiss Lissy. Es ist eine Entwicklung von Uhlenbrock, die Fleischmann seinerzeit eingekauft hatte. Nachdem der Roco-Fleischmann Konzern nun keine Uhlenbrock Technik mehr im Programm hat, ist das gestorben.
Informationen zum Thema Railcom findest Du am besten bei Lenz:
http://digital-plus.de/digitalplus-railcom.php#lrc110
Da wird es vernetzte lokale Detektoren geben, mit einer USB-Anbindung zum Rechner.
Grüße, Peter W.
zu 1: die Ecos und Ihr zugehöriger Detector melden eine mit Railcom plus Decoder ausgerüstete
Lok im überwachten Bereich.
zu 2: ergibt sich aus 1
zu 3: ich für meinen Teil nicht ( arbeite mit der Ecos )
zu 4: ja und intelligent
generell melden alle Gleisbesetztmelder den Standpunkt einer Lok in einem rechnergesteuerten Programm nach positionieren auf diesem .
Gruß Richie
danke für die Antworten!
@ Richie: Muss noch mal genau nachfragen:
Wenn Du meinetwegen eine Lok von den Schienen hebst und ganz woanders wieder auf die Schienen setzt, wird RailCom dann heute schon erkennen, dass es sich um eben diese Lok handelt (= intelligente Rückmeldung) oder musst Du das dem System erst wieder beibringen und solange wird einfach nur erkannt, dass da ein Stromabnehmer auf die Schienen gekommen ist (einfache / unintelligente Rückmeldung)?
VG, Boris.
Railcom ist eine schöne Spielerei.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Überleg mal, ob Du das wirklich brauchst.. ???.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Und Dich eventuell an einige Hersteller bindest, mit allen Loks und Rückmeldern....
Google auch mal unter Railcom Plus... da gibt es nämlich schon wieder was Neues...
Gruß Thomas (der auch so weiß, wo seine Loks stehen)
ich hänge mich hier mal mit einem speziellen Wunsch rein, den ich gegenüber Railcom oder einem anderen denkbaren BiDi-System gegenüber hege.
Ich fahre mit Lenz und den Traincontroller. Letzterer steuert automatische Zugfahrten und verfolgt die auch. Wenn es keine Fehler in der Hardware gibt, weiß das System immer, wo welche Lok ist. Aber, Shit happens, manchmal klemmt eine Weiche und dann ist der TC ausgetrickst.
Beispiel: Der Zug1 fährt von Block A über B und C nach D. Eine Weiche zwischen C und D klemmt und Zug 1 landet in Block E. Block E wird dann belegt gemeldet von einem unbekannten Zug, der vom Himmel gefallen ist. Der TC wartet auf Zug1 in Block D und hält diesen Block reserviert. Zug1 fährt unverdrossen weiter und nur ein Beenden dieser Zugfahrt und eventuell anderer kann Unglücke verhüten. Anschließend sind dann Fahrten zum Aufräumen angesagt, damit alles wieder so ist, wie es sein soll, also Realität und Programm übereinstimmen.
Wenn nun Zug1 sich in Block E melden könnte, wäre es ja möglich, dass der TC, eventuell nach einem Programmupdate, sich so verhalten kann, wie ein Navi, bei dem der Autofahrer sich verfahren hat, also einfach eine neue korrekte Fahrstrasse anlegen und andere Züge anhalten oder umleiten oder was auch immer. Das System könnte dann auf das unerwartete Auftauchen von Zug1 in E statt in D reagieren.
Dazu müsste nach meiner Ansicht die Railcom-Information durch die jeweiligen Belegtmelder weiter gegeben werden. Ist so etwas geplant? Oder sehe die Notwendigkeit, die Information über die Belegtmelder weiter geben zu müssen, falsch?
Viele Grüße
Friedhelm
aus meiner Sicht soll das bei RailCom so kommen.
VG, Boris.
Ich würde lieber die Ursache beheben ("klemmende" Weiche) als zu versuchen, mit Railcom die Fehler auszubügeln
Mit "klemmenden" Weichen würde ich niemals einen Automatikbetrieb fahren.
Gruß
Thomas
ich arbeite durchaus an den Ursachen. Es ist auch nicht so, dass es täglich passiert. Aber es kommt eben vor, da reicht ja ein Schotterkörnchen. Solange die Möglichkeit über Railcom nicht besteht, gibt es für mich keinen Grund, mich ernsthaft mit Railcom zu beschäftigen. Wenn das geht, würde ich darüber nachdenken. Wobei angesichts der Anzahl umzurüstender Loks und auszutauschender Belegtmelder das Ergebnis durchaus offen ist.
Viele Grüße
Friedhelm
Gruß,
Harald.
ich würde erstmal abwarten wie es in Sachen Railcom und anderer Rückmeldesysteme weitergeht. Perfekt wäre es wohl, wenn es auch kleine Sender geben würde, mit denen man nicht rückmeldefähige Decoder nachrüsten kann. Mit dem Tams FD-R Basic geht das schon, aber der ist ziemlich riesig. Für mich wäre diese Nachrüstbarkeit ein Killerargument für ein bestimmtes System.
Mir geht das mit Railcom schon zu lange auf den Keks.Wurde zu lange gezögert mit der kompletten Umsetzung. Habe ausserdem ne menge Rückmelder und Decoder verbaut, die tausche ich doch nicht alle wieder aus. Das hatt sich somit für meine Anlage erledigt, zumal alles perfekt läuft. Und wenn im Autobetrieb mal extrem selten ne Weiche klemmt, na gut. Wird der Zug per Regler zurückgesetzt.
Gruß Herbert
> mit denen man nicht rückmeldefähige Decoder nachrüsten kann.
Gibt es im proprietären Digitrax transponding System.
> Wurde zu lange gezögert mit der kompletten Umsetzung.
http://de.wikipedia.org/wiki/Time-to-Market
Das BiDi wäre toll für überwachtes Fahren bei Modultreffen. Für Heimanlagen ist es wohl so wie Herbert schreibt: Zu wenig und zu spät.
Gruß,
Harald.
Zitat
die Frage ist mit welchem Bus die Meldungen dem PC-Program übergeben werden sollen.
Zitat
Habe ausserdem ne menge Rückmelder und Decoder verbaut, die tausche ich doch nicht alle wieder aus.
Zitat
Für mich wäre diese Nachrüstbarkeit ein Killerargument für ein bestimmtes System.
Zitat
Ja, mit RailCom sollte der Steuerungscomputer genau wissen welcher Decoder in welchem Block Strom zieht.
Zitat
Wenn Du meinetwegen eine Lok von den Schienen hebst und ganz woanders wieder auf die Schienen setzt, wird RailCom dann heute schon erkennen, dass es sich um eben diese Lok handelt
Gruß
Tomi
vielen Dank für die Antworten.
@ Tomi: Vielleicht bin ich ja begriffsstutzig, aber gerade das Weiterverarbeiten der ausgelesenen Adresse scheint ja bei RailCom noch nicht zu laufen.
Lenz hat den dafür notwendigen "Lokaler RailCom Detektor LRC130" ja noch gar nicht im Vertrieb.
Oder verstehe ich was falsch, geht es auch über andere Geräte?
Und von daher auch noch mal meine Frage:
Wäre so etwas wie Lissy dann keine Alternative? Oder Trainnavigation von Fleischmann?
VG, Boris.
Dazu sagt Lenz: Zuerst brauch ich ein XpressNet dass "demnächst" auf 128 Teilnehmer erweitert wird. Auch habe ich schon einen Boosterbus verlegt. Dann brauch ich einen RailComBus (max 256 Module) der wahrscheinlich den RS-Bus obsolet macht. Dann noch einen Computer der Windows XP (alleiniges unterstütztes OS) fahren muss. Irgendwie bin ich von den Antworten nicht total überzeugt, vor allem nicht dass es nicht besser gehen könnte.
Gruß,
Harald.
Zitat
Vielleicht bin ich ja begriffsstutzig, aber gerade das Weiterverarbeiten der ausgelesenen Adresse scheint ja bei RailCom noch nicht zu laufen.
Zitat
Oder verstehe ich was falsch, geht es auch über andere Geräte?
Zitat
Wäre so etwas wie Lissy dann keine Alternative? Oder Trainnavigation von Fleischmann?
Bei Railcom kann so lange übertragen werden, wie die Lok im entsprechend überwachten Abschnitt steht.
Hallo Harald
man muss hier auch verschiedene Konstellationen berücksichtigen bzw. betrachten. Wenn z.B. schon eine vorhandene Belegtmeldung inkl. Rückmeldung vorhanden ist (egal über welchen Bus), dann brauchts den Railcom-Bus. Dieser verbindet alle Detektoren (wenn es sich um lokale Detektoren handelt). Dann wird von jedem Detektor ein entsprechender Abschnitt (oder mehrere) angeschlossen. Möchte man nur die Lokadressen anzeigen, so benötigt man lediglich noch ein Anzeigemodul. Möchte man aber die Daten in einem PC auswerten bzw. die Daten zur Steuerung der Züge mit einbeziehen, so muss natürlich noch eine Verbindung zum PC erfolgen. Diese wird dann über eine Art "Interface" an den PC weitergegeben. Im Falle Lenz wird das dann das Railcom-USB-Gateway sein.
Ist keine Belegmeldung vorhanden, so gibt es auch die Möglichkeit, Detektoren inkl. Belegtmeldung zu verbauen. Das ist besonders interessant für Neueinsteiger, die noch keine Anlage haben. Da wäre es ja Blödsinn, erst "weniger intelligente" Belegtmelder einzubauen um dann zusätzlich die Intelligenz des Railcom-Systems "aufzupfropfen".
Noch etwas Allgemeines:
Man muss auch hier, wie bei vielen anderen Dingen, ganz klar erst einmal eingrenzen, was ich mit dem System bewirken möchte. Ist es nur an bestimmten Stellen die Adresse zu übertragen? Bei Anlagen, die nicht per PC gesteuert werden, kann das schon mal von Vorteil sein, wenn man z.B. im Sbhf jede Lok bzw. Adresse auf einer Anzeige dargestellt bekommt. Dass so etwas bei größeren Sbhf (viele Gleise) auch ins Geld gehen kann, ist klar. Aber darum gehts hier ja erst einmal nicht. Im genannten Fall wären also alle Sbhf-Gleise mit einem Detektor zu überwachen.
Möchte man aber mit weiteren Daten "arbeiten", die vom System übertragen werden können (die Zukunft wird zeigen, was hier alles möglich ist), muss natürlich entsprechend mehr überwacht werden. So kann es dann sein, dass man seine ganze Anlage (alle Abschnitte) mit lokalen Detektoren überwacht. Oder aber dann über globale Detektoren alle in diesem überwachten Bereich befindlichen Daten "abrufen" kann.
Ich hoffe, ich konnte ein bisschen weiter helfen.
Gruß
Tomi
Mit eine Bidirektionale unterhaltung zwischen Anlage und Zentrale bzw. PC stelle ich mir viel mer for, als nur das die Loks sich identifizieren. Die Decodern können viele mehr Daten speichern (z.B. die Speed Profile) und bei bedarf mitteilen. Und warum eigentlich nur die Loks? Warum nicht auch die restlichen Decodern? Die Weichendekodern könnten z.B. eine bestätigung abgeben, wenn eine Weiche betätigt wurde (z.B. nach bemessung des Stromverbrauchs).
wieder vielen Dank für die Beiträge.
@ Tomi:
War auf jeden Fall hilfreich!
Interessant finde ich ja schon, dass Lenz als Lizenzgeber von RailCom dieses im Prinzip bislang kaum ausschöpfen kann (da der notwendige Detektor und der Bus fehlen), Tams das aber offenbar kann (habe mich gerade auf deren Seite informiert, scheint ja alles Notwendige vorhanden zu sein; danke noch mal für den Hinweis, hätte ich natürlich selbst schon mal schauen können).
Tomi, fährst Du denn mit RailCom, kannst Du uns mal sagen, was genau Du installiert hast??
VG, Boris.
auch wenn noch nicht alle Produkte auf dem Markt sind heißt das noch lange nicht, dass Lenz das nicht ausschöpfen kann, was da entwickelt wurde.
Mit Railcom bzw. BiDi beschäftige ich mich schon einige Zeit. Werde dazu demnächst mal einen extra Thread aufmachen, wobei ich da momentan immer etwas vorsichtig bin, da hier sehr schnell ein Thema "zerrissen" wird und dann macht das weniger Spaß.
Viele Grüße
Tomi
wäre aber echt hilfreich Tomi, wenn jemand Wissendes mal was Zusammenhängendes zu dem Thema schreiben würde. Ansonsten muss man nämlich echt in den Brocken suchen und jeder Beitrag erzeugt neue Fragezeichen, die man dann wieder klären muss.
VG, Boris.
da muss ich Boris zustimmen...
hier wurde schon oft was über Railcom geschrieben. Aber mich nervt einfach das ewige gemotze und gelästere von "Kollegen", die damit einfach noch nicht so viel Erfahrung haben bzw. sich damit nur am Rande beschäftigt haben und deshalb auch viele Dinge in Frage stellen, was sie gerne machen können. Nur von vornherein, ohne jeglichen Einblick in die Materie gleich über alles negativ urteilen, das geht mir halt auf den Senkel.
Gerne kann ich aber auf gezielte Fragen eingehen. Etwas zusammenhängendes schreiben? Da könnte ich Bücher mit füllen. Schau doch mal auf verschiedenen Internetseiten, was es da so über Railcom bzw. BiDi gibt. Auch Arnold Hübsch hat schon einiges auf seinen Seiten stehen. Wenn dazu noch weitere Fragen sind, wird hier sicher der ein oder andere noch etwas schreiben. Soweit es mir möglich ist, gebe auch ich gerne Auskunft.
Viele Grüße
Tomi
Ausserdem dachte ich, dass ich schon so einiges in @16 geschrieben habe?
wurde zwar schon beantwortet ,aber es ist so ,daß man eine Lok in einem überwachten Bereich vom Gleis nimmt und sie an anderer Stelle wieder aufs Gleis bringt ,sie sich sofort in dem neuen Bereich meldet. Es ist egal mit welcher Lok man dies tut, solange sie mit einem Railcom Plus Decoder ausgestattet ist. Der Lokpilot micro V 4.0 von Esu ist 100% zuverlässig darin.
Die Weichendecoder ( Switchpilot ) sind ebenso in der Lage eine nichtgestellte Weiche an die Ecos zu melden ( Stromflussüberwachung bei endabgeschalteten Weichen ).
Gruß Richie
Zitat
1) RailCom ist aktuell (noch) nicht in der Lage, einer Zentrale oder einem Rechner zu melden, wo sich eine Lok gerade aufhält, richtig?
2) Das heißt dann, falls das stimmt, nach wie vor muss die Zentrale oder der Rechner die eingerichteten Blockstrecken sehr gut kennen, um die Lok nach einmaliger Positionsangabe weiterverfolgen zu können?
Ich verstehe die vorzüge von RailCom nicht.
Da ich nun auf RailWare umgestiegen bin, weiß ich wie "genau" so eine Rückmeldung sein muss. Es sind deutlich weniger Rückmelder erforderlich, als manch einer glauben mag.
Wenn ich mir die ganzen RailCom Komponenten + Aufwand anguckt, dann sehe ich auch kostentechnisch kaum ein unterscheid zwischen steuerung mit PC und über RailCom.
RailCom mag vielleicht automatisch wissen, wo welche Lok aufgegleist wird, aber ob das ein Mehraufwand rechtfertigt ?
Gruß,
Basti
Ein Bekanter erzählt mir das am vergangenen Wochenende haben sie über die Normen debatiert. Hauptsächlich haben sie sich um Digitaltechnik gekümmert (Normen 6xx).
Unsere deutschen Kollegen scheinen auf Lissy und Loconet zu stehen wärend unsere französischen Nachbarn eher für RailCom sind.
Mein Fazit: wartet lieber dass die Amerikaner (NMRA) sich entscheiden und die Herstellern entsprechend handeln.
vielleicht muss man einfach mal zusammentragen was eigentlich gewünscht wird. Ziel muss sein die bestehende Technik zu vereinfachen, nicht noch zusätzliche Freiheitsgrade hinzuzufügen. Ich skizziere mal eine Idee...
Ich will eine (!!) Kiste mit 16 Anschlüsse für Blöcke dran sind, ein Anschluss für Dekoder (DCC out) und ein Netzkabel. Das Ding ist Zentrale, Booster und Rückmelder in einem und kann feststellen welche Lok auf welchem Block welche Eigenschaften hat.
PC Anbindung über WLAN, LAN oder USB. Beliebig kaskadierbar im 16er Raster. Die Slaves identische Teile. Darüber hinaus werden nur noch Weichendekoder benötigt, daran ändert sich nichts.
Mit 16 Blöcken kann ich schon eine ordentliche Anlage mit beispielsweise 4 Gleisen im Bahnhof, 8 im Schattenbahnhof betreiben. Die restlichen 4 Blöcke für Abstellgleise oder ähnliches. Mit 32 Blöcken kann man schon richtig dicke Anlagen betreiben. Darüber hinaus werden hier nur wenige kommen...
Zum Vergleich brauch ich heute dafür eine Zentrale (ca. 300 EUR) und Belegtmelder (ca. 130 EUR je 16er). Booster ist meist in der Zentrale, aber ich würde auch mal alle 16 Blöcke einen vorsehen. Da hat man doch auch preislich etwas spielraum!
Grüßle
Elvis
Das ist ja relativ. Also wenn die Rückmelder relativ billig wären (*) und ich sie einfach an den schon vorhandenen Bus (könnte man mit LocoNet) anhängen könnte wäre der Aufwand ja nicht so hoch.
> kostentechnisch kaum ein unterscheid zwischen steuerung mit PC und über RailCom
Ich glaube nicht dass BiDi/RailCom/Transponding ohne ein Computerprogram wirklich zum Tragen kommt. Da bekäme man Anmeldung des Decoders in der Zentrale und besseres PoM. Für Steuerung braucht man auf alle Fälle ein Interface vom Detektor zum Computer (direkt oder via Zentrale) und vom Computer zur Zentrale und ein "intelligentes" Program im Computer.
Tams hat auch einen eigenen Bus zwischen den Rückmeldemodulen der nach http://www.tams-online.de/htmls/download/RC-Talk-Protokoll.txt ein RS485 ist. Dann kann man nach http://www.tams-online.de/htmls/produkte/RC-Link/produkte_RC-Link.html maximal 24 RDC-2 auslesen, also 48 Blocks. Oder nur 24 wenn man die Spezifikation von RC-Talk durchliest (0xFC DD* A1* A2* 0xFF DD = Detektoradresse (0x01 - 0x18)) weil
RC-Talk nicht mehrere Blocks per Detektor kennt. Also noch etwas unklar das Ganze.
Gruß,
Harald.
(*) Bei tams sind wir bei EUR 20 / Block, bei Digitrax $30 / Block. Leider scheint man auch vor der Einführung nicht analysiert zu haben welcher Preis der Markt annimmt. Bei EUR 5 / Block wäre man bestimmt unter det Schmerzgrenze vieler. Frage ist ob die Elektronik wirklich so teuer ist oder was wir zahlen. Also ein Bar-code reader kostet $30. Wenn ich so einen einbaue wäre die Ablesung zwar nur punktuell, aber sehr billig bei den Fahrzeugen nachzurüsten. Blipp-blipp-blipp....
20 - 30 Euro PRO BLOCK ist mal häftig. DIe Uhlenbrock-RM die ich verwende kosten 60-70Euro das Stück, das bei 8 Blöcken pro Modul doch noch recht Günstig.
Ich meinte mit vergleich zur PC-Steuerung, dass man quasie ein echtes Gleisbidlstellwerk hat und diese hier mit einbaut: RailCom Adressanzeige LRC120
Ähnlich bei Lissy mit dem Gleisbildstellwerk von Uhlenbrock.
Daher der kostenvergleich. Die Module müssten sonst schon für 5 Euro rausgehen, damit man sich sowas leisten kann.
Gruß,
Basti
Hallo Elvis,
Du wirst es kaum glauben, aber genau so etwas ist bereits in der Denke und es existieren dazu schon erste Pläne. Empfehle Dir dazu mal die Seite www.opendcc.de und dann dazu das Forum.
Dort findet man auch schon, neben Blücher, einen fertig entwickelten und funktionierenden BiDi-16 Fach Rückmelder.
Gruß aus Hamburg
Thorsten
man muss aber dazu sagen, dass BiDiB nicht identisch mit Railcom ist. Aber ich bin sehr gespannt drauf, da ich die OpenDCC benutze, wär das wohl das ideale System für mich...
das stimmt, hatte ich aber auch nicht erwähnt.
Zur Zeit kann der 16-Fach BiDi-Melder von Herrn Kufer ja auch noch nicht über BiDiB melden.
Weil gibt noch keine Zentrale dafür.
Der 16-Fach BiDi-Melder von Blücher kann aber dieses schon übers Loconet melden und dort kann z.B. Traincontroller diese auch auswerten.
Gruß
Thorsten
sollte auch nur nochmal auf den kleinen Unterschied hinweisen ;)
"...Jetzt stürzt das PC-Programm ab ..." Ein gescheites PC-Program schreibt seinen Zustand regelmäßig in einen Statusfile so daß bei einem Absturz vielleicht 10 Sekunden verloren gehen. Die Programmänderung wäre wahrscheinlich billiger als BiDi.
Doch zum GBM16: Der GBM16 ist wahrscheinlich das "Produkt", dass einem reellen Bedarf am ehesten deckt. Wenn ein oder mehrere Hersteller sich zu OpenDCC bekennen würden und Produkte herausbringen.... Aber nur mit proprietärem Zeugs kann man Geld scheffeln, oder?
Gruß,
Harald.
DCC ist ein offener Standard, und damit verdienen so einige Firmen Geld. Deine letzte Aussage ist also ein wenig polemisch.
Zitat
zu OpenDCC bekennen
Wie soll sich ein Dritter zu etwas "bekennen" was er nicht selbst entwickelt hat?
Grüße, Peter W.
@Thorsten: Ja... und nein. OpenDCC ist eine Lösung, aber halt nicht für den Otto-Normal-Modellbahner!
Ich selber kann wohl schon eine OpenDCC-Zentrale mit dem Rückmelder in ein Gehäuse nageln. Ich bin aber auch ein Nerd!
Wichtig ist letzlich aber das es das fertig und erschwinglich am Tresen des Modellbahnfachhändlers geben muss. Und am besten steht da auch noch Trix/RoFl oder sonstwas drauf. Es geht um das Gesamtkunstwerk.
Denn der Kunde steht halt immer noch am Tresen und versteht Bahnhof! :o)
Grüßle
Elvis
P.S.: mal ehrlich, der Print auf SMD Basis ist schon Hardcore. Respekt! Aber das ist nichts mehr für Hobbylöter...
Siehe RedHat, SuSE etc, die packetieren und verkaufen auch die Entwicklung von anderen nachdem sie für den Verbraucher etwas Mehrwert hinzufügen (und sei es nur der Karton).
Gruß,
Harald.
Zitat
P.S.: mal ehrlich, der Print auf SMD Basis ist schon Hardcore. Respekt! Aber das ist nichts mehr für Hobbylöter...
Da sind die Baugruppen die ich in unserer SMD-Fertigung mit bearbeite meistens "grober scheiss" gegen
Aber schön mal nen abgerauchten Decoder unterm Mikroskop zu bewundern
Gruß,
Basti
moin Elvis, daher ja auch mein Hinweis auf den Blücher 16-Fach GBM mit Loconet-Interface.
Übers Loconet mit Loconetbuffer soll der schon in Zusammenhang mit Traincontroller Loknummer und Fahrtrichtung melden können.
Was Opendcc angeht, da ziehe ich auch echt meinen Hut.
Man kann kaum glauben, das Herr Kufer und einige seiner Mitstreiter das nur als Hobby machen.
. War auch nur als Hinweis gedacht das es Eigenentwicklern gelingt etwas zu entwickeln, was die "Profis" seit der Ankündigung von BiDi nicht schaffen..
Gruß
Thorsten
sehr schön, den Blücher Gleisbesetzmelder kannte ich bisher nicht:
http://www.bluecher-elektronik.de/index.php/produkte/gleisbesetztmelder/gmb16xn
Und die Kommunikation mit Rocrail scheint auch kein Problem zu sein - Rocrail ist zudem kostenlos:
http://wiki.rocrail.net/doku.php?id=bidib-de
http://forum.rocrail.net/viewtopic.php?t=3073
>>
Macht für eine Grundausstattung mit 16 Gleisbesetzmeldern, vorausgesetzt man hat eine Zentrale mit (USB-)Anschluss zum PC:
1x GBM16XN >> 148€
1x dazugehöriges LocoNet-Interface >> 19,25€
1x Rocrail >> kostenlos
Macht 10,46€ pro RailCom-überwachten Gleisabschnitt.
Oder ist da noch ein Haken bzgl. GBM16XN > LocoNet-Interface > USB-Interface > PC.
Da bin ich noch nicht ganz schlau draus geworden ...
Gruß
Ulrich
bei aller Freude über OpenDCC - aber in der FAQ http://www.opendcc.de/s88/gbm_bidi/gbm_faq.html lese ich zumindest raus, daß wegen der unklaren Lizenzsituation BiDi/RailCom eben nicht mehr unterstützt wird. Schade, muß ich sagen.
Die SMD-Platine finde ich persönlich noch ganz moderat (sowas haben wir hier auch bei handbestückten Mustern). Klar, das ist nix für das 80W Brateisen mit Netzstecker und ohne Regelung, und wer irgendwelche Handycaps hat wird da sicherlich auch seine Probleme bekommen.
Viele Grüße,
Torsten
ja, das stimmt leider. Es gibt keine offizielle Unterstützung mehr und keinen öffentlichen Support über Herrn Kufer. Verwendbar ist es trotzdem und es funktioniert.
Laut Aussagen von Herrn Kufer ist da aber wieder etwas Bewegung in die Sache gekommen und da die Lizenzen für BiDi ja kostenfrei sind sollte es in naher Zukunft wohl wieder auch offiziell unterstützt werden. Auch wenn Firma Lenz und Esu sich natürlich nicht vor Begeisterung auf die Schenkel klopfen werden. Aber wenn man einfach dann mal den Kauf von ESU und Lenz-Decodern boykotiert, kommt vielleicht Bewegung in die Sache
Auf jeden Fall gibt die werte Opendcc- Gemeinde da nicht auf. Wie heißt es doch so schön: die Hoffnung stirbt zu letzt.
Gruß
Thorsten
Zitat
Aber wenn man einfach dann mal den Kauf von ESU und Lenz-Decodern boykotiert, kommt vielleicht Bewegung in die Sache
Das mach ich bereits seit geraumer Zeit. ESU hat sich mit der miesen Regelung aus dem Rennen geworfen und Lenz durch die zu hohe Kriechgeschwindigkeit.
Zitat
Wenn ich mir die ganzen RailCom Komponenten + Aufwand anguckt, dann sehe ich auch kostentechnisch kaum ein unterscheid zwischen steuerung mit PC und über RailCom.
Die Steuerung mit dem PC schließt Railcom keineswegs aus und anders herum auch nicht.
Zitat
RailCom mag vielleicht automatisch wissen, wo welche Lok aufgegleist wird, aber ob das ein Mehraufwand rechtfertigt ?
Hallo Elvis
Zitat
Das Ding ist Zentrale, Booster und Rückmelder in einem und kann feststellen welche Lok auf welchem Block welche Eigenschaften hat.
Hallo Harald
Zitat
Also ein Bar-code reader kostet $30. Wenn ich so einen einbaue wäre die Ablesung zwar nur punktuell, aber sehr billig bei den Fahrzeugen nachzurüsten.
Viele Grüße
Tomi
Nur registrierte und eingeloggte User können Antworten schreiben.
Einloggen ->
Noch nicht registriert? Hier können Sie Ihren kostenlosen Account anlegen: Neuer N-Liste Account
Zum Seitenanfang
© by 1zu160.net;