[Dreispur]

Hallo !
Wenn man neu Beginnt und man RailCom , Railcom+ in Erwägung zieht sollte man auch alle Komponete darauf abstimmen .
Bedeutet Lokdecoder insbesonders die das verstehen sowie Rückmelder .
Natürlich auch die Centrale . Eine Software die das auswertet kann .
Eine Astreine Komposition .
Da wird es dann preislich nicht billig werden .
Es ist vieles angeführt worden , das es zu Störungen kommen kann und man nicht alle kostengünstige Sachen nehmen kann weil eben kein Railcom .
Hr. Vinc hat es schon vorab gut Fragen gestellt was dir wichtig ist .

Wie groß soll die Anlage werden ? Länge , Breite , Ebenen , Einzelspieler ?

Kann durchaus sinnvoll sein " normal " zu steuern und dafür eine gute MOBA Steuerung . Sollten dann einige Railcom Komponente Störungen bereiten kann man es ausschalten .

[Pirat-Kapitan]

Zitat

---

Damit müssen, vor allem Geschwindigkeitsbefehle, nicht auf Verdacht direkt öfter wiederholt werden um einen Empfang sicher zu stellen. Das spart Bandbreite am Gleis.

---

Moin,
weiss das auch die Zentrale und verzichtet auf entsprechende Wiederholungen?
Ich habe da in den Bedienungsanleitungen nichts Entsprechendes gefunden.

Schöne Grüße
Johannes

[StephanLeist]

Hallo in die Runde,

Zitat

---

Ein Vorteil vom Railcom mit Software ist mir noch eingefallen: Die Decoder quittieren den Erhalt vom Befehlen. Damit müssen, vor allem Geschwindigkeitsbefehle, nicht auf Verdacht direkt öfter wiederholt werden um einen Empfang sicher zu stellen. Das spart Bandbreite am Gleis.

---

Das ist interessant. Lese ich zum ersten mal, dass Railcom den Daten-BUS am Gleis entlastet. Ist das wirklich so?
Für das Bestätigen einer erfolgreichen Programmierung bedarf es übrigens keiner Railcom-Technik. Dafür reicht z.B. auch das Aufblinken des Spitzenlichts der programmierten Lok. Damit quittiert der Decoder den erfolgreichen Empfang sowie die Programmierung der darin enthaltenen Befehle.
Sollte es zu einer Störung kommen kann man das also sehen.

Ich gebe zu das ist nicht perfekt aber das Argument man programmiere im Blindflug bei POM ohne Railcom stimmt so pauschal einfach nicht.

Programmiert man mehr und aufwändiger, nehmen sich die meisten sowieso ein extra Gleis und nutzen dann auch komfortable Programmiersoftware. Da braucht es auch kein Railcom.

So "toll" Railcom auch sein kann, so ist der Nutzen der Decoder-Rückmeldung für DCC-Fahrer in vielen Punkten doch überschaubar und man sollte dann auch immer den Kontext (Mehraufwand, Kosten) sehen.
Sehr wahrscheinlich, dass bei einer Kosten vs. Nutzen Betrachtung, wie von Vinc angesprochen, die Kosten deutlich überwiegen.

Ich persönlich habe mit Railcom gemischte Erfahrungen gemacht. Das ist auch der Grund, weshalb ich mich nicht vollends dafür entschieden habe. Auch in meinem Umfeld gibt es nicht wenige Beispiele, die durch Railcom mit Problemen zu kämpfen hatten und es deshalb in ihrer Zentrale deaktiviert haben.

Allgemein möchte ich aber sagen ...
Die Idee und der Gedanke die Kommunikation zu den Decodern bidirektional zu haben, finde ich vom Grundsatz her toll und erstrebenswert. Nur fehlt mir der Glaube daran, dass es sich auf lange Sicht gesehen für das DCC-Protokoll durchsetzt. Ich befürchte eher, und das haben hier einige Vorredner auch schon anklingen lassen, dass es entweder einen technischen Bruch gibt, sodass man in einigen Jahren gezwungen ist neue Hardware zu kaufen, und/oder es herstellerbedingte Unterscheidungen gibt. Letzteres kann man heute schon teilweise mit Railcom+ sehen.

