Beyond DCC++

Hmm? I am all for DCC and DCC sound, though to me DCC++/JMRI is still behind the curve. If someone can come up with a program that not only reads the locomotive but also knows where it is at all times on the track via electrical contact/current with the tracks and reading the decoder itself. Just like if you were giving it a command to increase the throttle or activate the horn. Doing this without using blocks and IR sensors. Yes, signals will still be used in conjunction with turnouts etc. Plus to step it up a notch and put a decoder in the caboose/EOT car so the computer can read it also. Regardless on how far apart the two signals are. the computer will understand that the distance between the two will/should stay constant unless operations will either add or subtract from the train. So whenever a train passes a signal the light will change accordingly. Also the computer should be able to detect breakaways if the caboose or EOT car suddenly stops and the locomotives are still going. If that happens this will stop the train itself and all other trains on that line or the whole layout. By preventing an pileup. Just a thought, I do have a more in-depth ideas on this. It is fairly simple, plus it would be based off of the old current detectors.

Any thoughts?

 

That’s would work also. For example, my layout will consist of an inverted double loop. With the second tracks on the inside. What I was thinking is whenever the locomotive is depending on the signal from the controller( I am not referring to wireless operations) just directly from the computer to the electrical board into the track. So it will solely based upon the contact of the locomotive and EOT/caboose w/metal wheels of course. So as whenever the current/signal is changing electrons/information from the controller to the locomotive & rear decoder. It will know this location even if you decided to change your track design. This will not affect the situation of the signal between the locomotive/eot and the computer. Yes, the European equivalent is somewhat similar on what you will need.


Sent from my iPhone using Tapatalk

 

Mo-Pac if you haven't come across it already, download Rocrail (same as JMRI free to use, no limits except on their app). Once installed you have 2 demo layout you can test. The install doc will describe how to tests the layouts. Rocrail website also has list of all the equipment you can connect to your layout and that will work with Rocrail. Commercially there is iTrain (has a 2 month full demo license).

 

Thanks for the heads up though I am looking to put my idea in motion.

 

Detecting time delays of electrical signals to/from locomotives moving on model railroad track, for determining location within less than a foot, is fraught with technical hurdles, such as:

1. The relatively HUGE jitter from the unsteady contact between wheels and rails, and from wipers and wheels in the locomotive.
2. High edge rates of signals to provide sufficiently accurate detection, transmitted over rails, would be a nightmare for Electro Magnetic Interference.

They may be eventually surmountable, but not anytime soon at prices suitable for the hobbyist market.

I would bet a directional system (such as solid state radar with a phase array antenna) would fare better, and cheaper. And such a system could incorporate all the communication/control, leaving batteries and/or the rails for power alone.

 

Now on with your detailed questions. I will make it simple for others to(if they can) keep up. Let's say the train is on an oval track about 100 meters in diameter. In play the track length and multiple track spurs and other features even if there's a reverse loop. This would have no effect on this system. We all know at first the controls for reverse looping on a DCC system took some time to air out the bugs. Onward this train in question is a train with 125 cars. Yes, we know that all of the cars are in different lengths and weight. Plus we have let's say four DCC locomotives on point and two others 3/4 of the way back. Also lets say three of them have sound and the rest don't. This is to add acoustics of the train as it makes it way around just for fun. Yes, as a requirement the end of the train must have a caboose/EOT (or another locomotive if desired). They ALL must have a decoder with metal wheels for reading and sensing purposes. Yes, we all know that the current change is not constant for any train on any layout at any given time. Even through raising and lowering the throttle and making the extra functions work as the train rolls down the track. Though as for computers now-in-days can control any of the functions for any locomotives or other noise making cars/wagons on a layout through the wheels. With this AI will need to be advanced to the point that the computer is actually sensing/feeling the train through the current/contact on the tracks as it makes its way around this oval at all times. With this in mind the computer can determine not only the length of the train, the multifunctional commands for the train. It can sense the precise location through the contact from all of the metal wheels as the current and commands are sent and received from the computer repeatedly by the constant pings and the relay from the decoder. The computer will monitor the current load and amp draw of each train at all times. No need for blocks, IR's, or cameras. This is where the program of the computer will need to be able to function to the level of AI as needed. There's a lot of 0's and 1's in there! Now as far as the decoders from the rolling stock on the train. As we know the decoder/s is giving the response to the computer and in return it is acting as a homing device for the computer. With that the CPU can actually know where the train is at any given spot on the tracks as I have mentioned before.

