DCC++ to a new level

[Rivet Miscounter]

Wow! I'm seeing a lot of negative vibes, um, votes being used ini this thread. 

And extending beyond this thread!!!       Hundreds of downvotes I have now all of a sudden....woe is me.  lol

[peteski]

And extending beyond this thread!!!       Hundreds of downvotes I have now all of a sudden....woe is me.  lol

LOL!  I didn't realize that. I'm just as surprised as you are.  Yes, this will likely not last very long.  Something set MoPac off - he seemed to be quite happy with his Tomix layout, and now this?  Can we blame this on COVID-19 social isolation?

[Rivet Miscounter]

LOL!  I didn't realize that. I'm just as surprised as you are.  Yes, this will likely not last very long.  Something set MoPac off - he seemed to be quite happy with his Tomox layout, and now this?  Can we blame this on COVID-19 social isolation?

Pretty sure the social isolation for MoPac was loooong before COVID-19.

[MoPac]

[MoPac]

[DKS]

OK, well, being a bona fide a$$hat with a modicum of experience in the various fields involved in this discussion, I felt compelled to respond. I’m having a great deal of difficulty wrapping my head around the topic.

So, please correct me if I’m wrong, but from what I gather, your goal is to determine the location of a train anywhere on a layout by detecting the amount of current draw from the locomotive. I’m seeing a few issues right away. First, the current drawn by a locomotive constantly changes. As the decoder is required to perform different tasks, the load it creates varies. It’ll need more power to transmit a signal, or generate a sound, or process a command, than when it’s sitting idle.

And this doesn’t even take into account the motor. Even at a constant speed, a motor’s current draw varies. If you’ve ever connected an ammeter to a running motor, you can watch the load constantly varying. If you want to see even bigger variations in load, however, watch how it changes as wheels roll over track. Unless the rail and wheels are all polished to a mirror finish, the load will vary—sometimes significantly—because of the slightest bit of dirt or tarnish on any metal surface. Plus, there could be all manner of spurious current draws, such as semi-conductive dirt around switch points, etc.

Now, here’s a $64,000 question: How would the system differentiate between the rails and the wires that connect the system to the rails? Wires aren’t always consistent in length, gauge, connection spacing, and so on, so we cannot make any assumptions that can be programmed into the software. Also, let’s take a really simple layout that’s a circle of track. A locomotive is somewhere out on the loop, but which side of the loop? Is it at 3 o’clock, or 9 o’clock? Making matters worse, the tail-end car is also out there reporting in. Which side of the loop is it on? Because if the system got that wrong, then the assumption it makes about the length of the train can be vastly different. And finally, distance relative to what? the controller? Some arbitrarily-located sensor? In either case, wires are going to wreak havoc with any assumptions you make about distance.

And we haven’t gotten into the fact that two locomotives won’t draw the same amount of current, no matter what, unless they are 100% identical, and even then there could be variations. Then there’s the case of a passing siding on the mainline. How could the system possibly differentiate between a loco on the main and a loco on the siding? Assuming all things being equal, the current draw would be identical either way.

Furthermore, the difference in current draw when a loco is one foot or two feet away will be so minute that I’m having a very difficult time identifying the means to detect such tiny differences. Add in motor and other RF noise—which is rife on a layout—and all I see is a futile effort, inside or outside the box. Thus I’m seeing all sorts of problems if you’re relying solely on current draw to determine location.

So, let’s assume instead the system is relying on a signal round-trip time instead of current draw. The system controller pings the locomotive; the locomotive replies. Measure the round trip. Now we’re talking about a system that, in order to differentiate between one foot and two, must measure the time difference in femtoseconds. (I used to work for an instrument manufacturer, and we’d measure the times of biochemical reactions, which can happen really, really fast.) Doable, but likely not cheap.

The biggest problem with this process, however, is the time it takes the locomotive to respond to the ping. Even the best microprocessor can’t respond in the femtosecond realm. Furthermore, if the loco’s tiny CPU happens to be busy doing something else at that instant, then the delay will be greater. Now we’ve got the problem that the time can vary, and the difference between responding within one or two clock cycles could be interpreted as a distance of plus or minus several feet or more.