In Sachen bidirektionaler Kommunikation über die Schiene ist das letzte Wort noch lange nicht gesprochen.

[Flo_85]

Zitat

---

Moin,
weiss das auch die Zentrale und verzichtet auf entsprechende Wiederholungen?

---

Zitat

---

Das ist interessant. Lese ich zum ersten mal, dass Railcom den Daten-BUS am Gleis entlastet. Ist das wirklich so?

---

Das hängt von der Programmierung der Zentrale ab und wie die Daten am Gleis priorisiert werden. Da wird kein Hersteller Einblick geben. Bei openDCC gibt es Infos zu diesen Aknowledgement Messages bei Railcom. Ob sie der Hersteller der Zentrale nutzt ist eine andere Sache.

Die Anleitung hilft da nicht, die großen Zentralenhersteller werden dazu nichts erwähnen. Sowas findet man höchsten bei offenen Projekten. Oder man macht groß angelegte Testreihen um die Effizienz einer Zentrale zu testen, wie etwa in der Miba Digital Extra 2018.

Und noch eines ist klar: Bei nur 4 oder 5 gleichzeitig fahrenden Zügen hat das keine Relevanz.

[Ulf325]

Zitat

---

Das ist interessant. Lese ich zum ersten mal, dass Railcom den Daten-BUS am Gleis entlastet. Ist das wirklich so?

---

das ist Railcom Kanal 2 - Bestandteil von Railcom+
wird leider nur ganz ganz selten unterstützt, ich denke ernsthaft nur innerhalb des BiDiB Projektes

[ergunov]

Hi Olaf
Finally, there was someone who is interested in the Railcom theme at stummiforum
I have been working with Railcom since 2017, I was one of the digikeijs DR5088RC beta testers. I can say with confidence that I know a lot about the topic.
Judging by the messages in this thread, here many simply did not have any practice with Railcom, a lot of absolutely incorrect information, I am ready to share everything that I know, but only in English.

Here's an example of this post.

Zitat

---

Harte Fakten:
- Railcom(+) ist (noch) kein genormter Standard
- Railcom benötigt bestimmte Hardware
- Railcom wird nicht von allen Herstellern die es anbieten in gleichem Umfang umgesetzt
- Railcom verlangt nach strikter Konsequenz bei der Verwendung und Zusammenschaltung von Hardware, sonst zahlreiche Probleme möglich
- Railcom ist nicht zwingend für POM nötig, jedoch für das Auslesen der Decoder auf dem Hauptgleis
- Es ist nicht absehbar wie und in welche Richtung sich Railcom in Zukunft entwickelt
- Railcom benötigt zusätzliche Komponenten deren Kosten abhägig von der Anlagengröße enorm werden können (Kosten vs. Nutzen)
- Railcom kann unangenehme Nebeneffekte haben, auch bei vollständig korrekter Anwendung und Implementierung (z.B. Fiepen mancher Decoder)

Weiche Fakten:
- Railcom musste ins Leben gerufen werden, damit die veraltete Technik des DCC-Protokolls und der DCC-Übertragungslogik in Zukunft noch Konkurenzfähig ist ( --> vgl. hierzu auch was ESU darüber auf deren HP schreibt)

- Railcom ist nur durch einen - ich nenne es einmal - technischen Kniff möglich, wodurch sich die Möglichkeit einer Antwort des Decoders im Betrieb in das bestehende DCC-Protokoll einfügt. Dadurch sind die Möglichkeiten von Railcom schon heute klar limitiert und eine richtige bidirektionale Kommunikation unmöglich. Es ähnelt eher bspw. einer I²C-Bus-Übertragung, halb-duplex im Master-Slave-Betrieb, wenn dir das etwas sagt.