This is where smarter software will need to be in control of the train. Plus the CPU will need to handle all of the functions simultaneously. Ok we know sometime whenever you start up more than one DCC sound locomotive chances are they will all start up together. Adding a few second delay in between each sound locomotive would be cake. Plus it will enhance the different prime movers even when they are either EMD 567 or GE 7HDL for example. Regardless of the different amp draw or speed of the motor. We know that this has already been tackled by the DCC gods. By consisting the locomotives with speed match and etc.

The next level is where the train is rolling down the track and the CPU is reading and making functions operate as normal. With this in mind the CPU will determine the trains reading/functions and location of the train at all times through the contacts of the wheels. Even if it was at the furthest point from the command controller. It will also determine the actual distance between the lead locomotive and the rear locomotive(if used)/EOT/caboose. So "if" a portion of the train breaks away. Regardless if it is a powered or non powered tailing unit. The CPU can determine the change of the load or lack thereof. With this in play the CPU will shut down this train. If needed it can stop the whole layout. This would benefit from spreading havoc across a multi function layout. By keeping other trains from running into the rear of the stopped train and stop other trains on other tracks that are close enough if needed. Yes, the CPU will need to be fast and responsive to the pings it is giving and receiving or lack in the moment of a derailment or break away. Yes, we know the further the train is away from the command base the slower it will respond. This is why I mention that the AI in the CPU will need to be responsive and taught to understand the distance of the train from the command/cpu, different tracks, train length, reversing points, signals, switches and other functions for the layout. All of this is read, giving commands and located by the CPU at any given point. Plus the CPU will need to be powerful enough to handle the commands. No, I don't know how much power a said CPU will be needed to operate this software.

Now the only issue I have is. I don't have the skills to create a software to function like this. Heck I might be gone from this earth by the time AI will be this advanced. I am just wanting to share my "idea" of this concept. Without the use of modern, old style photo resistors, IR's or cameras through extra wires. As for the pricing, this would determine the cost of the development of the software programing for the computer and if the computer is smart / fast enough for the layout.

Please ask any other questions if I am missing something.


Sent from my iPhone using Tapatalk

 

@BigJake the reason why I am looking into this direction is because of the cost for sensors, cameras, and other tracking equipment will cost you and me more than what we can probably afford. To me having a cpu connected to the command center and the throttle should be all is needed. Yes, a modern computer is a must. The software/program is the brains of the center. Deciding on what decision to make. Yes, a lot of us are using what is available. To some of us. Spending the money on the extra devices to make everything functional can be costly. This is why I am focused on the program and software.


Sent from my iPhone using Tapatalk

 

I don't believe you will be able to reliably use current feedback to determine accurate location. Track conditions change unpredictably over time too much, and will change the current/location relationship.

AI needs training, with some independent system that can provide actual location data (independent of current draw) to calibrate the algorithm on every user's layout. And like I said, over time (weeks, days or less) track conditions can change a lot, so it will have to be re-trained often. Training takes time (you can't speed up the trains!), so the AI will spend more time in training than out. And then your locomotives/axles/wheels/trucks/track will be worn out (and their degrading condition also ruins the calibration).

So, to do all that (re)training, users will need that independent location system anyway. Why not just use that independent system and forget the AI, since training the AI will take too long, too often, and will wear out your trains?

 

Yes, I agree and I forgot to add that the AI will need to be trained and calibrated. As of dirty tracks this can cause it not to function properly. The tracks will need to be cleaned to the level of any DCC running. In turn as we all know that whenever dirty tracks are a issue. The trains will not function as they should.

As for as the command and the cpu giving reliable feedback on determining accurate location the software will need to be super smart and actually think for itself. So yes again it will need to be taught to learn the tracks, train and the functions of the layout and be able to track the train or trains.


Sent from my iPhone using Tapatalk

 

Maybe we're going about this the wrong way. Rather than having the Command Station do all the heavy lifting to figure out where its train cars are located, why not have the cars pitch in?

You could use a calibrated roller to paint a strip of IR reflective (and visually transparent) paint dots at accurate spacing along the entire track road bed. Then an IR emitter/detector pair and a Railcom compatible decoder in every car/loco could detect those dots, and report their passage to the Command Station for an indication of relative location from startup.

No AI required!

To auto-calibrate the absolute location, you could put a narrow beam IR LED (different wavelength, to avoid interference with the above emitter/detector pair) somewhere on the track, facing up, and a matching IR sensor in each car, so the decoder could determine when the car passes over the LED, to determine an absolute position reference, from which dot count can give you relative position updates as the car rolls around the track. So, you have, after a lap, an auto-calibrating position reporting system.

In volume manufacture, such a decoder with interfaces for the emitter/detector and sensor, could be fairly cheap, and low power (the thought of having hundreds of decoders on the layout at one time does present difficulties for current DCC systems, power not withstanding.)

