Block detection and automation test/practice layout

[Martijn Meerts]

I think according to the DCC spec, the 'correct' way to handle CV03 is to actually limit the speed steps. CV53 (and the other ones ESU uses for motor control) are custom CVs. But internally the Digitrax decoders might handle CV03 differently, as long as limits the max speed.

 

And yes, trains do often run different after they've warmed up a little bit, but I've not noticed that big of a change. The biggest change I usually see is that they run somewhat smoother, but not significantly faster.

 

[gavino200]

Marc, I also notice a significant difference between a cold and a warmed up loco.

 

I've been setting up my speed "curves" in a roughly similar way to both of you, however I've really just followed the example of the iTrain video tutorial.

 

The first thing I do is set CV3 and CV4 to 0.

Then I set the inertia simulation in iTrain which will take their place.

 

I haven't played with the inertia simulation values in iTrain yet, though I will later.

 

Next I set the maximum speed. I look up the prototype max speed on wikipedia.

Then I I arbitrarily guess at a value for CV5 and measure the loco speed at the top speed step.

Then I alter CV5 to get closer to the desired max speed and measure again.

Rinse and repeat until the CV5 value produces the correct top speed.

 

Next I use a similar process to set CV1, except I don't really measure the speed but rather eyeball what looks like a suitable shunting speed that the loco performs smoothly at.

 

Next, I leave the loco running on the speed measurment mode of iTrain with intervals of 5 steps in both direction to produce a speed "curve".

Curve is in quotes because they're generally slightly wiggley straight lines.

 

I don't use CV6 because I don't really see any point. Maybe I will later.

 

These are the CVs for my Hustle Muscle, a US diesel electric loco

 

And this is the speed curve (I actually chose a non prototypical max speed for this loco)

 

 

 

 

[gavino200]

At first, I thought this method would allow me to use all the speed steps within the chosen range. That's how Bob Fuller in the video series described it. But what Martijn and a guy on the iTrain forum mentioned makes me wonder.

 

Iain from iTrain: "NB, I don't not adjust CV5 to set max speed, I use CV57 which is max apparent voltage on the motor - otherwise they are set in exactly the manner I describe in the video."

 

To this point I've been able to set up around 20 locos using this method. I've only failed with three. I'm going to try to get these working before moving on. Two are bricked, and one is the Super Rail Cargo with the Digitrax DZ123 that can't be set with a reaction delay. I'm currently reading through the Digitrax Decoder Manual trying to understand why my loco is having problems.

 

I'm also going to re-watch the tutorial video where Bob Fuller talks about using the Default DCC CV menu versus making custom lists for different locos. I'm going to try to make different CV menus for most of the main decoders that I have. An idea suggested to me by a guy on the iTrain forum was to keep an excel file of the various CV and iTrain settings that work well for different Decoders and Locos. I'm going to do this also.

 

[gavino200]

I put the following post on the Digitrax forum. This is my best attempt at describing the problem.

 

I'm using the iTrain automation software with a Digikeijs DCC system. I'm currently setting up my locos to work with iTrain. The only decoder so far that's having problems is a DZ123 that's in a Kato loco.

The loco/DZ123 has always worked fine in regular manual DCC function. It also works fine manually in iTrain. The problem is with setting something called "Reaction delay". This is a feature in iTrain that adjusts for the physical momentum of the train so that the software can make the loco stop in the right place.

It's recommended that CV3 and CV4 be set to zero. That is the Decoder's accel/decel be disabled. Instead the iTrain software provides it's own simulated inertia to compensate.

Then you have to set "reaction delay". You set an automatic train route where the train stops at a desired point. If the train overshoots the mark, then you increase the reaction delay until it stops at the right point. If the train undershoots the stopping point then you decrease the reaction delay until it stops at the right point.

The problem with the DZ123 is the following:

The train overshoots by a lot. I keep increasing reaction delay. The delay has to be increased to an unusually high level to decrease the amount that it overshoots by. But instead of actually getting to the point where it stops at the right point, adding a small extra amount of reaction delay causes the train to undershoot by a LOT. The same thing then happens in reverse.

What CVs in the DZ123 might be causing this? Any suggestions to fix this?

 

I wonder if "Torque Compensation" could be the culprit?

 

 

 

