[ergunov]

Zitat

---

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!

---

You change the meaning again.
The fact is that many devices (the same roco Z21 detector) were designed before their manufacturers joined the RailCommunity association.
The RCN-217 was not created from scratch, as the basis was Standart RailCom Lenz 1.4, which in turn is based on NMRA 9.3.2.
Accordingly, all RailCom-enabled devices created prior to the introduction of RCN-217 are based on Lenz 1.4 or NMRA 9.3.2. Although basically all of these standards are fully compatible.

In the end, as I understand it, the foundations of the RailCom problem are not standards or hardware problems.
The problem, as Bulgakov wrote in the disembodied "Dog Heart" - "Devastation in the Heads." The fact is that railway modeling is an age hobby, and, accordingly, people are not ready for changes and something new. For many, DCC is already a problem, not to mention Railcom or computer control.

[8erberg]

Hallo,

siehe: http://www.digitrax.com/tsd/KB960/digitr...s-lenz-railcom/

Peter

[ergunov]

Hi Peter
???
what?

[Tanis]

Moin,

vielen Dank für eure Antworten und die rege Diskussion!

Mein Fazit ist: RailCom wäre ein "nice to have", wenn es die wichtigsten Hersteller von Hard- und Software in ihre Produkte einbinden würden, aber so ist eine leistungsfähige Software reifer, umfänglicher und im Kostenverhältnis gegenüber railcomfähigen Dekodern & Rückmeldern selbst dann günstiger, wenn man die 500,- € für TC Gold stemmt.

Egal wie groß meine Anlage einmal werden könne und wieviel Züge darauf fahren werden... ich werde ohne RailCom klar kommen. Die Frage nach RailCom stellte sich ja nur deshalb vor Planung und Bau der Anlage, weil ich jetzt mit der Beschaffung von Lokomotiven beginne und da Klarheit brauchte.

Da das jetzt geklärt ist kann ich mich mit dem Thema Zentrale und Rückmelder beschäftigen.

Grüße. Olaf

[moppe]

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

---

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.

---

What happened to Uhlenbrock Marco! Why is it not on your list?


Klaus

[moppe]

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

---

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

---

I don’t recognise all these problems and frustration with RailCom.
I have been using it since the Z21 detector hit the market and has never seen any problems.

I know several who is using Uhlenbrock Marco, without issues.

If you count the large numbers of problems with the “Digischeiss” DR5088 as a general problem with RailCom, you need to be able to distinguish between a cheap product that was sold before it had finished it development, and RailCom as technology.


Klaus

[moppe]

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

---

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.

---

Railcommunity is a joke.
They sit around the table and agree on the standards - and then they go home and develop new equipment that doesn’t follow the standards.

Klaus

[uhx]

Folks, seriously? I absolutely don't get the point of this whole pro/con Railcom discussion. I've been operating Zimo decoders combined with GBMBoost/GBM16T for five years now. Neither was the equipment ridiculously expensive, nor have I ever experienced any of the asserted problems. On the contrary, reading out CVs on the main line (hardly ever use a programming track) has become an essential function in everyday operation and QoS has proven most beneficial.

So, if someone doesn't need this kind of amenities, that's ok. However, if someone does that should also be ok. How about stop trying to prove one another that Railcom is the best/worst invention ever being made in model railroading and just let it be what it is: most useful for some, completely useless for others and whatever is in-between those extremes.

[ergunov]

Zitat

---

What happened to Uhlenbrock Marco! Why is it not on your list?

---

Hi Klaus
I just do not know what MARCO can do there, if you enlighten, I will be grateful.

Klaus You can tell us in detail about the Z21 Detector, what it can, what RailCom packets it uses. Does it transmit speed, QOS and direction data?

As for the DR5088, I agree, but this is the fault of the owner of the company, the developer was against it. Although all this applies only to the block output, after firmware 1.4 it became fully functional, and the OPC_MULTI_SENSE_Long packages licensed in the LocoNet protocol expand the capabilities of RailCom.