And it still doesn’t solve the dilemma of which side of the circle the locomotive is occupying. Indeed, because the system cannot make that distinction, and the loco is, let’s say, at 9 o’clock, the system will obtain two very different results simultaneously, since there’s no way to direct the ping to the left or right side of the circle. And it makes my head hurt to think of what the results might be if there were multiple locos out on that circle. Then there’s still the case of a passing siding on the mainline, which a time-based system couldn’t possibly solve, either.

So, bottom line, we’ve pretty much eliminated relying on current draw alone as being a reliable method, as well as using a time-differential based on round-trips to the loco, unless I really missed the boat somewhere, in which case, I am all ears. But any solutions must be based in reality: how, precisely, would these very basic problems be addressed? The answer cannot be “AI software,” because even the best AI cannot counter the laws of physics that make current- or time-based systems unreliable.

Barring any miracle cures, what have we got left? All I could imagine is a GPS-like system: a transponder for each locomotive, and several sensors attached to the ceiling of the train room. Feasible, perhaps, although the discriminators in the sensors would need to be among the finest ever designed in order to obtain a resolution down to less than a foot. You’d still have problems with passing sidings, I suspect, since resolution down to an inch is likely stretching things, so the system would need to be imbued with some pretty potent AI software.

The above all represent passive systems that require little to no input from the modeler. I maintain, however, that it’s the “lazy man’s way” of doing things, and the modeler’s wallet will suffer the consequences, since there’s no free lunch. The alternative is to hunker down, and program your actual track plan into the system software, and use a more direct approach for locating trains. To me, RFID tech offers a much more cost-effective solution. The chips cost pennies apiece—you could put one in every car—and then install off-the-shelf readers strategically around the layout.

As an aside, the subject line had me thinking, DCC-double-plus-good. But, Big Brother jokes aside, a system as proposed seems like overkill, and the more complex a system is, the harder it will be to troubleshoot. Do you really want AI involved with your layout? “Alexa, where’s my train?” Scary thought.

[Maletrain]

Thank you DKS! 

I will add to the number of practical difficulties by mentioning things like mid-train locomotives and those BLI cattle cars that make animal sounds.  Those are going to be adding to current draws through lots of track feeders in the same block.  Even with current detection on every feeder (which I think he said he is not proposing), it would require a lot of assumptions or one heck of a sophisticated AI program to even begin to pinpoint the locations of multiple current drawing items on the tracks of any realistic layout.  It would at least require a real-time inventory of every item on the tracks and its current operating state.  And then, the results would best be stated as something like "there is an 85% probability that loco #123 is located within x inches of point y."

The real problem with the OP's  description is that it seems to oscillate between measuring current in multiple places and measuring the total draw on the command station or booster feed.  He has not clearly communicated where he is getting what types of data and how he thinks that data can be processed to determine positions of individual pieces of equipment.

I have some knowledge of "neural networks" and AI for "learning" how particular patterns of data are associated with specific causes.  There is a physical limitation on how much you can infer that comes from the number and nature of the data points used.  The OP seems oblivious to the concept that the effects measured must be logically adequate to make the desired distinctions among the potential causes.

Unless/until the OP makes some clear description of what data he proposes to collect and how he proposes to analyze it, this thread is worse than useless, because it is generating a lot of ill will.

So, I am going to stop participating until I see some value in doing so.

[John]

I know this thread is locked .. but some thoughts

1) Digitrax transponding -- will allow you track locomotive information in a block.  It seems to have mixed results ..

2) DKS's idea of using RFID would work similar to transponding, but would require relatively costly readers around the layout .. the real railroad does that ..

3) You could set up a receiver grid at known locations -- similar to cell phone towers and transmitters .. if you mapped out the room precisely enough, you could calculate the X Y (and maybe Z axis) based on the relative signal arrival at each receiver .. then or course you would need a precise time source and some software .. might be fun, but not worth the effort IMHO