Below are the CV values to turn it off. I don't understand what it means when they give the value as 017/x11. Does that mean I set CV54 to 017? So what of the x11?????

 

Edited February 12, 2022 by gavino200

[Madsing]

Hi Gavin, still reading your post. It’s interesting. 
x just means hexadecimal. “17” in hexadecimal is “11”. It’s useful if you need to know or set the individual bits in the CV. 
Marc

[gavino200]

Thanks Marc. I'm going to play around with CV54-57 this morning and see if I can get this thing to work in iTrain.

[Martijn Meerts]

I think, in the end, it doesn't matter if you use CV05 for speed or something else, the result will mostly be the same. CV05 changes the pulses to the motor, ESU CV53 changes how BEMF affects the motor, including max speed. Neither method directly affects the voltage going to the motor.

 

I think CV05 on most, if not all decoders these days doesn't limit speed steps anymore, and even if so, the internal speed steps should be able to compensate. It really is only a potential issue when you have to lower CV05 to very low values.

 

[gavino200]

I tried a few things. The problem is now slightly different but not solved.

 

After reading the Digitrax manual the only CVs that I found that might be involved were fore BEMF and Torque Compensation. I turned them both off.

 

 

I tried setting the reaction delay. I can get the train to stop in one direction by setting a very high reaction delay. But in the other direction it stops a LONG way short even with reaction delay at a minimum.

 

I tried increasing CV4 to different values. I also tried changing the simulated inertia in iTrain both step delay and step size. No improvement.

 

 

I posted the question on the Digitrax forum and got an interesting answer:

 

"Have you got RailCom enabled or disabled in the Digikeijs system ?    I’ve known DZ123’s become troublesome if there are Railcom signals on the track."

 

I don't want to turn off RailCom as I plan on using it.

 

There are also people on the iTrain forum who have said that they could never get their Digitrax decoders to work on iTrain and ended up just replacing them. I'm prepared to do that but would rather not.

 

I know that the Digitrax owner had a massive fight with the rest of the model train world over Trainsponding vs RailCom. Could it be that he knobbled his decoders so that they wouldn't work with RailCom. I'd love to hear any reports to the contrary - Digitrax decoders working fine in the presence of RailCom. This decoder is working fine in regular manual mode. It's just behaving erratically with iTrain reaction delay. I'm going to ask the question again in the iTrain forum. I mentioned it in passing in conjunction with a different problem, but I'll make a designated thread about it now. The risk is that, while they're friendly and helpful in general, they're also often easily irritated and borderline rude at times.

 

This is the response from Iain (from iTrain) on the iTrain forum

 

"Haven't heard of issues that can be specifically directed at Digitrax, but it is known that some decoders provide better control than others - even within the same OEM. Personally I just stick with Zimo which provide me with excellent control."

 

There's a thread right below it in which a regular user describes having not been able to get his Digitrax decoders to work in iTrain and that he had to replace them all. I'm not sure if there's a little bit of "see no evil, hear no evil" going on there. I'm sure they don't want do discourage potential customers.

Personally I just stick with Zimo which provide me with excellent control."

 

 

Edited February 12, 2022 by gavino200

[Martijn Meerts]

You could disable Railcom temporarily at least, just to see if that has any effect on the decoder. 

 

There's no logical reason why Digitrax decoders would have difficulties with iTrain, since iTrain just sends standard DCC commands. The only reason why Digitrax would have problems with that, is if the decoders don't implement the DCC commands correctly, which seems rather unlikely.

 

As far as I know, the whole issue with transponding was mainly that Digitrax was being difficult releasing the protocol of it, so third parties weren't easily able to support it. I never heard anything about there being a massive fight or anything. Railcom does send some extra data over the DCC bus of course, so if the decoder is slow at handling that data, it might get backed up on commands, but that seems unlikely to me.

 

I've not done anything in iTrain in a long time myself, so I'm not really familiar anymore with all of the settings. Unfortunately my motivation is nowhere near enough to do any work on the N-scale layout, so I probably won't be looking at iTrain anytime soon either 🙂

 

[gavino200]

1 hour ago, Martijn Meerts said:

You could disable Railcom temporarily at least, just to see if that has any effect on the decoder. 

 

I will.

1 hour ago, Martijn Meerts said:

 