Thanks Ulli finally who said something good.

[Flo_85]

Zitat

---

... weil ich jetzt mit der Beschaffung von Lokomotiven beginne und da Klarheit brauchte.

---

Bei den Loks brauchst Du dir da aber wenig Gedanken machen, aktuelle Decoder haben Railcom großteils sowiso drin.

Es stellt sich in erster Linie die Frage ob man auch lokale Railcom Melder haben will oder nicht. Denn die Zentralen unterstützen es ja großteils auch. Selbst wenn man keine lokalen Melder verwendet kann man den globalen der Zentrale ja zB immer noch zum POM lesen nutzen.

[moppe]

Zitat

---

I just do not know what MARCO can do there, if you enlighten, I will be grateful.

---

Marco is RailCom by Uhlenbrock.

Zitat

---

Klaus You can tell us in detail about the Z21 Detector, what it can, what RailCom packets it uses. Does it transmit speed, QOS and direction data?

---

I only use it with the Z21 app and gets the address - nothing else.
It can report direction and channel 2 data.

https://www.z21.eu/media/Kwc_Basic_Downl...08-Detector.pdf

Klaus

[ergunov]

Zitat

---

I only use it with the Z21 app and gets the address - nothing else.
It can report direction and channel 2 data.

---

Klaus instructions I saw, they do not reflect all the nuances.
For example, does speed transfer and qos work?
What decoders and what software do you use?
Regarding the direction, as I understand it in 10808, OPC_MULTI_SENSE, invented by the blucher, is used, which means that the direction data goes as a correction of the locomotive address, which limits the address 4096.

In my DR5088, you can use either OPC_MULTI_SENSE or OPC_MULTI_SENSE_Long.
This increases the possibility of compatibility with different software, for example, the direction in TC9 works only on OPC_MULTI_SENSE, and in Rocrail on the more progressive OPC_MULTI_SENSE_Long.

[moppe]

Zitat

---

What decoders and what software do you use?

---

Software = Z21 App on iOS.
Decoders = ESU, ZIMO and Uhlenbrock.


Klaus

[StephanLeist]

Hi at all,

Zitat

---

Bei den Loks brauchst Du dir da aber wenig Gedanken machen, aktuelle Decoder haben Railcom großteils sowiso drin.

Es stellt sich in erster Linie die Frage ob man auch lokale Railcom Melder haben will oder nicht. Denn die Zentralen unterstützen es ja großteils auch. Selbst wenn man keine lokalen Melder verwendet kann man den globalen der Zentrale ja zB immer noch zum POM lesen nutzen.

---

Exactly right, Flo. That's the point.

@Ulli, Ergunov
I think what Flo wrote shows what this pros and cons discussion for Railcom should be.
It isn't the question if there ist someone who uses Railcom without problems and gets along with it or somone who already used it and couldn't be satisfied and the third group of people won't use it because they know issues and have seen problems other model railroadres had with it or do not want to pay as much for it as they should have to. (little benefits for much money becode they already have a software for everything)
I myself also know someone who uses Railcom with detectors successfully but you have to say the hardware he uses is all from one manufacturor (ESU) except the decoders for the locos (Zimo & ESU). He never told something about problems. Here, the question for a beginner is, if he wants to pay for the benfits and if the benefits are worth it.
But I also know someone how tries to use Railcom, too. He used hardware of different manufacturers and had several problems. Here, one must say to a beginner, that it could be that he will have problems when using Railcom hardware from different manufacturors.

So the experiences I made, fit well with the impression that somone can get out of this thread.

Best regards

Stephan

[vikr]

Hallo Olaf,

Zitat

---

Die Frage nach RailCom stellte sich ja nur deshalb vor Planung und Bau der Anlage, weil ich jetzt mit der Beschaffung von Lokomotiven beginne und da Klarheit brauchte.

---