This would, however, be difficult to implement on flat cars, well cars, etc. that do not have room for the decoder and other circuitry to be hidden out of sight (at least in N or smaller scales, which is what matters to me.)

 

That’s already have been done. With barcodes and IR’s the only issue with this is whenever there is a break away it will not recognize the issue whenever part of the train has stopped. Even with this the AI will be needed to stop the train and any other trains nearby to prevent a bigger catastrophe.

As for as emitter/detector decoders this is why I would suggest to keep it simple to have one for the rear EOT/caboose. Anymore for the rest of the train would be very costly. Because if the EOT car stops or the rear locomotive is derailed by an pile up. The cpu will have the command center stop the train.


Sent from my iPhone using Tapatalk

 

However, it occurs to me that such a system of dots, by itself, would not account for direction.

Optical encoders use two parallel pulse tracks, in quadrature, to allow determination of direction. So a slightly more complex paint wheel, and a pair of detectors for the emitter, could solve that problem.

And there are "virtual absolute" encoders that use a third, pseudo-random pulse pattern, such that crossing some fairly small number of pseudo-randomly spaced pulses can be correlated with the known pseudo random pattern to determine absolute location with very little, consistent movement in either (but only one) direction. I believe Gurley patented this technology, so such an approach may have to license that patent. I used them on one project, and the controller had to try to rotate the axle in one direction or another to determine the absolute position, from which the relative position could determine precise location. It was much cheaper than an absolute encoder of equivalent precision and speed.

 

Interesting indeed about the painted wheel technique and virtual absolute decoders. First time I have heard of this by Gurley. This will have to deal with multiple directional trains though. I would definitely like more information about this technology. As this is somewhat in the same direction as my idea is running.


Sent from my iPhone using Tapatalk

 

I think you are confusing my idea vs a system of stationary barcode readers, reading barcodes on cars passing a stationary sensor. My idea has the sensor in each car reading stationary dots on the trackbed as it passes over them.

WRT dirty track impacting decoders anyway, the relative dirtiness to interfere with a DCC decoder is much more than that necessary to fatally interfere with a sensitive current measurement. Thus the track would become dirty enough to fatally alter the current measured, to prevent accurate determination of location, LONG BEFORE the DCC decoder would stop functioning.

Andy

 

Okay thanks for the clarification. Now it makes sense. I am still interested on this type of setup.


Sent from my iPhone using Tapatalk

 

Mo-Pac, I have hard time extracting from your posts on how exactly you want to determine the locations along the rails.

If you are thinking of an electrical timing measurement, or of a rail resistance measurement to determine the distance between a locomotive and the detecting station, I see technical problems with both approaches:
To translate run time differences between electrical signals along the rails into distances, you would need fairly sensitive time-to-digital converters, since electromagnetic waves are so darn fast (speed of light): pretty close to a foot per nanosecond. For sound (one foot per millisecond in air, so a million times slower) cheap distance measurement gizmos to plug into your self-navigating toy car already exist. So a sound based system might be more realistic.
You could think of something like a triangulating shooter locating system that is being installed in some places by local police, except that you would tell a locomotive to sound the horn, and triangulate its location with three receivers.

If you wanted to measure the rail resistance between locomotive and detecting station, you would need to be able to measure resistance differences with a resolution of order 0.1 Ohm or so, to get a precision of about a foot (see for example https://dccwiki.com/Rail_Size for model rail resistances); that should actually be doable in principle, but as BigJake already pointed out, you'd have to deal with all the effects of varying wheel-rail resistance due to dirt and oxidation and rail joiners.

Both timing and resistance measurements would be made a lot more complicated by feeder wires to different locations on the track.

If I'm not mistaken, local railcom receivers can already determine the presence of a locomotive in their district, so maybe your best option is to build cheaper railcom receivers for yourself.

 

You should think outside of the box. You talk about electrical timing between stations and such. This is not the case. It is not relying on distance between signals on the rails. Only between the train and the command center and cpu. BigJake and I already discussed and agreed that the tracks should be cleaned in order to run DCC. Knowing to have a DCC system and dirty tracks is trouble waiting to happen. No need for feeder wiring or having railcom receivers


Sent from my iPhone using Tapatalk

 

Very good. Not needing timing or resistance measurements or feeder wires will make things a lot simpler. So, just the CPU with some AI then?

 

Yes, all of the timing and resistance measurements are done through the software. As for as feeder wires my opinion wires should be used for safe measure. Although if the tracks were clean as well as the locomotive/EOT/caboose wheels. Yes, just the CPU, command center and controller with a very intelligent AI.


Sent from my iPhone using Tapatalk