There's no logical reason why Digitrax decoders would have difficulties with iTrain, since iTrain just sends standard DCC commands. The only reason why Digitrax would have problems with that, is if the decoders don't implement the DCC commands correctly, which seems rather unlikely.

 

I agree. But there are numerous accounts of people having difficulties with them.

 

1 hour ago, Martijn Meerts said:

 

As far as I know, the whole issue with transponding was mainly that Digitrax was being difficult releasing the protocol of it, so third parties weren't easily able to support it. I never heard anything about there being a massive fight or anything. Railcom does send some extra data over the DCC bus of course, so if the decoder is slow at handling that data, it might get backed up on commands, but that seems unlikely to me.

 

It seems to have been a fairly bitter thing. The though crossed my mind that there might have been a bit of spite involved. Though more likely Digitrax have added usability features into their decoders to make them as plug-n-play as possible that fight against iTrain.

 

 

1 hour ago, Martijn Meerts said:

 

I've not done anything in iTrain in a long time myself, so I'm not really familiar anymore with all of the settings. Unfortunately my motivation is nowhere near enough to do any work on the N-scale layout, so I probably won't be looking at iTrain anytime soon either 🙂

 

 

Thanks, Martijn. It's nice to know I'm not the only one who forgets this stuff.

 

 

[gavino200]

Moving on to the next phase. I'm taking my four tried-and-tested trains to a layout with a station and three sidings. All the basics are working.Time to see what iTrain can do.

 

 

Behold the horror that is on-table wiring.

 

[Martijn Meerts]

I've seen (and built) plenty layouts where the wiring looks like that under the table, in parts where you can't really reach it for any sort of problem solving 🙂

 

[Wolf]

As I postet on a different Topic, our Club Layout running Railware on Lenz Hardware has issues with Digitrax as well, its kind of hit and miss.

I found that disabling the 3 Step Speed Table especially on the replacement DCC Board "DN163K4A" (wich I have in my DE10s as well as plan to slap into the EF510). I would need to ask my mates at the club if I would need to find out how they actually turned that off tho.

Just thought could help to mention that Railware seems to have issues too.

[gavino200]

On 2/14/2022 at 4:08 AM, Wolf said:

As I postet on a different Topic, our Club Layout running Railware on Lenz Hardware has issues with Digitrax as well, its kind of hit and miss.

I found that disabling the 3 Step Speed Table especially on the replacement DCC Board "DN163K4A" (wich I have in my DE10s as well as plan to slap into the EF510). I would need to ask my mates at the club if I would need to find out how they actually turned that off tho.

Just thought could help to mention that Railware seems to have issues too.

 

Thanks. I'll keep this in mind. For the moment I'm getting rid of my DZ123 as even Digitrax admit that it's "problematic". I won't be getting any more Digitrax decoders but I'd reather be able to avoid reinstalling the one's I already have installed.

[gavino200]

I'm in the process of re-reading the entire iTrain manual. All 233 pages of it. Now that I have a decent idea of the basics, it's making much  more sense to me. When I read it first I was totally lost.

 

I'm in Phoenix at the moment, and had an opportunity to chat with one of the local gurus at a brick-and-morter trains store. Among other things we talked about DCC and automation. He told me some funny stories about a local train club that's heavily into technology. They dived in deep to automation and got so lost they had to completely give up, take everything apart and start again. This guy, Obie, was a bit of a tech-skeptic, so he was really playing up the story, and making us laugh. But it made me feel better about the struggle I've had learning this software. I'm super glad I'm learning this on a temporary layout. If I was trying to make this work on a main layout that I was separately invested in, I'd be pulling my hair out by now.

 

I've also been re-reading my Digikeijs manuals. I'm ready to configure a second detection unit. I still find the sections on configuring different connection/communication methods, difficult to understand. I'm only partially familiar with networking language. But I want to decide how I want to set up my system before moving to the main layout.

 

Currently I'm using a USB to connect my laptop to the DR5000. I'm going to re-eval alternatives again, including ethernet, and RasPi.

 

 

[Madsing]

55 minutes ago, gavino200 said:

I've also been re-reading my Digikeijs manuals. I'm ready to configure a second detection unit. I still find the sections on configuring different connection/communication methods, difficult to understand. I'm only partially familiar with networking language. But I want to decide how I want to set up my system before moving to the main layout.

How is the detection unit connected to the DR5000?

[inobu]