- Der persönliche Nutzen von Railcom ist selbsverständlich von deinen persönlichen Vorlieben/Vorstellungen, was den Moba-Betrieb angeht, abhängig.

---

Railcom is standardized and even in two standards:
NMRA S-9.3.2 (currently the standard is outdated and needs to be reviewed)
RCN-217 is the current working standard.

Railcom and Railcom Plus are one and the same, the Plus version was made by ESU for ECOS for automatic registration of the locomotive in the station, the requirements in the Railcom Plus version are already included in the RCN-217.

RailCommunity, as the creator of RCN standards, unites almost all the leading European manufacturers, so RailCom is also considered an industry standard by RCN-217.

POM mode is virtually impossible without RailCom.

There are problems with hardware and software from different manufacturers, but many are solved.

[aftpriv]

Hi Ergunov
I would bei very interested what in the past the hardware problems have been and the solutions to it.
English ist no Problem
Best regards from Germany
Alf
If you want to explain in private write to: LedLib@yahoo.com

[ergunov]

Hi Alf I think it’s better to lead the main discussion here.
In personal communication it is better to solve specific issues.

Everyone who is interested in feedback from the actual use of RailCom, I propose to make a list of basic questions. I will answer everything.

[Instandsetzung]

Ähem . . . Hallo,

Zitat

---

Zitat

---

Ich selber fahre mit dem Train Controller auf mehreren Anlagen und wir haben nirgendwo RailCom - denn wir brauchen es nicht.
Im Train Controller Forum ist auch hier und da zu lesen, daß Leute, die RailCom benutzen, Probleme haben.

---

Was auch kein Wunder ist, denn Herr Freiwald weigert sich hartnäckig Railcom überhaupt zu unterstützen. Wie soll es da auch funktionieren.

---

Und die Erde ist eine Scheibe . . . ? ? ?

Oliver

[MobaVinc]

Hi Ergunov,

I am sorry for the things I didn't know well enough.

It is true that Railcom is a normed standard, I didn't konw that exactly.
Well, but the norming here refers to the technical implementation - on the lower OSI layers if you like so.

The Railcom hardware you can get on the market not always does support Railcom in the same extent. There are several differences on the available hardware although the Railcom sign is printed on.
Ultimately, the Railcom standard serves as the basis for Railcom to function in principle. In practice, for users things look different for different manufacturers.


Here an excample of what you wrote

Zitat

---

Railcom and Railcom Plus are one and the same, the Plus version was made by ESU for ECOS for automatic registration of the locomotive in the station, the requirements in the Railcom Plus version are already included in the RCN-217.

---

So, please tell me: If I want to buy hardware because I'd like to use Railcom+, from which manufacturer can I get it? Why is there a distinction between Railcom and Railcom+ when it's all the same? Again, you refer to the technical part of Railcom, the lower OSI-layers. (like it is written in tech.doc. NMRA S-9.3.2 --> physical layer, packet layer ...)
But for the user practically there is a big difference between Railcom+ and Railcom - the costs on the one hand, the needed hardware components on the other hand.
So, your view on Railcom might be correct but not the truth for the end user.

Zitat

---

There are problems with hardware and software from different manufacturers, but many are solved.

---

This also might be true, but how many problems are left and how many will come in future?
At least your statement is so honest and admits that there have already been many problems that need to be addressed and which had been solved..

Zitat

---

I have been working with Railcom since 2017, I was one of the ...

---

So, I can really understand that for you Railcom draws a different picture.

Zitat

---

