z21 (weiß geht gar nicht mehr, weil Blücher die Produktion der X-Bus Schnittstelle eingestellt hat

Die Funktionalität ist immer an einen Rückmelder (Reailcom-Decoder) gebunden. Für diesen Rückmelder bekommt man dann halt zusätzliche Daten, vor allem die Decoderadresse.
In Deinem Fall wäre eine praktische Anwendung das Fahren mit der Z21-App. Du kannst die für die dort angelegten Blöcke (...Gleise) die Lokadresse anzeigen lassen. Im Spielbetrieb (Handbetrieb) sehr praktisch.

Im Automatikbetrieb gibt es noch andere Möglichkeiten, das würde aber hier den Rahmen sprengen. Und bei TC wird außer Lokadresse eh nichts unterstützt.

Zitat

---

Die Funktionalität ist immer an einen Rückmelder (Reailcom-Decoder) gebunden.

---

Das stimmt nicht. Man kann Railcom auch nutzen wenn man keine Railcom fähigen Rückmelder hat. Railcom Rückmelder bieten zusätzliche Funktionalität. Grundvoraussetzung ist das es die Zentrale und die Decoder unterstützen. Wobei Decoder ohne Railcom natürlich weiter eingesetzt werden können.

Zitat von bernd46 im Beitrag RailCom, RailComPlus oder doch ohne?

---

So: Was kann das? was kann ich dann? oder braucht man dann noch einen railcomfähigen Belegtmelder?

---

Zitat

---

Das stimmt nicht. Man kann Railcom auch nutzen wenn man keine Railcom fähigen Rückmelder hat. Railcom Rückmelder bieten zusätzliche Funktionalität. Grundvoraussetzung ist das es die Zentrale und die Decoder unterstützen. Wobei Decoder ohne Railcom natürlich weiter eingesetzt werden können.

---

Dann ist aber die einzig verfügbare (extra-) Funktionalität POM-Lesen. POM Schreiben geht auch ganz ohne Railcom.

Hallo Flo,

Zitat

---

Zitat

---

Die Funktionalität ist immer an einen Rückmelder (Reailcom-Decoder) gebunden.

---

Das stimmt nicht. Man kann Railcom auch nutzen wenn man keine Railcombelegtmelder hat.

---

Hier war ganz konkret nach der z21 oder Z21 gefragt!
Der Beitrag "es gehe doch" verwirrt den Fragesteller.
Keine von beiden hat meines Wissens einen (globalen) Detector eingebaut (meine hat jedenfalls keinen nutzbaren!). Also gibt es - zumindest derzeit - keine z/Z21-Lösung, um ohne weitere externe Geräte, mit den Railcomnachrichten irgendetwas anzufangen, insbesondere auch kein POM-Lesen!

MfG

vik

Edit vik: 16.02. meine Z21 hat einen globalen Detector und der läßt sich auch sinnvoll nutzen, sorry mein Anwenderfehler! POM-Lesen geht also ohne Zusatzgeräte!

Zitat

---

In Deinem Fall wäre eine praktische Anwendung das Fahren mit der Z21-App. Du kannst die für die dort angelegten Blöcke (...Gleise) die Lokadresse anzeigen lassen. Im Spielbetrieb (Handbetrieb) sehr praktisch.

---

Laut Roco (Herr Köhler) soll in der übernächsten Version der Z21-APP auch die Aufgleisrichtung dargestellt werden können.

Bisher kann in Verbindung der Z21 (schwarz) z.B. mit dem Blücher oder dem Roco 10808 in der z21-APP nur die DCC-Adresse neben einem Blockmeldersymbol angezeigt werden.

MfG

vik

Zitat

---

Also gibt es - zumindest derzeit - keine z/Z21-Lösung, um ohne weitere externe Geräte, mit den Railcomnachrichten irgendetwas anzufangen, insbesondere auch kein POM-Lesen!

---

Doch; die z21 und Z21 beherrschen POM-Lesen, schon immer. Die Funktionalität ist aber sehr instabil, mehr als 3 Loks und ein paar Weichendecoder am Gleisbus, dann geht da auch nichts mehr.

Zitat

---

Bisher kann in Verbindung der Z21 (schwarz) z.B. mit dem Blücher oder dem Roco 10808 in der z21-APP nur die DCC-Adresse neben einem Blockmeldersymbol angezeigt werden.

---

richtig, das ist schon lange so, und es wird langsam Zeit daß sich mal wieder etwas tut.
noch zu ergänzen: mit dem Blücher GBM und der X-Bus Schnittstelle ging es sogar an der z21 (weiß)

Zitat

---

Die Funktionalität ist aber sehr instabil, mehr als 3 Loks und ein paar Weichendecoder am Gleisbus, dann geht da auch nichts mehr.

---

Wenn man Railcom, vor allem den globalen Detector, verwenden will, kommt man, ausser vielleicht bei einer kleinen Spielbahn, nicht darum herum auch die Anlagenverdrahtung und andere Verbraucher (am Gleis) dementsprechend anzupassen. Man muss dann dafür sorgen das Verbraucher während des Cut-Out gepuffert sind und nicht (zu viel) Strom vom Rückmeldsignal absaugen. Schließlich müssen die Decoder ja das Rückmeldesignal mit gepufferter Energie aus einem Kondensator treiben.

Hallo Ulf,

Zitat

---

Doch; die z21 und Z21 beherrschen POM-Lesen, schon immer. Die Funktionalität ist aber sehr instabil, mehr als 3 Loks und ein paar Weichendecoder am Gleisbus, dann geht da auch nichts mehr.

---

Das ist spannend, das hat bei mir noch nie funktioniert! Offensichtlich habe ich das immer falsch gemacht.
Wie kann ich genau testen?

Bei Z21 mit Roco 10808 und Railcom fähige Lok auf Hauptgleis hinter Roco 10808 kann ich die CVs auslesen.

Jetzt lasse ich das Roco 10808 weg, stelle die Lok direkt auf das Gleis am Main-Ausgang der Z21.
Sonst keinen weiteren Verbraucher. Also quasi ein POM-Programmiergleis!
Wie kann ich mir die CVs anzeigen lassen?

MfG

vik

Zitat

---

Jetzt lasse ich das Roco 10808 weg, stelle die Lok direkt auf das Gleis am Main-Ausgang der Z21.
Sonst keinen weiteren Verbraucher. Also quasi ein POM-Programmiergleis!
Wie kann ich mir die CVs anzeigen lassen?

---

mit dem Maintenanece Tool
auf CV-Programmmierung, dort auf POM

Oder POM Programmierung mit multiMAUS / WLANmaus.


Klaus

Zitat

---

Zitat

---

Jetzt lasse ich das Roco 10808 weg, stelle die Lok direkt auf das Gleis am Main-Ausgang der Z21.
Sonst keinen weiteren Verbraucher. Also quasi ein POM-Programmiergleis!
Wie kann ich mir die CVs anzeigen lassen?

---

mit dem Maintenanece Tool
auf CV-Programmmierung, dort auf POM

---

Maintenance Tool hat definitiv bisher nie geklappt, zumindest nicht mit meiner Z21 und mit meiner Anlage dran. Aber ich werde das mal solo als POM-Programmiergleis ausprobieren...

MfG

vik

Zitat von vikr im Beitrag RailCom, RailComPlus oder doch ohne?

---

unabhängig davon, dass der DR5088RC hinsichtlich der Stromfühlereigenschaften meines Erachtens eine Design-Schwäche hat, glaube ich dass es einen Workarround geben müßte, um den Stromverbrauch eines Fahrzeuges immer über die mminimale Nachweis-Schwelle von 10mA zu bekommen,

---

Zitat von schoobi im Beitrag RailCom, RailComPlus oder doch ohne?

---

Vielleicht ändert ja Digikeijs irgendwann nochmal das Design der Melder (bis dahin habe ich aber vermutlich schon andere gekauft).
Was ich halt nicht verstehen ist: Warum meint Digikeijs, nur mit dieser hohen Auslöseschwelle von 10-15mAh die Railcomspezifikation einzuhalten wenn es Fichtelbahn, ESU und Roco auch anders schaffen? Hat da Digikeijs was falsch verstanden oder halten sich die anderen drei nicht an die Spezifikation? Aber deren Melder funktionieren ja offenbar auch einwandfrei und machen bei Railcom keinerlei Probleme.

---

Zitat von vikr im Beitrag RailCom, RailComPlus oder doch ohne?

---

Also zumindest ergunov interpretiert die Anforderungen zu eng. Diese Auslöseschwellen gelten nur während der Lücke, also solange beide Schienen vom Leistungsteil getrennt sind, lediglich die Detektoren an den Gleisabschnitten hängen, die Decoder gerade senden und deren Strommodulation detektiert werden soll. Außerhalb der Lücke gelten die Vorgaben nicht.
Der Detektor muss vermutlich in der Lücke - zum Strom fühlen - eine etwas andere Messanordnung nutzen, als zur Decodierung des aufgeprägten Stromsignals in der Lücke und dauernd zwischen beiden umschalten.

---

Zitat von vikr im Beitrag RailCom, RailComPlus oder doch ohne?

---

die Blücher Hardware ist immer noch die beste und die einzige,

---

Zitat

---

Yes, we only take into account one fact, Blücher works only with Channel 1, and nothing counts except the address and direction.
And the transfer of long addresses is not possible in principle.

---

letzteres ist falsch, lange Adressen funktionieren natürlich

Zitat

---

Florian you forget the cost factor, the DR5088 unit is two times cheaper than the Roco. And the cost of ownership of the bundle DR5000 / DR5088 differs from the Z21 / Z21detector by more than two times.

---

Yes, quality costs......

The only reason why Digikeijs have success is because they are so cheap.
If you look at this forum, most of the problems people have is because they wanted to save money and purchased Digikeijs products!


Klaus

Zitat

---

Hello vik
The threshold of 10 mA is not such a terrible drawback, it is relevant primarily for the N scale. At the same time, you miss the important fact that the cost of one input, for DR5088 it is only 5.3 euros per input, compare with 11.3 for Z21 detector. Moreover, even in a pair of DR5088/DR4088, the cost of entry will be lower.

Florian you forget the cost factor, the DR5088 unit is two times cheaper than the Roco. And the cost of ownership of the bundle DR5000 / DR5088 differs from the Z21 / Z21detector by more than two times.

---

Hallo ergunov (ich antworte dir mal auf Deutsch damit auch diejenigen mitlesen können die kein Englisch verstehen),

doch, die mehr als 10mA sind ein schrecklicher Nachteil! Und es ist eben nicht nur für Spur N relevant sondern auch für Spur H0. Ich habe doch oben die Stromverbräuche gegengerechnet, der DR5088RC verbraucht mehr als 18 mal soviel wie die Konkurrenzprodukte.
Erst gestern Abend hatte ich wieder eine heftige Kollision auf der Anlage weil eine richtig fette Lok (Piko 221 mit Zimo MX630) nicht erkannt wurde. Und die braucht nicht gerade wenig Strom.

Es ehrt dich ja, dass du den DR5088RC verteidigst aber für mich ist er der teuerste Melder auf dem Markt. Warum? Weil ich die Kosten für kaputte Loks, die jetzt schon zwei Mal auftraten, mit in die Anschaffungskosten rein rechne. Was nützt mir das billigste Modul wenn ich dauernd Kollisionen habe? Das ist doch Mist.
Und wenn ich den DR5088RC mit einem DR4088CS kombiniere (was du auch schon in einem anderen Thread vorgeschlagen hast) ist der DR5088RC der mit Abstand teuerste Belegtmelder auf dem Markt. Dann kann ich gleich auf ein anderes System setzten (zumal der Verkabelungsaufwand dann echt gruselig wird).

Ich jedenfalls bin seit gestern Abend endgültig kuriert und baue den DR5088RC umgehend aus, mir wird das zu unicher und zu teuer.

Ach und wegen der Railcomspezifikation: Ich glaube nicht, dass ausgerechnet BIDIB dagegen verstößt, und deren Melder sind wesentlich empfindlicher.

Viele Grüße
Florian

Zitat

---

Zitat

---

Also quasi ein POM-Programmiergleis!
Wie kann ich mir die CVs anzeigen lassen?

---

mit dem Maintenanece Tool
auf CV-Programmmierung, dort auf POM

---

Hallo Ulf, hallo Flo,
habe das noch mal eingerichtet und getestet:
1. Ein einziges Gleis am Main-Gleisanschluss der Z21.
2. eine Lok mit Railcom fähigem Decoder
3. Lok läßt sich mit eingebautem Lokfahrpult fahren.
4. Menu CV Programmieren, Einstellung: DCC-POM Lokdecoder.
5. Versuch zu Lesen: Kann CV xx nicht lesen. Result=NACK!
6. korrekte DCC- Adresse eingegeben, CV 28 eingegeben, Bit 0 und 1 gesetzt und mit Schreiben (blind) POM programmiert.

Jetzt klappt es. Tja, wenn man Kanal 2 meistens bei seinen Decodern ausgeschaltet hat, braucht man sich nicht zu wundern, wenn POM Lesen auch i.d.R. nicht funktioniert. ops:

Danke, das Problem saß vor meiner Z21! Der Thread war für mich jedenfalls sehr hilfreich. Nochmals vielen Dank an Ulf, Flo und Moppe!

MfG

vik

Zitat

---

The Florian threshold of 10mA is not taken from the ceiling, this is the minimum value for RailCom according to standard RCN-217.
The design of the other blocks seems to contain two independent detectors in one block, the first for RailCom, the second just current sensors, Digikeijs went the way of cheapening.

---

Hallo ergunov,

ich habe mir jetzt tatsächlich mal die RCN-217 angesehen. Wo genau steht denn dort dass der Belegtmelder erst ab 10 mA auslösen darf?
Es geht in der RCN-217 ausschließlich (so wie ich das jetzt auf die Schnelle sehe) um die Railcom-Lücke. Und damit ausschließlich um die Railcomdetectoren. Gleich im Kapitel 2.3 geht es um die entsprechenden Ströme.
Es geht in der RCN-217 NICHT um die Belegtmeldung.

Somit hat vik mit dem was er weiter oben schrieb Recht: Ein kombinierter Railcomdetector mit Belegtmelder kann so empfindlich sein wie er will, nur innerhalb der Railcomlücke darf er die 10 mA nicht unterschreiten. Er muss also immer hin und herschalten.
So machen es offenbar auch die anderen Hersteller.

Du schreibst "Digikeijs went the way of cheapening". Man hat sich offenbar zur Preisreduzierung genau dieses so wichtige Umschalten gespart.

Generell finde ich es ja gut wenn ein Hersteller versucht, auch für die Leute mit weniger Geld günstige Produkte zu entwickeln. Aber er darf doch dabei nicht an der absolut wesentlichen Funktion so sehr sparen, dass sie unzuverlässig wird. Dann war das doch sparen am falschen Ende.

Der DR5088RC ist eigentlich ein toller Baustein auf den sicher nicht nur ich lange gewartet habe. Umso enttäuschender ist leider das Resultat. Lieber auf irgendeinen anderen Schnickschnack verzichten als auf die elementaren Funktionen.

Viele Grüße
Florian

Hallo Bernhard (bernd46),

Zitat von bernd46 im Beitrag RailCom, RailComPlus oder doch ohne?

---

Ein Gleisoval, angeschlossen an eine Z21, gesteuert mit Multimaus (oder z21 App), eine Lok mit Railcomfähigen Decoder - bei der natürlich die entsprechenden CV aktiviert sind - .
So: Was kann das? was kann ich dann? oder braucht man dann noch einen railcomfähigen Belegtmelder?

---

Florian, I’ve been using DR5088 for more than 2 years and I haven’t had any problems with it, as I understand you are using DR5088 not with DR5000, maybe this is the problem?
The DR5088 has a lot of tweaks that can help with issues, of course, apart from sensitivity.

And while reading the topic, I see a lot of misconceptions, I propose to stipulate some points once and for all.
1. There is a standard for RailCom and this is a fact.
2. The problem of operation of equipment of different companies does not depend on the RailCom standard. The problem is in the data buses, and which of the features of the same LocoNet manufacturers are laying in their devices.
3. "Honest" POM when writing and reading CVs is possible, is possible only using RailCom.
4. The Z21 / z21 stations have sensors allowing reading RailCom data, their address is 10000.

Hello vik, you are not quite right.
Let's figure it out.
1. Blucher is not as good as you say, maximum currents of 10A per input are very redundant. Work only with Channel 1, and the incomplete implementation of the standard will also be taken into account, the impossibility of transmitting information other than the address, the POM not working, the inability to detect more than one locomotive on the block.
2. The OPC_MultiSenses message format is indeed developed by Blucher, but they are fully licensed by Digitrax as part of the LocoNet protocol, which means they are standardized and available to all LocoNet licensees.
3. Digikeijs developed its DR5088 itself, without regard to other manufacturers. In addition, they created and licensed OPC_MultiSenses_Long packages, in which the restrictions on transferring directions were resolved.
4. The threshold of 10 mA is not so small, all of my locomotives, as well as wagon with decoders, can be found without any problems.

Hallo ergunov,

Zitat

---

as I understand you are using DR5088 not with DR5000, maybe this is the problem?

---

Das Problem, dass der DR5088RC ein Fahrzeug mit geringem Stromverbrauch nicht, oder nicht mehr erkennt und meldet, tritt nach meiner Erfahrung sowohl mit der DR5000, als auch mit der Z21 oder standalone (USB) auf.

MfG

vik

Zitat

---

Das Problem, dass der DR5088RC ein Fahrzeug mit geringem Stromverbrauch nicht, oder nicht mehr erkennt und meldet, tritt nach meiner Erfahrung sowohl mit der DR5000, als auch mit der Z21 oder standalone (USB) auf.

---

vik do you have a DR5088RC?
You had problems with detection personally, on what scale, with which locomotives?

Zitat

---

Florian, I’ve been using DR5088 for more than 2 years and I haven’t had any problems with it, as I understand you are using DR5088 not with DR5000, maybe this is the problem?
The DR5088 has a lot of tweaks that can help with issues, of course, apart from sensitivity.

---

Hallo Ergunov,

was genau hat jetzt die Intellibox II, die ich mit dem DR5088RC nutze, damit zu tun, dass der Melder einfach oft nicht auslöst? Das ist doch kein Bus- oder Kommunikationsproblem. Railcom ansich geht doch einwandfrei, also Adressmeldung in Channel 2 und Auflgeisrichtung. Wenn du in zwei Jahren keine Probleme hattest war das ganz einfach Glück. Deine Loks scheinen mehr Strom zu verbrauchen als einige, die ich nutze. Das gönne ich dir ja auch und stelle das überhaupt nicht in Frage. Aber dann glaube du mir doch bitte auch das es bei mir nicht immer funktioniert.

Bis jetzt werden folgende zwei Loks im Stand nicht erkannt (Spur H0):
Lenz Köf II Artikelnummer 30151-01 (Decoder Lenz mini Gold mit USP)
Piko 221 Artikelnummer 52602 (Decoder Zimo MX637P22)

Zitat

---

And while reading the topic, I see a lot of misconceptions, I propose to stipulate some points once and for all.
1. There is a standard for RailCom and this is a fact.
2. The problem of operation of equipment of different companies does not depend on the RailCom standard. The problem is in the data buses, and which of the features of the same LocoNet manufacturers are laying in their devices.
3. "Honest" POM when writing and reading CVs is possible, is possible only using RailCom.
4. The Z21 / z21 stations have sensors allowing reading RailCom data, their address is 10000.

---

Zu Punkt 1: Genau, das ist Fakt. Und Stand jetzt ist es für mich so, dass sich Digikeijs als einziger nicht daran hält bzw. es falsch interpretiert. Ich mache mir doch auch die Mühe als Laie die RCN-217 zu verstehen und habe dich gebeten, mir die Stelle zu zitieren, in der steht, dass der Belegtmelder nicht empfindlicher sein darf als 10-15 mA. Vielleicht irre ich mich ja auch, aber wo genau steht das? Ich sehe in der RCN-217 nur in einem Kapitel Hinweise auf die Stromstärken. Und zwar in Kapitel 2.3 (habe die RCN-217 jetzt komplett durchgelesen). Dort steht , dass während des Cutout mehr als 10 mA als eine 0 und Ströme von weniger als 6 mA als eine 1 erkannt werden. Es bezieht sich aber ausschließlich auf den Cutout. Was außerhalb dessen passiert wird in der RCN-217 überhaupt nicht spezifiziert. Ergo der Belegtmelder darf außerhalb des Cutout so empfindlich sein wie er will.

Im Übrigen sind wir hier mit den Problemen ja nicht allein. Lese dich mal durch das Spur N forum 1zu160. Dort wurde genau diese Unempfindlichkeit schon viel früher thematisiert. Dort wird sogar geschrieben, dass der DR5088RC als Belegtmelder völlig untauglich ist. Der DR5088RC wird ja spurneutral verkauft, sollte also auch bei den kleinen Spuren funktionieren. Leider merkt man erst hinterher was man sich da eingebaut hat wenn es das erste mal auf der Anlage scheppert.

Wir drehen uns hier im Kreis. Um das zu ändern zitier doch mal bitte die entsprechende Stelle in der RCN-217 mit den 10 mA bei Belegtmeldung, gerne auch in Englisch. Mich interessiert das jetzt sehr, schließlich möchte ich Digikeijs ja auch kein Unrecht antun.

Viele Grüße
Florian

Zitat

---

vik do you have a DR5088RC?
You had problems with detection personally, on what scale, with which locomotives?

---

Ja, 2018 hatte ich auf einer Ausstellung im Lokschuppen Erkrath eine N-Testanlage, bei der es mit DR5000 und DR5088RC immer wieder zum "Verschwinden der Loks" kam, die mit einem DR5088RC detektiert wurden. Den DR5088 habe ich immernoch, auch mit aktueller Firmware.

Zu den Fahrzeugen die regelmäßig verschwanden oder nach Einschalten der Gleisspannung gar nicht erst auftauchten gehörten auch Wagen mit Schlußbeleuchtung und Railcom fähigem Funktionsdecodern.

Ich habe dann auch unsere H0-Fahrzeuge systematisch untersucht und bei den kleinen leichten Fahrzeugen mit Faulhabermotor und natürlich den Wagen mit Funktionsdecodern, dieselben Beobachtungen gemacht. Die Belegtanzeige verschwand sporadisch.

Der besondere Charme des DR5088 ist seine universale Nutzbarkeit als eigenständige Rückmeldezentrale durch den eingebauten LocoNet-Buffer. zum Anschluss an den PC

Dadurch könnte der DR5088RC jedem nahe gelegt werden, der die Lücke erzeugen kann und Erfahrungen mit Railcom machen will. Er braucht nur noch einen PC.

Ich würde mir einen Nachfolger für den DR5088RC wünschen, der
1. eine Belegtmeldung bei 1mA oder weniger beherrscht,
2. noch schneller melden kann,
3. eine eingebaute galvanische Trennung am USB-Bus besitzt,
4. jeweils eine zwei-farbige LEDs für jeden Kanal zur Anzeige von Belegtmeldung/Railcomnachricht hat.

MfG

vik

Ok Florian.
If you do not understand the difference between 0 and 1, it will be difficult for me to tell you about this.
Let's try - "0" is the lack of data, "1" is the availability of data, if we lower the current below 10 mA, this bulette is perceived as "1", which implies that at this time information should come, but it does not. So this situation can cause a violation of integrity.
There is a solution, installing current sensors in parallel with RailCom sensors, but this makes the unit more expensive and complicates the circuit and firmware.

Vik, I understand you.
Personally, I have not experienced problems with the DR5088RC, but I do not exclude that they may be.
According to your wishes, I would also like to have such blocks. Perhaps Digikeijs will someday make them, but for this a number of conditions must be fulfilled. Manufacturers of command stations with LocoNet protocol fully implement the OPC_MultiSenses and OPC_MultiSenses_Long packages in them. Software makers will stop looking at RailCom askew.
RailCom will receive a much more well-deserved understanding from modellers. In general, demand is needed, and demand requires conditions, but none of this is available yet, but it's a pity.

Zitat

---

Ok Florian.
If you do not understand the difference between 0 and 1, it will be difficult for me to tell you about this.

---

Naja Ergunov, das ist ja schon fast ein bisschen frech was du schreibst. Wie kommst du darauf, dass ich den Unterschied zwischen 0 und 1 nicht kenne? Ich habe nur geschrieben, was in der RCN-217 steht (die du ja selbst immer als Quelle angibts) und wollte von dir wissen, wo in der selben Dokumentation steht, dass der Belegtmelder nicht empfindlicher als 10 mAh sein darf außerhalb des Cutout. Ich findes es nämlich nicht, und auch jetzt hilfst du nicht weiter.

"if we lower the current below 10 mA, this bulette is perceived as "1", which implies that at this time information should come, but it does not"
Genau, nichts anderes habe ich geschrieben. Aber eben nur währen dem Cutout, nicht davor und nicht danach. Außerhalb des Coutput erwartet die Zentrale überhaupt keine Railcomnachrichten, also ist doch der Strom egal, oder nicht?

Du stellst hier Behauptungen auf ("Fakt", "Standard") aber lieferst nie den Beleg dazu. Ich versuche es wenigstens und versuche zu verstehen, was in der RCN-217 steht. Ich bin kein Elektroniker, nur ein dummer Seemann der in Mathe nicht gut aufgepasst hat. Offenbar ist Railcom (zumindest die Details) doch nur was für Freaks und ich kapier es nicht. Tatsache ist, alle Hersteller außer Digikeijs können es. Warum ist mir inzwischen auch egal.

Interessant ist aber, dass du vik verstehst und ihm glaubst, das es nicht immer klappt, mir aber nicht. Und du bestätigst vik in dem Wunsch nach einem Nachfolgemelder mit den entsprechenden Verbesserungen. Wie geht das? Ich denke man kann die Empfindlichkeit nicht verbessern ohne die RCN-217 zu verletzten.

Ich bin dann jetzt hier raus und gehe Eisenbahn spielen. Das ist mir dann doch zu dumm. Eventuell reden wir auch aneinander vorbei.

Viele Grüße
Florian