Get a sheet of the 2" Pink or Blue foam and cut it down to your test track size. Use hot glue to tack

the primary radius down to the track. This will prevent the track from moving. You can drill holes

to drape your wiring below. It keeps things neat on top plus you can move it around.

 

Tacking the track down keeps the track from walking or moving ever so slightly as the train moves

around the track.

 

Your next step is to speed match all your trains so everything is consistent.

 

https://yankeedabbler.com/accutrack-ii-model-train-speedometer-scale-ho-n-oo-yankeedabbler-part-66-accutrack-ii/

 

This allows you to dial in your speed steps. Right now you are shooting in the dark.

 

Inobu

 

[gavino200]

1 hour ago, Madsing said:

How is the detection unit connected to the DR5000?

It's connected by loconet for communication and two track output wires for power.

 

[gavino200]

39 minutes ago, inobu said:

Get a sheet of the 2" Pink or Blue foam and cut it down to your test track size. Use hot glue to tack

the primary radius down to the track. This will prevent the track from moving. You can drill holes

to drape your wiring below. It keeps things neat on top plus you can move it around.

 

Tacking the track down keeps the track from walking or moving ever so slightly as the train moves

around the track.

 

At the moment I'm tacking it down using nails pushed into the foam. It's working ok.

 

 

 

39 minutes ago, inobu said:

 

Your next step is to speed match all your trains so everything is consistent.

 

https://yankeedabbler.com/accutrack-ii-model-train-speedometer-scale-ho-n-oo-yankeedabbler-part-66-accutrack-ii/

 

This allows you to dial in your speed steps. Right now you are shooting in the dark.

 

Inobu

 

 

All the locos are speed calibrated using iTrain. Later I'll probably buy a direct speed measurment device. I'm considering the uconn (the u is a mu) as it's recognized by iTrain. It's more expensive. But I'll check this one out too. Thanks. I also have one made using Marc's design but I'd have to look into integrating that.

[inobu]

17 minutes ago, gavino200 said:

 

At the moment I'm tacking it down using nails pushed into the foam. It's working ok.

 

 

 

 

All the locos are speed calibrated using iTrain. Later I'll probably buy a direct speed measurment device. I'm considering the uconn (the u is a mu) as it's recognized by iTrain. It's more expensive. But I'll check this one out too. Thanks. I also have one made using Marc's design but I'd have to look into integrating that.

As long a the track is secured you are good to go.

 

Being able to move the speed device is key as you can find the spots where the speed varies. It is the variations that has you chasing the ghost.

 

Inobu

 

 

You want to get something outside of iTrain to validate the speed.

[gavino200]

4 minutes ago, inobu said:

 

Being able to move the speed device is key as you can find the spots where the speed varies. It is the variations that has you chasing the ghost.

You want to get something outside of iTrain to validate the speed.

 

That's a great thought. It would be nice to have the device communicate with iTrain to avoid tedious data input. But I need to make sure that the device gives me a direct speed read, independent of iTrain so I can use it to calibrate iTrain. Thanks, inobu!

[cteno4]

Might think of soldering some 18g feeds directly to the undersides of the tracks. It makes a very solid connection to the tracks. Using feeders with plugs winds up in many crimps that potentially could e a little wonky and small gauge wires.

 

jeff

[gavino200]

1 minute ago, cteno4 said:

Might think of soldering some 18g feeds directly to the undersides of the tracks. It makes a very solid connection to the tracks. Using feeders with plugs winds up in many crimps that potentially could e a little wonky and small gauge wires.

 

jeff

 

Yes, I switched to doing that a while back. This practice layout still has some joiner-soldered feeders. But I never thought about this as a trackwork practice layout. Only a way to learn iTrain.

 

The temporary DC layout is even worse in that regard. It has a bare minimum of feeders. When we start building the real layout I'll be doing the wiring for real, trying to make it as bulletproof as possible. I may even consider soldering some of the rails, though I need to learn about that first.

[cteno4]

Just thinking of removing variables from your test setup. Even spacing of feeders as well.

 

jeff

[gavino200]

1 minute ago, cteno4 said:

Just thinking of removing variables from your test setup. Even spacing of feeders as well.

 

jeff

 

Ah, yes. It's very small. There's one feeder per feedback section. At the moment one feedback per block. They're not all the same length, but fairly close.