Hi,

I am planning on getting the ESU update for my CS1. Does anyone know if you will be able to run a DCC loc AND MFX at the same time?

Does the CS2 allow the simultaneous use of DCC and MFX?


Thanks,

Phil

The answer to both questions is Yes. DCC and mfx can be used together with both the CS2 and v3 CS1.

Don´t forget about ESU new Ecos II,which you can also using in both with DCC and mfx.

Goofy

Once the ESU update is available I plan on ordering it. I will post results ASAP. I just hope the ESU update comes out.

Phil

Thank's very much Perz, for clarifying. It all makes sense to me, including the note about Digitrax. If I understand it correctly, NMRA have choosen Lenz system, which AFAIU doesn't make sense using unless all equipment is changed at a time. I guess they have thought about something to avoid destroyal of equipment, but I guess it's difficult to convert parts of the layout. I think Digitrax claim it would be possible to have some segments with feedback, and others without.

And still, there I've not heard any good thinking (well, I've not actually searched for it) about how this feedback should be used in a good way. The only commersial system I know that is WORKING, that is, can cause functions to appear at the layout, without using a computer, is still AFAIK Lissy. Which of course is expensive, but still - has been working for years alaready.

Sorry for stealing thread. Enought from me now. /Lars

No, I'm not referring to Digitrax LocoNet. I'm referring to their "transponder" technique.

Trains.

Right thanks, I misunderstood

However the Digitrax transponder function is aimed at occupancy detection and needs a separate detector to listen , which in turn feeds the message back to the controller via loconet.

Given that neither the CECoS/CS1 or CS2 have loconet this becomes a mute point does it not ?

Are you saying it ALSO has the automatic registration capabilities similar to mFX when you put a decoder on the track for the first time?

Trains.

Hi Lars, all,

Although I'm getting off-topic here, I'd like to add something to the discussion.

@ Lars: Your contribution is a very good elaboration on the possibilities of digital feedback. Reading your contribution makes me wonder; do you know of the DCC RailCom system, among others supported by ESU?
In their new items folder, they present the ESU ECoSdetector.
See: http://www.esu.eu/produk...osdetector/ecosdetector/
Which seems to be a really interesting system. In your classification, their system is having the features 1..4 listed and is technically like option A.

I for one am very interested in the practical application of the RailCom system, even though it requires a lokdecoder featuring RailCom. Consequently, I would have to convert a couple of my locomotives. Luckily, most of them would benefit significantly from a new decoder anyway.

Interesting discussion and sorry for going off-topic.

I must rely on web translators for the ECosDetector manual, however it appears to be very much like the Digitrax equipment, which has a foundation of basic occupancy detection by way of detecting any current draw. To this you can add an intelligent detector capable of reading a decoders ID (if it has one)

Therefore to get started you do not NEED ID intelligence. I think the Decoder extension is just that, a simple led that turns on when a section is occupied. The ID , if available, can be built up to.
Please correct me if I have this wrong.

5.programming a whole trip from departure to Arrival
6.doing it for 1, 2 or 3 , or several trains...
7.Assigning a "characteristic of priority" to some trains ( automatic choice of which train will stop on a cross)
8. .....doing all what you do with a PC, but in better condition of communication ( integrated)
....don't you think that it needs a "special item" , a kind of " special box - with or without screen , depending on if the job can be treated easily on CS2's screen I.E. with keyboards or/and layout panel - a kind of "special box " to connect it to the CS2 ?
Because I believe a wireless channel should be abble to do the job...only 4 digit must be transmitted)

There are two reasons why I think there will not come such a product:

1. The principle of using modulation of the decoder current draw to locate the segment where a train is positioned is patented by a man named Ireland. Mr. Ireland has licensed this patent to Digitrax. So only Digitrax are allowed to use this principle. The Railcom DCC circumvents this by not using modulation of the current draw for the feedback, but instead use stored energy in the decoder to transmit during power "cutout" periods. The mfx feedback is non-infringing on that patent as long as it is not used for identification of the train position.

2. The principle is not so scalable, at least not if based on mfx. There are three different mfx commands that enable the feedback in the decoder (I use Rainer Müller's terminology here):

a) PING. This command is directed towards one single decoder at a time. The addressed decoder gives a simple (non-coded) response.

b) SUCH (German for "search"). This command is directed to all decoders but only non-registered decoders can respond. The response is non-coded.

c) READ. This command is directed towards one single decoder at a time. The addressed decoder gives a coded response, containing the data requested by the parameters to the READ command.

None of these commands actually control the trains, so they have to be mixed with train control commands. In practice only the PING command is meaningful for positioning. The time required for a PING to one lok is around 20 ms, and the PINGs can only take up a fraction of the available bandwidth. To be able to detect all trains you have to ping each train, one after eachother. The more trains you have, the longer time there will be between the PINGs to a specific train. With 10 - 20 trains the detection will be too slow to be really useful I think.

A possibility would have been to have a broadcast PING-like command. The SUCH command is like that, but it only adresses the loks that have not already been registered. To my knowledge there is no mfx command that can make all registered loks respond at once. There is a reason why such a command would not be such a good idea anyway. The mfx feedback draws quite a bit of power. My measurements indicated approximately 2.5 VA. Guess what will happen on a heavily loaded layout if suddenly each lok draws 2.5 VA extra!

In fact this can happen with the SUCH command, if none of the loks are registered, and the lok serial numbers are such that the probed bits coincide. I suspect that this phenomenon can be a source of many mfx registration failures. E.g. the MS sends out a SUCH and the combined current draw of all the responses causes a temporary overload that makes the decoders and the MS lose the power in the critical moment when both sides have to decide if the lok is registered or not.

I don't know how Digitrax and DCC Railcom have solved the scalability problem, or even if they have solved it.