Harte Fakten:
- Railcom(+) ist (noch) kein genormter Standard not right
- Railcom benötigt bestimmte Hardware completly true
- Railcom wird nicht von allen Herstellern die es anbieten in gleichem Umfang umgesetzt completly true
- Railcom verlangt nach strikter Konsequenz bei der Verwendung und Zusammenschaltung von Hardware, sonst zahlreiche Probleme möglich completly true
- Railcom ist nicht zwingend für POM nötig, jedoch für das Auslesen der Decoder auf dem Hauptgleis not wrong
- Es ist nicht absehbar wie und in welche Richtung sich Railcom in Zukunft entwickelt maybe you know it?
- Railcom benötigt zusätzliche Komponenten deren Kosten abhägig von der Anlagengröße enorm werden können (Kosten vs. Nutzen) completly true
- Railcom kann unangenehme Nebeneffekte haben, auch bei vollständig korrekter Anwendung und Implementierung (z.B. Fiepen mancher Decoder) completly true

---

There is not much left of your concerns about the numerous bottle statements. Some have even been underpinned by yourself.
But please, I am open to new information. So you can explain the world of Railcom to us ignorants.

Zitat

---

POM mode is virtually impossible without RailCom.

---

No,why? Reading is impossible, thats true.

Best regards

Vinc

[ergunov]

Zitat

---

Und die Erde ist eine Scheibe . . . ? ? ?

---

Oliver so what?
In TC9, RailCom's implementation is very disgusting.
1. Only OPC_MULTI_SENSE packages are supported.
2. Of all the information only the addresses of the locomotive are accepted, there is no speed and qos.
3. The direction allocation mode works according to the “Blucher method”, so there is no other in OPC_MULTI_SENSE, which imposes restrictions on the address of the locomotive.
I'm not talking about the fact that with several sensors per unit, Railcom data can be taken from only one of them.

[ergunov]

Alright Vinc let's go over the points.

I repeat once again Railcom and Railcom Plus are one and the same standard, Plus variation is needed only for automatic registration of the locomotive and its functions in Ecos. In short, all the pictures that you made in LokProgrammer will be in Ecos. That's all, there are no other differences.

The fact that Railcom requires special equipment is of course obvious, it cannot be otherwise.

Regarding the compatibility and problems of different equipment.
It's not so simple.
At the moment there are 4 feedback blocks supporting Railcom: (We do not take into account OpenDcc and BIDIBI)
1. ECoSDetector RailCom - firmly attached by EcosLink to Ecos.
2. Blücher GBM16XL - absolutely redundant in current in the circuits, has a very high final price. Half of the RailCom implementation, only Channel 1 works.
3. Roco Z21 detector Railcom - the same problem as Esu is tied to the CAN bus, which allows you to work only with Z21.
4. Digikeijs DR5088RC - LocoNet bus removes restrictions and allows you to connect the module to different stations, work with the DR5000 and Z21 has been confirmed. In fact, it can work with any station with LocoNet; the main condition is that the station supports OPC_MULTI_SENS packets.

I do not understand what kind of connection problems you are talking about.
For example, the Ecos-EcosLink / Loconet convertor-DR5088RC really works simply as a unit with current sensors and does not transmit RailCom information. But this is the fault of ESU, despite the LocoNet licensing, they did not realize all messages from this bus.

Explain to me the fool how POM will work without RailCom., This is not physically possible.
Multimaus does not count, so there is actually no POM, but only an imitation.
z21 which does not have a separate exit to ProgramTrack can POM, and RailCom is in it.
POM programming works when accessing a specific address, for this reason it is not possible without Railcom.

What does it mean in which direction?
The standard is accepted, there are devices. So far, one obstacle is the greed of manufacturers who are doing everything for RailCom to work only when using their infrastructure.

About the costs agree. But what are the costs. Almost all decoders introduced in the last 5-8 years have Railcom support. Stations and boosters also support it. We need feedback blocks with Railcom, they are really more expensive than ordinary ones, and of course the question of compatibility between different manufacturers is open.

What compatibility issues are you talking about? I don’t understand. I have never experienced anything like this.
Problems are possible when using decoders with RailCom and old stations without RailCom, or vice versa, almost all of them are solved. But this is very rare and very specific, I had no such problems with Zimo, ESU, D&H and even American decoders. I helped the man he had problems, but with the American BLI decoder 2000 release, we decided everything.