Was hindert Dich daran ausschließlich Lokomotiven zu beschaffen, die einen Railcom fähigen Decoder haben, bzw. sich notfalls umrüsten lassen?
Bei neueren Loks von Minitrix läßt sich der ab Werk eingebaute Decoder sogar häufig nachträglich die Railcom Fähigkeit updaten.
Du hälst Dir so alle Optionen offen.

Auch in einer Railcomumgebung ist es ökonomisch sinnvoll auch Melder einzusetzen die nur Belegtmeldung beherrschen.

Meine Empfehlung: Bau Dir ein übersichtliches Testbrett mit ein bis fünf Weichen (am besten einschließlich einer Kehrschleife) und z.B acht Rückmeldern. Probier selbst mit den Testversionen der Modellbahnsteuerprogramme alles aus, bevor Du groß einkaufst.

MfG

vik

[ergunov]

Zitat

---

Software = Z21 App on iOS.

---

Klaus that is, you do not use automation with a PC?

Zitat

---

But I also know someone how tries to use Railcom, too. He used hardware of different manufacturers and had several problems. Here, one must say to a beginner, that it could be that he will have problems when using Railcom hardware from different manufacturors.

---

It’s clear to Stephan that everything is much simpler within the framework of one system; I’m just trying to collect data on the difficulties that may arise when using equipment from different manufacturers.

[8erberg]

Zitat

---

Bei neueren Loks von Minitrix läßt sich der ab Werk eingebaute Decoder sogar häufig nachträglich die Railcom Fähigkeit updaten.

---

Die Zeiten sind vorbei, es werden keine D & H Decoder mehr von Minitrix eingesetzt.

Peter

[moppe]

Zitat

---

Zitat

---

Software = Z21 App on iOS.

---

Klaus that is, you do not use automation with a PC?

---

Correct.

I run a large layout computer controlled in my club, so at home I want to do everything manually.
Z21 for controlling Lay-out and WLANmaus for running trains.


Klaus

[ergunov]

Understood Klaus Thank you.

By the way, I looked at Uhlenbrock MARCo, indeed, it supports RailCom, its minus is the presence of only two inputs, at a price of 40 euros and tuning only by LNCV.

[moppe]

The only reason the DR 5088 is popular is its low price.
Unfortunately it is also the reason why so many people have problems with RailCom.

Quality costs!


Klaus

[ergunov]

Klaus than you do not like DR5088?
As for me this is the best unit, the LocoNet bus provides compatibility with different stations.

[moppe]

Zitat

---

Klaus than you do not like DR5088?
As for me this is the best unit, the LocoNet bus provides compatibility with different stations.

---

In general, I see most questions concerning Digikeijs products, in forums both in Denmark and Germany.
Either it is because Digikeijs holds 90% of the market (they don’t) or because their products is “semi-finished” and their manuals is confusing. When the DR 5088 came onto the market, it flooded the bus with unnecessary traffic, when you had several units.
I have never seen that with the Z21 detector.

Why?
Because the Z21 detector was a finished and tested product when it was released.


Klaus

[ergunov]

Klaus, I understand what you mean. Personally, I can’t say that I was experiencing problems with the DR5088 even at the beta test stage, I don’t know if the thing was that I immediately knew that he was waiting for him.

And with Digikeijs, everything is much simpler.
The problem with all smart people is that they think that everyone around is smart too, and that’s not at all true.
Their products are very cool, the DR5000 is generally a super station. Probably the manufacturers decided to save a little, but in vain.
If you invested a little more in higher-quality components, made more thoughtful instructions, paid more attention to marketing, the result would have been completely different.

[vikr]

Hi Klaus,

Zitat

---

Why?
Because the Z21 detector was a finished and tested product when it was released.

---

Blücher helped Roco to develope the 10808. Now it seems to work better (more universal) than the original.

MfG

vik

[ergunov]

Hi Vik
Where did you get the information that Bluher was involved in the development of the Roco 10808?