Block detection and automation test/practice layout

[Martijn Meerts]

Any reason you're running 28 speed steps instead of 128? Your system and decoders should be able to handle 128 steps, which makes the acceleration and deceleration quite a bit smoother. Just don't do a speed measurement on every step if you do go 128 steps 😉

 

[gavino200]

4 hours ago, Martijn Meerts said:

Any reason you're running 28 speed steps instead of 128? Your system and decoders should be able to handle 128 steps, which makes the acceleration and deceleration quite a bit smoother. Just don't do a speed measurement on every step if you do go 128 steps 😉

 

 

Good to know. Thanks! I'll redo it with 128 steps. 

 

It occurred to me while doing this that a fully loaded train is going to be slower than a loco by itself. I'm guessing there's a way to speed measure a full train. That will be my next investigation, I think. 

Edited May 10, 2021 by gavino200

[Martijn Meerts]

Theoretically, you could measure EMU/DMU and the like as a full set (as long as they only have 1 motor car), since those will always be running as a full set. A loco however can haul whatever you want, and most software allows you to specify things like the weight of various cars, and if you hook those up to a loco in the program, the program will simulate the load.

 

Theoretically, the decoders should keep the speed around the same regardless of whether you have just the loco running, or the loco with a string of cars. It's the same system the decoders use to regulate the speed of a loco when going up or down a slope.

[gavino200]

12 hours ago, Martijn Meerts said:

Theoretically, you could measure EMU/DMU and the like as a full set (as long as they only have 1 motor car), since those will always be running as a full set. A loco however can haul whatever you want, and most software allows you to specify things like the weight of various cars, and if you hook those up to a loco in the program, the program will simulate the load.

 

Theoretically, the decoders should keep the speed around the same regardless of whether you have just the loco running, or the loco with a string of cars. It's the same system the decoders use to regulate the speed of a loco when going up or down a slope.

 

Interesting. I'm pretty sure mine used to slow down going up inclines and speed up going down. But maybe it would have been worse without this mechanism. 

 

I changed my speed steps to 126. The program automatically spread out the measurements I had taken with 28 steps. So I didn't have to redo them. 

 

I now have three locos done. Some go more smoothly than others. I'm found, especially on one loco, a dapol, that I got the following error a lot, especially at the lower end of the speed curve. The value would just go directly to something massive and the process would stop. The only way to continue was to clear the value and try again. Sometimes I had to do this multiple times. 

 

 

I really need to set up a very short block for the low speed measurements. Waiting for the train to cross the block at the lower speed steps is like waiting for an actual train when you're in a hurry. And when it occasionally misses it's mark and keeps going at an inch hour.........Well, I guess it's good for developing patience.  

 

I'm beginning to wonder how good a system DCC communication actually is. It seems that there are a lot of misreads and miswrites to and from decoders. One of my decoders won't read but I can still write to it. Weird. I need to learn more about how these things work. 

 

 

[Martijn Meerts]

It can vary for each decoder, not all decoders implement it, others don't implement it really well, yet others have it but turned off by default etc. It's the Back EMF that's used for it, so you could have a look at that. I know that ESU decoders allow you to set up Back EMF settings for low speed running separately from high speed running, but wrong settings make the loco run pretty terrible.

 

The slow speed measurements is mainly why I bought hardware specifically for speed measurements, it just saves a lot of time. And depending on the occupancy detectors you use, it's also more accurate. Most occupancy detectors don't send a signal to the command station when they become occupied, but wait for the command station to poll them to check their status. This can cause minor delays between the loco entering the detected station, and the software getting the status. At high speeds that can make speed measurements somewhat incorrect.

 

As for decoders not reading but allowing to be written to, or those function decoders by any chance? Unless they have Railcom or Transponding, a function decoder that's only driving head / tail lights for example isn't drawing a lot of current, and then can't be read. It's a bit of an annoyance with many function decoders.

[gavino200]

4 hours ago, Martijn Meerts said:

It can vary for each decoder, not all decoders implement it, others don't implement it really well, yet others have it but turned off by default etc. It's the Back EMF that's used for it, so you could have a look at that. I know that ESU decoders allow you to set up Back EMF settings for low speed running separately from high speed running, but wrong settings make the loco run pretty terrible.

 

I don't think I've ever really changed CVs except to address the decoders. But I do want to look into that more in the future. 

 

 

4 hours ago, Martijn Meerts said:

 

The slow speed measurements is mainly why I bought hardware specifically for speed measurements, it just saves a lot of time. And depending on the occupancy detectors you use, it's also more accurate. Most occupancy detectors don't send a signal to the command station when they become occupied, but wait for the command station to poll them to check their status. This can cause minor delays between the loco entering the detected station, and the software getting the status. At high speeds that can make speed measurements somewhat incorrect.

 