If you are offended by quoting your message, I apologize. It was simply one of the last and one of those where a lot of questions were raised. I used it not for you personally, but simply as one example.

In general, I agree that there are enough problems with the implementation of RailCom, but this thing is interesting and has future even in our computer age.
Maybe when the requirements of RCN become more stringent with regard to their compliance, then RailCom will work with equipment of any manufacturers.

Vinc and another question.
Did you yourself have experience with Railcom, or are all your arguments “paper” and based only on data from the Internet and your assumptions?
Just why am I asking this, I myself had a lot of questions and doubts, some of which were decided and dispelled only when I "felt" RailCom live.

[Rainer Lüssi]

Hi all

Zitat

---

POM programming works when accessing a specific address, for this reason it is not possible without Railcom.

---

PoM works by sending config values to a specific decoder address. That works completely without RailCom and with devices such as the Marklin CS2 (no RailCom present).
The limitation in this case is changing the address.

Regards
Rainer

[ergunov]

[quote="Rainer Lüssi" post_id=2074089 time=1581054084 user_id=225]
That works completely without RailCom and with devices such as the Marklin CS2 (no RailCom present).
[/quote]

Rainer yes, Marklin has POM, but it is only possible to write CVs without reading them.

[aftpriv]

Good Morning Ergunov

Zitat

---

Railcom is standardized and even in two standards:
NMRA S-9.3.2 (currently the standard is outdated and needs to be reviewed)
RCN-217 is the current working standard.

---

If I read all the threads as of #31 correctly, then there is a "current workings standard", however the industry is not complying with it.

So de facto there is no standard seen from the level of the end user. This is very apparent when one reads the thread before #31.

Zitat

---

Even you wrote:
There are problems with hardware and software from different manufacturers, but many are solved.

---

A lot of others however are not solved (see thread)

My assumption is the following: “normal” railroaders leave your fingers off Railcom, you will be either very frustrated or loose a lot of money or even worth, be both.

Best regards
Alf

[ergunov]

Hi Alf
The main problem is that at the moment RCNs are not strict and binding standards, but they go to this and in the future completely replace NEM in the field of electronics.
As for standards, the existence of NMRA and NEM norms is parallel, while some of their provisions are not synchronized is not such a big obstacle.

I don’t understand why everyone is talking about some problems with Railcom? Despite the fact that many of the commentators did not even use it, but only “read something somewhere”, this is some kind of frivolous approach and reminds us of the times when DCC appeared, when many said “Why is it needed, we are good at DC”.

When I talk about my positive experience, no one listens to me, but only distrust its results, why?

Zitat

---

My assumption is the following: “normal” railroaders leave your fingers off Railcom.

---

My theory is different.
RailCom simply “burned out”, it took too long from the “paper standard” to real life, and when this happened it was not so enthusiastically received. PC programs have learned a lot without RailCom, the desire of manufacturers to cash in and in various ways to limit the use of their equipment also does not play into the hands.
And in the end, we suffer from all this we are modellers.

[aftpriv]

Hi Ergunov

Zitat

---

You wrote:
The main problem is that at the moment RCNs are not strict and binding standards

---

Zitat

---

Quote from RCN-217 (unfortunately only in German language):
1.2 Anforderungen: Um diese Norm zu erfüllen, müssen alle in dieser Normdefinierten technischen Werte und Protokolle eingehalten werden. Die Tabellen 5 und 6 definieren, welche der Meldungen von einem Decoder mindestens zu unterstützen sind.

---

müssen = to be bound to ==> Therefore RCN-217 is a strict and binding standard concerning RailCom.

Conclusion, if I as an end user can not rely on the correct and all encumbering implication of RCN-217 then this standard is at present not worth the paper it is printed on.

Therefore at this stage “hands off RailCom”

Best Regards
Alf

[system47]

Hallo Alf,

