What's the ideal track voltage?

[Madsing]

Yes, many options here.

You can also have a look at sigrok (https://sigrok.org/wiki/Main_Page) and find/select cheap hardware to go with that free software.

[gavino200]

I believe this is what was going when my trains were running but not responding. From my new favorite site.

 

"Error Detection

The final byte indicates the packet is complete. It also allows the decoders to check the validity of the packet. If the packet is corrupted, a decoder looking at the final byte would find the checksum included is wrong. It would ignore the packet and wait for an uncorrupted one to arrive. This is one reason why the command stations keep repeating the packets over time. A corrupted packet often occurs if dirty wheels or track prevented the whole packet from being read properly."

[Madsing]

Correct, and I finally understand what you meant in the initial post. This has happened to me too. Sometimes, the quality of the DCC connection (through the connectors, tracks, wheels...) is not good enough, there is still power reaching the decoder and the motor but the decoder cannot understand the DCC packets and it discards them, so the train keeps moving at the same speed until it finally gets a valid DCC command packet. This can lead to a train overshooting a platform.

[Wolf]

10 hours ago, gavino200 said:

"Error Detection

The final byte indicates the packet is complete. It also allows the decoders to check the validity of the packet. If the packet is corrupted, a decoder looking at the final byte would find the checksum included is wrong. It would ignore the packet and wait for an uncorrupted one to arrive. This is one reason why the command stations keep repeating the packets over time. A corrupted packet often occurs if dirty wheels or track prevented the whole packet from being read properly."

Oh gosh, I have to look more into this for our club layout. I can only take what I get told there for granted, but by now I even soldered resistors to my front boogeys (N700A and NEX) for digital control to "recognise" the First car on a "block part" (lack of english term, sorry) wich I didnt even understand why as there is so much power consumption (Lights, Decoder for Frontlight), and  it still overshoots into a turnout on times. This could totally be simply the train not stopping early enough because compromised packages too, no?

[inobu]

My initial response on Posted Monday at 05:46 PM explains both aspects of the issue.

Its not only lost packets but voltage drops as well.

 

A voltage drop can still produce a good packet but the rectified voltage can be lower. This lower voltage

is weaker therefore slowing the train down. This occurs over time which effects distance. iTrain cannot

compensate for something it does not know is happening.

 

Voltage is directly proportional to torque. Higher voltage more torque. Higher torque more distance covered over time.

 

Inobu

[Madsing]

2 hours ago, Wolf said:

Oh gosh, I have to look more into this for our club layout. I can only take what I get told there for granted, but by now I even soldered resistors to my front boogeys (N700A and NEX) for digital control to "recognise" the First car on a "block part" (lack of english term, sorry) wich I didnt even understand why as there is so much power consumption (Lights, Decoder for Frontlight), and  it still overshoots into a turnout on times. This could totally be simply the train not stopping early enough because compromised packages too, no?

Yes. I really would never do that.

What’s the value of the resistor you had to add? What current detection system are you using?

Do you have a way to check when the sensor is triggering?

[Wolf]

1 hour ago, Madsing said:

Yes. I really would never do that.

What’s the value of the resistor you had to add? What current detection system are you using?

Do you have a way to check when the sensor is triggering?

10k ohms resistor. Its Railware software on a Lenz DCC System. Block is determined by usage of energy, or so I am told. when I put the first car on the tracks before, system at times would not detect "occupation", with resistor now it detects every time without failure. Still overshoots sometimes hence my idea it could be what was mentioned above.

Keep in mind, besides one ICE Set my rolling Stock is basically the first with Motorcars not at the front, PLUS the person who initially build the layout is no longer around, so I would take it even the others at times do a "guess" on a reason.

[Madsing]

Ok. I should not have said “I would never do that”, but “I never had to do that”. 10k ohms is very reasonable and will only generate a current of 1 or a few mA (milliamperes) which is ok. And the conclusion remains the same, a car overshooting can be due to DCC commands not properly reaching the decoder. 
Do you have a way to check when the current sensor triggers?

[Wolf]

4 hours ago, Madsing said:

Ok. I should not have said “I would never do that”, but “I never had to do that”. 10k ohms is very reasonable and will only generate a current of 1 or a few mA (milliamperes) which is ok. And the conclusion remains the same, a car overshooting can be due to DCC commands not properly reaching the decoder. 
Do you have a way to check when the current sensor triggers?

 

Well I reread about the resisitor thing again after your comment, and it seems to be used quite a lot, especially on train Cars that dont consume power, like cargo, to prevent automatisation for example to switch a turnout while the train has still traincars on it. The Software we use (Railware) even states it as a valid technique in its manual, so I am less worried now I did a stupid thing XD (Although the common thing seems to just glue an SMD resistor to an axle instead of soldering a regular one to the pickups like I did because Kato Axles are plastic).

 

The Software shows pretty much realtime the trigger of a sensor and as such the occupation of a track or turnout, but so far I never watched it decently. It happened a few times when we presented our layout, one time the first car shot that far into the turnout it burned the front boogie (plastic deformation) because the turnout was not switched and the first car went onto the turnout, so I just did what people recommended to prevent more destroyed boogies, and didnt look further. As it seems still to happen I will look into this in detail when I have the time now though, especially the commands not reaching properly to the decoder.

[Madsing]

If this can help, in the recent past, I have experienced two other possible causes for a train overshooting a platform.

1. The automation software (Rocrail) was running on a computer connected to the command station (a Roco Z21) over wifi (wifi is the default mode of connection of the Z21 as it comes with its own wifi router). Although the quality of the wifi connection seemed to be good, I experienced intermittent short interruptions of connection (one or two seconds), so the commands could get delayed on their way to the Z21. This problem was solved after connecting the computer and the Z21 over a wired Ethernet connection.

2. I have used a computer running multiple software at the same time. This could delay the processing (something I figured out after analyzing the Rocrail log files). I now run Rocrail on a dedicated Raspberry Pi 4 just next to the Z21.

[gavino200]

On 2/15/2022 at 6:05 AM, inobu said:

The example being a Track voltage of 15 volts will yield a pulse of 13 or 14 volts. CV5 Max Voltage will establish the maximum duty cycle of the

PWM. The voltage does not increase only the frequency of the pulses.

 

 

I was reading about this on the DCCwiki today. There's a great explanation of Pulse Width Modulation. Well explained and simple yet comprehensive. I love the DCCwiki. Pretty much any DCC concept can be found there as well as history.

 

There are nice explanations of attempts to facilitate slow speed driving too, including "Dither" and "Kick Start", that @Madsingwas talking about.

[inobu]

1 hour ago, gavino200 said:

 

I was reading about this on the DCCwiki today. There's a great explanation of Pulse Width Modulation. Well explained and simple yet comprehensive. I love the DCCwiki. Pretty much any DCC concept can be found there as well as history.

 

There are nice explanations of attempts to facilitate slow speed driving too, including "Dither" and "Kick Start", that @Madsingwas talking about.

I have somewhat of an advantage as I worked as a Data Network Test Engineer in a lab. That afforded me an in depth knowledge of data transmission, signal multiplexing,

data protocols and such. When I started back into the Hobby and switch to DCC I could see exactly what they were doing. Most of my posts were over looked because it seem like non-sense, irrelevant or crazy.

 

If you look back in my post I mentioned torque and voltage being an issue with time/distance based control. There are a lot of detains of getting it right.

 

Dithering for example is a derivative of Quantizing in the data world. In the data world the sampling rate would effect the clarity of the reproduction of the signal. The similar

technique is used for the motor control. This all falls back to match your track voltage with your motors.

 

All of the Dither and Kick Start comes after the track and wiring is ironed out and up to par. Because many modelers don't pay attention to detail they need to use the

kick start and such to compensate for the abnormalities in the layout. 

 

DCCwiki is a good site and I reference it as I'm starting to forget things. The only warning it DCC CV's have a cause and effect and you have to know what does what and

how it can effect something else. If not you will be running around in circles.

 

Inobu

 

 

 

[gavino200]

10 minutes ago, inobu said:

The only warning it DCC CV's have a cause and effect and you have to know what does what and

how it can effect something else. If not you will be running around in circles.

 

Inobu

 

I agree. CV programming seems to be a bit of a dark art. I've barely scratched the surface. I'm planning on standardizing to as few different decoders as possible so I can learn in more depth how they work.

 

Likely, I'm gong to use an ESU LokPilot V.5 Micro DCC decoder for almost all intallations, unless I need something smaller (D&H nano). Apart from that I'll probably use Zimo for Kato drop-in decoders. That will leave me with about 30 odd decoders, that I've already installed, to learn better. So far only one doesn't play well with iTrain. My 30 various decoders are all a mix of Kato, Digitrax, ESU, D&H, Lenz, TCS. I have two sound decoders, one SoundTraxx and one ESU. Probably I won't get any more sound.

 

For now I'm going to focus on learning everything I can about how the LokPilot works.

[inobu]

 

1 hour ago, gavino200 said:

For now I'm going to focus on learning everything I can about how the LokPilot works.

 

Lok/ESU is the way to go. Back in 2020 I mentioned switching to ESU and the switch is worth it to me. If you like juggling trains the ECoS is the system to do it with.

The decoders are getting better and better with each upgrade.

 

I've said it before.....Get the Lok Programmer and decoder tester ( if you haven't already ) and make a test rig.  It really works well with one another.

 