I think I'll be doing that. I really don't have the patience for speed measuring a snail, over and over again. 

 

 

4 hours ago, Martijn Meerts said:

 

As for decoders not reading but allowing to be written to, or those function decoders by any chance? Unless they have Railcom or Transponding, a function decoder that's only driving head / tail lights for example isn't drawing a lot of current, and then can't be read. It's a bit of an annoyance with many function decoders.

 

It's a D&H in a DD16. It read fine at first, but now not at all. Maybe it will work again on "reboot" (???). 

[Martijn Meerts]

Hmm.. You could try a factory reset on that decoder yes. I have to say, I have had decoders start failing for no apparent reason before. Most just stopped responding, others weren't possible to write to anymore. Interestingly, the ones that had issues writing to were usually Selectrix decoders, which are manufactured by D&H. I've also had 1 catch fire, which might have been caused by a short. But it only happened several years after it was installed in a train that ran quite a lot.

 

Decoders are just weird at times 😄

 

[gavino200]

10 hours ago, Martijn Meerts said:

Hmm.. You could try a factory reset on that decoder yes. I have to say, I have had decoders start failing for no apparent reason before. Most just stopped responding, others weren't possible to write to anymore. Interestingly, the ones that had issues writing to were usually Selectrix decoders, which are manufactured by D&H. I've also had 1 catch fire, which might have been caused by a short. But it only happened several years after it was installed in a train that ran quite a lot.

 

Decoders are just weird at times 😄

 

 

I actually did factory reset it. Then it responded to address 3, but still wouldn't read. I put it back to it's chosen address and it took it. 

 

Today I tried it again. It still wouldn't read on the program track, but oddly enough, I could read all but one CV on the main track. Other locos are reading fine on the program track, so I don't think it's a problem with iTrain or the DR5000. 

 

I'm actually really liking the iTrain decoder programming function. Everything is going well so far. Next up, I'll work on programming stopping distances, for the locos that I have speed data on. 

 

I found this guy on YouTube. He does iTrain tutorials that a bit more quick and to the point than Bob Fuller, though I think Bob's videos are also very useful. 

 

 

[chadbag]

One thing I have seen with regards to cv read and write is the voltage the control center is putting out. I tend to set the input voltage to my programmer ( D&H programmer) 14v or 15v and it works better than when I was using 12V or 13v

[gavino200]

49 minutes ago, chadbag said:

One thing I have seen with regards to cv read and write is the voltage the control center is putting out. I tend to set the input voltage to my programmer ( D&H programmer) 14v or 15v and it works better than when I was using 12V or 13v

 

That's interesting. With the DR5000, how do you do that? Set it for HO? O gauge? Is it possible to configure the program track higher than the main? Or do you have to switch over and back every time?

 

If D&H decoders are designed to be read at a higher voltage that would make sense why it reads on main but not on the program track. 

Edited May 11, 2021 by gavino200

[chadbag]

It all depends on the input power on most of these command centers and programmers. I haven’t tried much programming on the main with the DR5000 as I just use the D&H programmer and my input power block I use with it is variable and lets me adjust it.   I forget which power supply I have on the DR5000. 
 

 

[gavino200]

I rearranged the circuit for the Yukari arduino speed measurment device, with the proper distance between the sensors, and tried it out on the layout. It works well. I have to enter the speed data by hand, but at the low speeds that's still quicker than the track method unless I use a very short feedback segment. 

 

I'm noticing that I probably almost never drive my trains at scale speed. These things are seriously fast!

 

Edited May 14, 2021 by gavino200

[gavino200]

I finally worked out what was causing this weird error in my speed measurements. It happens when the locos stop before both trucks have crossed out of the center measurement zone. When the loco turns It is already in the measurement zone at time zero, which makes no sense to the software. So it gives an error. 

 

It's easily avoided by simply moving the loco along a bit by hand, fully out of the measurement zone. I think it won't occur if I to the start/stop accuracy adjustments first and then do the speed measurement. I believe that's the order that Bob Fuller did these processes in. Now I know why. 

 

[Madsing]

2 hours ago, gavino200 said:

I'm noticing that I probably almost never drive my trains at scale speed. These things are seriously fast!

Yes, yes, yes! We usually run our trains too fast! They look much better (more prototypical) at lower speeds. 

[Madsing]

I am looking for a way to automate the whole process. Maybe the Arduino could send speed change DCC commands, measure the speeds over the whole range, then write speed calibration CV values directly into the decoder…

[gavino200]

5 minutes ago, Madsing said:

I am looking for a way to automate the whole process. Maybe the Arduino could send speed change DCC commands, measure the speeds over the whole range, then write speed calibration CV values directly into the decoder…

 

Yes, I was just thinking about this. I bet there's a way to do that. I'm sure I've seen a project where an arduino is used to make a DCC decoder. I want to do this in order to understand better how a decoder works and how I could interact with it.  I bet the Yukari speed meter could be adapted to communicate with iTrain just like a uComm commercially available device that Martijn uses. 

 

 