so wie ich es sehe, hast Du eine Lösung, die erst im vergangenen Jahr offen gelegt wurde.
Wo ist der Unterschied? Ich werde mich komplett von allem was aus dem Hause Märklin kommt verabschieden, da es nur in ihrer Welt funktioniert.
Ich Frage mich, wie das alle mit der CS3 in DCC machen (LGB, Trix, alles von Märklin ausser H0). Das funktioniert nicht.
Aber das schöne ist ja, dass jeder machen kann was er will.
Ansonsten werden persönliche Erfahrungen, für die es dieses Forum gibt, negiert und abgewertet. Weiter so!

[MobaVinc]

Hi Ergunov,

Okay, I go to the trouble again and try to clarify this. Let's go.

I've read your post three times and the only thing I can found is that you are mentioning nearly the same things like I do, only with more detailed information on top.

Zitat

---

I repeat once again Railcom and Railcom Plus are one and the same standard,

---

Physically yes, no doubt from my side. And ofcorse it has to be, because otherwise this wouldn't work on the same technically way like it is descibted in the tech.doc. (read my former post, I explained exactly this with the 1st/2nd OSI-layers)
But again you look on Railcom from a technical point of view. This isn't the view from an end user. If it would be like you claim, then it would not matter what kind of hardware the end user buys. Railcom or Railcom+ products, he always gets the full functionality because Railcom is always the same - and finish.

I'll try to explain with an other excample from former times. DCC is a normed and standardized protocoll since many years, but what happened as the protocoll was expanded for the long adresses? The DCC protocoll with the long adresses also was included into the DCC normation. Why? - Yes, because it should technically remain the same (again refer to the low OSI-layers). Otherwise there would have been compatibility problems ...
Now, what was the situation for the end user?
1) If he/she starts from zero and wanted the extention with the long adresses, he/she was only allowed to buy components that already supported this feature.
But you could have also buy components that did not have this extension. So, for the end user there were two "DCC-protocolls" although it was technically the same and was written into the normation.

2) If he/she already had DCC hardware, these users felt the difference very clearly. I don't think I have to go on here. ...

Zitat

---

The fact that Railcom requires special equipment is of course obvious, it cannot be otherwise.

---

No doubt, I've written the same.

Zitat

---

Regarding the compatibility and problems of different equipment.
It's not so simple.
At the moment there are 4 feedback blocks supporting Railcom: (We do not take into account OpenDcc and BIDIBI)
1. ECoSDetector RailCom - firmly attached by EcosLink to Ecos.
2. Blücher GBM16XL - absolutely redundant in current in the circuits, has a very high final price. Half of the RailCom implementation, only Channel 1 works.
3. Roco Z21 detector Railcom - the same problem as Esu is tied to the CAN bus, which allows you to work only with Z21.
4. Digikeijs DR5088RC - LocoNet bus removes restrictions and allows you to connect the module to different stations, work with the DR5000 and Z21 has been confirmed. In fact, it can work with any station with LocoNet; the main condition is that the station supports OPC_MULTI_SENS packets.

---

Here I think you know more than I do, especially more details. But I definitely agree with you that there are these compatibility problems and that is why Railcom is not always the same for end users. Like I already wrote here:

Zitat

---

The Railcom hardware you can get on the market not always does support Railcom in the same extent. There are several differences on the available hardware although the Railcom sign is printed on.
Ultimately, the Railcom standard serves as the basis for Railcom to function in principle. ...

---

Zitat

---

I do not understand what kind of connection problems you are talking about.

---

Where did I speak of connection problems? I didn't mention anything like that.

Zitat

---

Explain to me the fool how POM will work without RailCom., This is not physically possible.
Multimaus does not count, so there is actually no POM, but only an imitation.

---