Inobu

[gavino200]

4 minutes ago, inobu said:

 

Lok/ESU is the way to go. Back in 2020 I mentioned switching to ESU and the switch is worth it to me. If you like juggling trains the ECoS is the system to do it with.

The decoders are getting better and better with each upgrade.

 

I regret a bit going with the Digikeijs instead of the ECoS. But unless I find a major problem with the DR5000 I'll stick with it now.

 

4 minutes ago, inobu said:

 

I've said it before.....Get the Lok Programmer and decoder tester ( if you haven't already ) and make a test rig.  It really works well with one another.

 

Inobu

 

I do have an ESU decoder tester which I like a lot. I've considered getting a LokProgrammer, but I don't plan on using sound decoders at the moment. And the programming function on iTune together with my programming track seems plenty good.

 

Can you describe your programming rig?

[inobu]

9 minutes ago, gavino200 said:

Can you describe your programming rig?

 

You can test everything with in a few minutes. Plug a new decoder in the tester and you can test everything out.

Install the decoder and place it on the track. Select N or Ho on the switch to the left and run it on the track.

 

 

 

 

With the Lok Programmer software you can operate the loco on the test track

 

 

 

Inobu

[gavino200]

That's a very clean setup. As always top marks for aesthetics and functionality, inobu!!!

 

