'Messy' DCC signal.

[BoD]

At a recent model railway exhibition I was discussing servo control of signals with some guys from MERG. I talked about my plans to control the points and signals via DCC and a computer. One of the gentlemen there used DCC to control locos but other electronics to control motors etc because he felt quite strongly that you could 'ask' the DCC signal to do too much and the signal could become distorted and cause problems with loco control.

He has obviously sewn some seeds of doubt here because, whilst I still intend going down the path of Rocrail and DCC control of my layout, I occasionally just wonder about what he said.

My question then is, is his reasoning sound? Can you mess up the DCC signal by asking it to do too much?

[Talltim]

I don't see that point control etc is any different from loco control, after all the DCC controller is just sending signals to change power settings on decoders.

More decoders (of any type) being controlled simultaneously requires more data to flow, if you reach the limit of the bandwidth then you might experience degraded performance, I don't know with the DCC format whether this would be because of missed commands or latency (slowness) I also don;t know at what point you would reach the limit.

[PaulCheffus]

Hi

 

Without getting in to the nuts and bolts sending a command to a point is basically the same as sending a command to a loco. I can't see why this would cause any distortion to the DCC signal and having used an oscilloscope to view the signal on my own layout I didn't notice any waveform changes when changing points other than the encoded information is different.

 

As has been said above bandwidth could be the only limiting factor and again I don't see that being an issue. The Lenz command station (I am most familiar with this as I have one) sends the loco data periodically for all locos in the command station stack so if one packet was corrupt (and there is an error checking mechanism built in to DCC so that it is rejected) then the loco would get another one quite quickly.

 

Cheers

 

Paul

[Dagworth]

Hi

 

Without getting in to the nuts and bolts sending a command to a point is basically the same as sending a command to a loco. I can't see why this would cause any distortion to the DCC signal and having used an oscilloscope to view the signal on my own layout I didn't notice any waveform changes when changing points other than the encoded information is different.

 

As has been said above bandwidth could be the only limiting factor and again I don't see that being an issue. The Lenz command station (I am most familiar with this as I have one) sends the loco data periodically for all locos in the command station stack so if one packet was corrupt (and there is an error checking mechanism built in to DCC so that it is rejected) then the loco would get another one quite quickly.

 

Cheers

 

Paul

I've seen the bandwidth get overloaded without using DCC for accessory control. With a Lenz set 100 with a full stack it's quite easy to get locos stuttering as the refresh rate gets too slow. Clear the stack back to only what's needed and the problem goes away.

 

Andi

[Crosland]

My question then is, is his reasoning sound? Can you mess up the DCC signal by asking it to do too much?

 

As a MERG member myself, that is disappointing. Probably a misuse or misunderstanding of terminology somewhere but the answer is, quite simply, no.

 

Was it someone on a MERG stand?

 

As others have said there is a limit to the amount of information that can be carried on a DCC bus but accessory control packets are infrequent and unlikely to be the straw to break the camels back.

 

Andrew

Edited June 17, 2014 by Crosland

[Phil S]

What is sent out by the Central Controlller varies between designs: There is a basic cycle of Loco Speed (and direction and Directional Lighting) control packets, and, if other functions are activated, addiitonal packets for the Functions in groups.  Also transmitted 'when required' are packets giving specific commands to stationary decoders (accessories such as points and signals).

 

The variations between designs are in the 'size of the basic loco stack' and precisely how they have chosen to send the accessories, when commanded.  In effect, the more powerful the processor used, the more locos are likely to be in the stack ... but few controllers seem to provide this information, especially prior to purchase.

 

An exception was the Massoth Dimax: manufacturers of many of the MTS controllers for LGB (after the initial Lenz design ?), who now produce their own range, in their own name, of dcc modules etc, as well as any still produced by them for LGB (which is now part of Marklin).   The original {Lenz) LGB MTS could only select from locos 1-8, and 2 functions... 'higher level functions' - of which LGB were an early user - were originally accessed by repeated pressing of F1... with 'Serial' Decoders which counted how many F1 commands were sent .... for many years, LGB MTS has offered the standard 'parallel' function commands, but only using F1-8 via their own handsets.  A great operational difficulty with the Serial Method, was ensuring the user sent the F1 pulses quickly enough, and that none were 'lost in transit' through dirty track etc. ... was that 7 or 8 pulses you sent to the loco ????

 