Wait, I can't accept that, whether immitiation or not, the pure programming on the main track is possible. Just not the reading of CV's.
And:
[quote="Rainer Lüssi" post_id=2074089 time=1581054084 user_id=225]
PoM works by sending config values to a specific decoder address. That works completely without RailCom and with devices such as the Marklin CS2 (no RailCom present).
The limitation in this case is changing the address.
[/quote]Thanks to Rainer.

Zitat

---

z21 which does not have a separate exit to ProgramTrack can POM, and RailCom is in it.
POM programming works when accessing a specific address, for this reason it is not possible without Railcom.

---

Yes, thats true.

Zitat

---

The standard is accepted, there are devices. So far, one obstacle is the greed of manufacturers who are doing everything for RailCom to work only when using their infrastructure.

---

Yes. Well, another thing I have already mentioned.

Zitat

---

About the costs agree. But what are the costs. Almost all decoders introduced in the last 5-8 years have Railcom support. Stations and boosters also support it. We need feedback blocks with Railcom, they are really more expensive than ordinary ones, ...

---

Again, you explain in more detail what I wrote.

Zitat

---

... and of course the question of compatibility between different manufacturers is open.

---

Yeah, the compatibility "problems" I also mentioned before.
So it's beyond me how you can ask this? ...

Zitat

---

What compatibility issues are you talking about? I don’t understand. I have never experienced anything like this.

---

Zitat

---

If you are offended by quoting your message, I apologize. It was simply one of the last and one of those where a lot of questions were raised. I used it not for you personally, but simply as one example.

---

No, problem at all. The only thing is, you claim that Railcom has to be viewed in a total different way but you say exactly the same things like I do in almost all aspects.

Zitat

---

In general, I agree that there are enough problems with the implementation of RailCom, but this thing is interesting and has future even in our computer age.

---

Here I am definitely with you. A bidirectional communication leads to a lot great features and possibilities.

Zitat

---

Maybe when the requirements of RCN become more stringent with regard to their compliance, then RailCom will work with equipment of any manufacturers.

---

I can only hope so. Then compatibility problems can also be excluded

Zitat

---

Vinc and another question.
Did you yourself have experience with Railcom, or are all your arguments “paper” and based only on data from the Internet and your assumptions?
Just why am I asking this, I myself had a lot of questions and doubts, some of which were decided and dispelled only when I "felt" RailCom live.

---

I on my personal track, no. However, in our club and with some friends. Problems here and there, sometimes easy to solve and sometimes it is very tedious to find the reason for errors at all.
Some problems have been because of hardware from different manufactures, some because of combination of older hardware (15 or 16 years old, no age for model railroad conditions) with newer ones.
... Fortunately, we are 3 electrical engineers in the club.

Best regards,

Vinc

[ergunov]

Alf why are you changing the meaning?
I was not talking about the fact that the RCN-217 is not thought out, just the opposite, everything is very clear and balanced there.
I mean that compliance with RCN standards by all manufacturers is still in the process.
More than 20 members have joined the RailCommunity, including ESU, Roco, Zimo, Digikeijs and NMRA with MOROP, so sooner or later RCN will become tough and binding, and all conflicts with NMRA and NEM will be resolved.
I spoke with NMRA officials, it is a very bureaucratic organization, besides having the problem of translating technical German into technical English.

Alf have you tried using RailCom yourself?

[ergunov]

Vinc that you have clung to this Railcom Plus, this is just marketing from ESU, everything is not incompatible there, but there are only mechanisms that synchronize project icons for a decoder with a command station.

When I wrote that I don’t have any problems, I already spoke about a fully working and debugged scheme.
I agree at the design and assembly stage, anything is possible.
I use Rocrail and I had to sit a lot on the forum talking with the developer and solving software problems, there I met people who ran the Z21-DR5088RC configuration and eventually achieved results, here on stummiforum I read a relatively fresh story from a person trying to launch a bunch of IntelboxII- DR5088RC, he did something, something didn’t, but it seems he gave up.

At the beta stage of the DR5088, as well as during its operation, I entered into correspondence with various manufacturers of equipment and software, communicated with officials from NMRA.
I believe that RailCom has future ones, and I will try to help it advance.