I generally just use my decoder tester by attaching it to the tracks using tiny test wires. I've used small track lengths with rerailers and buffers, right beside my command station before. This time I'm planning on building my test track into my layout, at a location close to the command station/computer. That way I can drive my locos in and out for programming.

 

I'm going to use this basic design. Maybe I'll hide a switch and LED under a removable building.

 

The LokProgrammer software looks nice. But so is the programming screen in iTrain. I'll get a LokProgrammer if I get into sound. But until then I'll probably hold out.

 

[chadbag]

I bought a decoder tester -- I think it is Zimo -- I have to go find it.  I have not installed or tested it yet as our house project takes priority.  I have a similar setup with my D&H programmer hooked to a small test track and I can control the trains from the software.  The software is OK for Windows software...   The D&H programmer will program any brand of decoder for standard DCC type things.  Obviously brand-specific things like sound won't work if not D&H.  I suspect any of the branded programmer boxes are the same.

 

Eventually I plan on getting the ESU command station, a Z21, the new TCS, etc. in order to make sure my software I am writing is compatible with them all.  That is long term and not short term.  I am happy with my DR5000 now.  I'll probably end up with an ESU and a ZIMO programmer as well.  I only have one or two ESU decoders, and 2 or 3 Zimo, but will probably get more of each, though I will buy more D&H to build the EM13 boards with as I have many more trains to add DCC to that use EM13 style boards.  Depending on cost I may also just buy Zimo ones.

 