The Dimax controller offer the user a setup option of how many locos they want to include 'in the stack' / cycle: the more locos, then the slower the repeat rate, and therefore response to speed changes (which in turn will also be affected by CV3 and 4 inertia values0.

My experience of the MTS Central unit suggests 8 locos are on the stack - and all can therefore be controlled and moving if there is enough current available - via a booster if necessary.

The precise number can be confused at times, as many decoders (particularly for garden use?) include a memory, in the case of loss of information; and therefore after an emergency stop, it is possible that more than the 'current stack' of locos retain their function settings. This is particularly true of Sound On/Off whose status is even retained in 'analogue' by digitrax decoders.  The Central Unit itself has a memory limit  of 32 locos when used with a Massoth handset, but still only 1-22 plus Analogue 0 are accessible with LGB handsets.

 

Observation of the Roco MULTIMAUS and its amplifier shows an output a cycle of 16 locos 'on the stack' to which are added packets for any of those locos which have active functions, and THEN on top of that, when an accessory is operated, a 'burst' of 15 packets is sent which repeat the Accessory command.   When used with multiple handets, and/or the computer interface to software, it would be possible to send commands to more than 1 accessory 'simultaneously' /rapidly ... but I havn't monitored this. [i use an NCE dcc reader to monitor what is actually sent to the track]

By  contrast; the Roco MultiCentralePRO central unit appears to send a cycle of 32 locos in its stack.   Reading of Roco FEEDBACK modules is a separate process which is only 'mixed in' with the Expressnet loco/accessory data on the link to the computer ... it has its own physically separate bus, and this terefore does affect the track dcc bus.

 

A 'factor' which may have affected the decision/opinion of the person reported, is that with SOME controllers, it is easy to swap between loco and acccessory  control - but less so on others!

Edited June 17, 2014 by Phil S

[Suzie]

There is the potential to corrupt the DCC waveform by attaching a poorly designed piece of equipment to the track feed, but that could be anything and is most likely to be a rake of lit coaches.

 

There is nothing to worry about if you are just adding good quality accessories. If you start running low on power you can easily add a booster, but you are likely to be having a pretty busy layout before that happens.

 

I suspect that what you were told does not come from experience. Attaching accessories has to be given proper consideration as to how it is done to get the most from your system, but there is no reason not to do it. Good quality accessories will have flexible wiring arrangements to suit your situation.

[BoD]

Thanks for the replies folks. You have gone some way to putting my mind to rest.

 

Andrew: Yes the gentleman concerned was on the MERG stand and whilst possible I don't believe there was a misunderstanding. He was quite specific about separating the train control (DCC) from the servo control which used electronics controlled from a computer.

 

At the moment I have only experimented with a test track and one or two accessory decoders at once, mainly to learn how to use the rocrail software and there have been no problems so far (I will probably regret making that statement before too long).

 

I am using a mixture of NCE SwitchIT decoders with tortoise motors, and Lenz or LDT feedback/ track detection modules. Some of these use the track power. I have already accepted that I may need an additional power booster but other than that (and assuming the wiring follows good practice) using the track supply shouldn't cause problems should it?

[Grovenor]

IMHO it is desirable to separate the DCC for accessories, especially points with live frogs, from that for the track. Not because of any technical issue with the DCC signal but because of practical operating convenience. If you accidentally drive a train onto a point set the wrong way (and you or someone will) you will get a short via the switched frog. The cure for this is to change the point to the correct position thereby removing the short. However if your points are controlled from the track this cannot be done as the short will prevent the point moving. If you want to control the points via DCC it is best to run a seperate DCC bus to the points and fit a fuse/breaker in the track bus so the track shorts do not shut down the command station and you will still have control of the points.

This may be what the MERG person was getting at.

Keith

[peach james]

My understanding of Digitrax is that the stack limits are around 200 items on a regular basis.  So, a basic accessory decoder is not likely to cause problems, from memory, the signal to change a status is sent 3 times, and then not repeated.  Same sort of thing for message status updates from accessory decoders.  Where it gets sticky is if the system is generating lots of speed change instructions for locos.  If you are using the CV's in the chip (CV3/4) to regulate acceleration, then that would place no more demand on a loco than the single change of speed instruction.  If you are using software generated speed tables (think RR&Co), then you may run into problems.

 

Digitrax hard limits are a DB150 is 22 locos, and a DCS100/150/200 is 120 locos running _at the same time_

 

James

[TartanTrax]

Thanks for the replies folks. You have gone some way to putting my mind to rest.

 

As a manufacturer of some DCC kit, I will just add my 5p's worth here and say that not only is it unnecessary for you to worry but pointless as this man's opinions are just that and not hard evidence. We had some results of tests done by the NMRA (when issuing Warrants of Conformance to manufacturers of command stations and boosters) that showed that it is pretty much the norm for the quality of the DCC square-waves produced by numerous products on the market to be poor to very poor on average. On average, the expensive models were just as guilty as the budget models and putting these systems under significant load seems to harm them very slightly to not at all. In terms of the DCC specs, locomotive decoders are required to be very tolerant of a poor DCC signal and they usually are. The problem arises with accessory decoders, turntable controlers etc. where there isn't the same requirement for coping with poor DCC and relatively poor performance can result and sometimes no performance at all. This isn't because you asked too much of it, - the hardware was just not built to a high enough standard. (Of the NMRA tests we were given, about 70 to 80% should have been improved before putting them up for sale to the trusting public.)

 

When we designed our DCC4PC Standalone Railcom Cutout Device we wanted to make sure that we wouldn't be blamed for anything not working because guys came up with an opinion that we were to blame. That is why our product, when connected to a command station or booster, will take in the DCC signal and repair it so that no decoders should fail to respond to DCC commands, either when the RailCom cutout is active or even when it is not. If you want to look at our website under the manuals for the Cutout Device, we have published oscilloscope traces of the DCC signals from two very popular mid to top of the range Command stations both before and after fixing. Both these manufacturers were successful at getting an NMRA Warrant of Conformance (WoC) so they are clearly not very strict. You have to wonder how bad some of the DCC signals are from manufacturers that failed to get a WoC after the NMRA tests. One of those that failed, is mentioned quite often on this forum but it would be unethical for me to mention any names, as in practice their stuff seems to work pretty well regardless. However if you do try to run both systems via DCC and find you have a problem as the MERG bloke described there are a couple of ways to fix the problem. One we are looking at presently is adding a hardware & software bridge to a Raspberry Pi. This has the potential to be a very high quality solution at a budget price. It is such an obvious idea, I'm sure we aren't the only ones looking at this either.

 

Kind regards,

 

Ray.

[zedcell]

On 17/06/2014 at 20:41, Suzie said:

There is the potential to corrupt the DCC waveform by attaching a poorly designed piece of equipment to the track feed, but that could be anything and is most likely to be a rake of lit coaches.

 

There is nothing to worry about if you are just adding good quality accessories. If you start running low on power you can easily add a booster, but you are likely to be having a pretty busy layout before that happens.

 

I suspect that what you were told does not come from experience. Attaching accessories has to be given proper consideration as to how it is done to get the most from your system, but there is no reason not to do it. Good quality accessories will have flexible wiring arrangements to suit your situation.

Sorry i know this is an old post, only i was doing a bit of research on a corrupt dcc signal and this post sent the alarm bells ringing , with regard to a rake of lit coaches.

My problem is i a have a fairly large DCC layout, power is supplied via a NCE DB5 and SB5 supplying 5 amps each to 2 power districts , i have 2 rakes of hst fitted with coach lighting and one of the rakes has been a bit erratic on certain sections of track including jerky and unresponsive to some commands like horns but when the power car is tested on a rolling road on the program track it runs perfect . 

Would be interested to hear what your thoughts on this .

 

[Crosland]

15 hours ago, zedcell said:

i have 2 rakes of hst fitted with coach lighting and one of the rakes has been a bit erratic on certain sections of track including jerky and unresponsive to some commands like horns but when the power car is tested on a rolling road on the program track it runs perfect . 

 

 

How does the power car behave on it's own on the track?

 

How does it behave when pulling a rake of unlit coaches?

 

Edited September 12, 2019 by Crosland

[34theletterbetweenB&D]

On ‎11‎/‎09‎/‎2019 at 18:49, zedcell said:

..a bit erratic on certain sections of track...

To add to Crosland's suggested next steps you need to test the loco alone and loaded with unlit coaches specifically on those 'certain sections' where the trouble is observed.

 

(Assuming here that you have already done the sensible stuff of cleaning the rails of the 'certain sections' and ensuring the loco's pick up wheels are clean and all pick ups are functioning efficiently.)

 

(My immediate guess would be that the connections between power bus and track on the 'certain sections' are marginal in some respect, and this particular loco and decoder combination finds it out.)

[RFS]

I would also suggest verifying the wiring of the problematic sections by doing the simple coin test, ie placing a coin or wire across the rails to ensure that the command station shuts down immediately. If it doesn't, the wiring at the location is not adequate and needs improving. And if you do have a problem here, then I would recommend doing the coin test on all parts of the layout, especially the farthest reaches and turnouts. 

 

This is particularly important in your case as you are using 5-amp power supplies. A short that goes undetected (eg because poor wiring has caused voltage drop) can do a lot of damage if, for example, the short is caused by a derailment on points and the short is flowing through the pick-up wires of the loco. 

Edited September 13, 2019 by RFS