[MobaVinc]

Hi Ergunov,

I have to add, that I do not doubt your positive experience with Railcom. I' ve made positive experience with it myself. But there are a lot problems/issues and aspects one should think about. And I personally can't give a recommendation for this at the moment.

If there are these huge changes, you told of, in future, then I' ll use it and can give recommendations without bad conscience.

The "dream" of a bidirectional communication over the track is a thing that has been overslept for far too long. This aspect should have been taken into account when DCC was standardized in the 90s. The DCC technology might not have been standardized as we know it today.

At the moment, a user has to ask whether the effort versus benefit of Railcom is positive for him. Although a lot has happened in the past 10 years, I still don't see it as positively as you would like to put it here.


Best wishes,

Vinc

[ergunov]

Zitat

---

This aspect should have been taken into account when DCC was standardized in the 90s. The DCC technology might not have been standardized as we know it today.

---

By the way, there is an explanation for this, Lenz is to blame for everything, here is an example when trying to dictate your rules on the market gives the opposite result.
It was Lenz, as the creator of RailCom, who filed a patent for it in the USA and transferred the standard to NMRA. As a result, manufacturers simply did not use the protocol, the situation changed only after the patent expiration date and the creation of the RCN-217 norm.

[StephanLeist]

Hallo Vinc,

Zitat

---

The "dream" of a bidirectional communication over the track is a thing that has been overslept for far too long. This aspect should have been taken into account when DCC was standardized in the 90s. The DCC technology might not have been standardized as we know it today.

---

Dann könnte dich das hier interessieren, wenn du an richtiger bidirektionaler Kommunikation über die Schiene interessiert bist. Ich für meinen Teil finde es schade, dass sich sowas nicht als Standard druchgesetzt hat.
C-Digital System ???
Ich fand es schon interessant einmal das zu lesen, weil es mir ermöglicht hat andere Dinge (Standards) bei DCC oder der Moba allgemein differenzierter zu sehen.

Ich bin sehr gespannt wo sich Railcom noch hinentwickeln wird, v.a. entwickelt es sich ja gefühlt schon seit 20 Jahren und immer heißt es, dass wird noch mal wichtig und groß ... und wenn nur erst ...
Bei den heutigen Softwarelösungen am PC oder auch mit Embedded-Rechnern hat es Railcom auf jeden Fall schwer eine deutliche Darseinsberechtigung zu erlangen.

[aftpriv]

Hi ergunov

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

---

Alf why are you changing the meaning?
I was not talking about the fact that the RCN-217 is not thought out, just the opposite, everything is very clear and balanced there.

---

I have not questioned the integrity of the RCN-217 standard.

Zitat

---

I mean that compliance with RCN standards by all manufacturers is still in the process.

---

If manufacturers do not comply in all respects to the standard then they must not use this standard as reference – the RailCommunity is there to sanction wrong doings in order to protect the end user as well as their own seriousness.

Zitat

---

More than 20 members have joined the RailCommunity, including ESU, Roco, Zimo, Digikeijs and NMRA with MOROP, so sooner or later RCN will become tough and binding, and all conflicts with NMRA and NEM will be resolved.

---

Looks like many of them being unruly.
What have NMRA and NEM to do with this issue, the Standard is issued by the RailCommunity. Either the members adhere to it or remove the reverence to RailCom.

Zitat

---

I spoke with NMRA officials, it is a very bureaucratic organization, besides having the problem of translating technical German into technical English.

---

What have they to do with it? If they want to have RailCom in there own holy bible they all need to do is refer to RCN-217.

Zitat

---

Alf have you tried using RailCom yourself?

---

No, I look into it when the system is running flawless and bee sure not to sink money unnecessarily!

My personal Conclusion: even so there is a standard, however not adhered to at all or in parts, as well as many problems regarding interoperability you will not see me interested!

Regards
Alf