I basically right now am D&H/TCS with some Zimo and as mentioned, a couple ESU.  I only use the TCS ones that are drop-in for locomotive light boards.  I don't use the discrete wired ones.

 

[chadbag]

I did buy these ESU RailCom transmitter units -- not tried them yet.  And this is my decoder tester. I have a blown TCS and a couple D&H decoders to test to see if they really are blown 🙂.  Both of these came from http://www.sbs4dcc.com

 

 

 

[gavino200]

18 minutes ago, chadbag said:

I did buy these ESU RailCom transmitter units -- not tried them yet.  And this is my decoder tester. I have a blown TCS and a couple D&H decoders to test to see if they really are blown 🙂.  Both of these came from http://www.sbs4dcc.com

 

 

That's interesting. I didn't know you could do that. Though space is usually an issue, and I can't imagine opening a previous installation to splice one of those thingies onto it. But they're reasonably cheap, so I'll bear them in mind.

 

My tester is this ESU version. It's essentially the same as your D&H. I also made a jig to connect an EM13 to it for testing, though I've been meaning to remake it a bit better. Connecting the EM13 can be a hassle.

 

[gavino200]

I have to say the following quote from Iain at the iTrain forum has stuck in my head.

 

"The DCC signal produced by the DR5000 as supplied is poor, looking more like a noisy sine wave than a clean square wave, and this can, and often does, result in poor control. A significant improvement in the DCC output can be achieved by purchasing a decent quality SMPS to replace the DK supplied SMPS."

 

If there's any truth to it, then it seems like an obvious thing to try. Doing a little searching for "Power supply 17V 3amp" I get a plethora of different offerings. I really don't have any way to sort them out by quality. 

 

Does anyone know of a brand or model of Power Supply that I could rely on to produce a good quality output?

[Rob2160]

Hello all,   New member and my first post after reading through this thread I thought I would add my experience. 

 

I have an old NCE Power Cab (purchased in 2009) and it came with a 16 volt - 1.5 amp power supply.   Later that year I also purchased the Bachmann 5 amp booster (comes with an 18 volt / 5 amp power supply.) 

 

The voltage measured on the track from the Power Cab alone is 15.9 and when using the Booster is 16.05 on my meter. 

 

I have run N-Scale / HO and G scale trains on this system for 14 years with zero issues.   Atlas N-scale with Lenz decoders factory fitted,  Kato N-Scale with NCE and Digitrax decoders and even the Kato passenger cars like the California Zephyr which have small lights on the rear carriages operate no issue.   More recently a couple of BLI with sound N-scale models too. 

 

Also dozens of HO locos,  MTH,  Atlas Gold,  BLI,  Proto DCC/Sound,  Bachmann factory fitted DCC, Marklin and most of the Thomas and friends Bachmann line with TCS decoders I installed myself.  

 

In 14 years these would have over 3000 hours of combined running time across 100+ locomotives without a single decoder or loco failure.

 

I hope this helps as the 16 Volt has been 100% fine for me.  

 

My layout for the kids in 2009... running on the Bachmann 5 amp booster.  All DCC. 

 

 

[Wolf]

Taking the oppertunity to raise the flag for #Team16V here as well, as this is what my club's layout (lenz as well) runs on too, never had an issue to the voltage.

As for the issues I had mentioned a year ago, I can by now clarify that the issue was the person dealing with the trains (so my own fault) and not the layout, by now i can "stop" all my trains without the need of stupid resistors pretty much on point, and if not am able to usually determine the issue on the train, not to track.

[Rob2160]

For what it is worth I just tested two other units I have. 

 

1.  Digitrax Zephyr Express - power supply states 13.8 volts / 3.6 amps.  Measures 14 volts DC and gives 14.8 volts on the track

 

2.  Bachmann Dynamis - power supply states 16 volts / 2.3 amps.  Measures 16.2 volts DC and gives 16.2 volts on the track

 

I used the Dynamic heavily for two years with my N-scale equipment and everything worked fine.  I am convinced the 16 -16.2 volts is perfectly fine for N and HO scale despite based on my own experience.