[gavino200]

I have a little stable of speed measured locos now. Most are some ugly US trains that I used because they have a clear front and back. I also used a DD16 and the three car base set of the E5. Seeing a Shinkansen running again just makes me happy. 

 

My next challenge is to make a "Reaction Delay Shuttle". I set one up using Bob Fuller's instructions. As expected it didn't work. I'm sure there's a step left out, or that I misunderstood his instructions somehow. I'm going to search for other sources and try to get passed this obstacle. Reaction delay settings are my automation goal for the weekend. 

 

I can't execute the reaction delay shuttle. I get a "route not possible from this location" error. 

 

So far this is what I've done. 

 

Train route "Reaction delay shuttle" as shown. 

 

 

Place the train digitally on it's mark

 

 

Train physically located on the same mark

 

 

Error

 

 

My stable of speed measured locos. DD16 and some uglies. 

 

[Martijn Meerts]

Speed measurements can be automated in iTrain, you just select multiple speed steps, and it'll do those in order, going back and forth. I believe you can also read the speed while just running trains, but I can't quite remember if that was iTrain or some other program I've tried/used. Pretty sure there was 1 where you could monitor a train's speed and act on if it deviated too much from what it should be.

 

[gavino200]

No luck at all getting my "Reaction Delay Shuttle" to work. Basically this is just a "Train Route" used for finetuning braking distance. I keep getting the error "route not possible from this position.  I'm just going to leave it for now. I bet when I learn about train routes in detail the problem will be obvious. I don't thing the stopping distance finetuning is quite as crucial as I had assumed anyway. 

[gavino200]

I decided to open a new project and set my simple loop up again. This doesn't take long and I get better at it each time. I'm starting to get a better familiarity with what I'm trying to do. 

 

Right now I'm having a problem with the feedbacks. I think it's something related to how the DR5000 is interacting with iTrain. I've posted a question on the Digikeijs formum. I also found an iTrains forum, but unfortunately my account seems to need to be approved, so I'll have to wait. In the meantime, I'm looking for the answer in the iTrain manual.

 

This is the question I asked at Digikeijs. I'm not really sure how to phrase it better.

 

"I have a DR5000 working with a DR5088RC for block detection. Both are connected to a simple loop with five blocks and no turnouts. Everything is connected to iTrain. 

I think the Digikeijs equipment is working. I had it working before on a different practice loop. The feedbacks briefly flash red repeatedly when there is a loco on the track they represent. But it doesn't stay red like it should. 

When I drive the loco manually, there is a brief flicker of red instead of the feedback lighting up red. When I use the view->feedback monitor -> DR5000, it shows the five feedbacks that I'm using in white like it should, but it doesn't show any as active or detected in blue, as it should. 

Any ideas?"

Edited May 16, 2021 by gavino200

[gavino200]

Finally a breakthrough! It was a Digikeijs issue and not an iTrain one. I hadn't turned off the S88 input so the Command Center was getting confused. Block detection is running smoothly in iTrain now. My train routes are running with no error messages. Slight problem is that the stop function worked on the first shuttle run, but not after that. That will be a trouble shooting issue for another day. 

 

It's really all starting to come together. 🙂

[Martijn Meerts]

Ah, so the command station was expecting S88 feedback, but was getting something else? I don't know anything about the Digikeijs command station 🙂

 

[gavino200]

On 5/18/2021 at 9:47 AM, Martijn Meerts said:

Ah, so the command station was expecting S88 feedback, but was getting something else? I don't know anything about the Digikeijs command station 🙂

 

 

Yes, it seems that was it. So far the Digikeijs is fairly user friendly. The hardware is relatively simple and consistent. I like the graphical interface and the customer service/ tech support is excellent. But things like this always take a while for me to grasp. Re-installing an setting up from scratch has really helped me to consolidate my knowledge. 

 

I'm glad I'm learning this on a throwaway practice layout. It was a "decision" dictated by necessity, but a lucky one. 

[Martijn Meerts]

I think that's a bit of a 'problem' with newer command stations. They support a whole lot of stuff, which is great, but can also be confusing when you're just starting out. When I started out, we got a Selectrix starter set with a command station and 2 digital trains. There was only a limited amount of compatible hardware for that, so it was all fairly easy. We did have a simple oval to play around with, but when we started with computer control, we converted an existing layout without doing any test layout(s). That was very doable though, because at the time you pretty much only had Trix and Rautenhaus doing Selectrix hardware 🙂

 

[gavino200]

Yes, that would be a much better situation for learning. But I'm pretty determined and I'm really in no hurry, so I'm sure I can work it out. I'm also starting to get a better idea of how CVs and decoder programming works. I'm very excited by the possibilities of automation. 🤪