Loco Detection: What Is It and How Does It Work?

[Nick_]

Why Hornby is still faffing about defies logic.

My best guess is because Hornby Hobbies PLC doesn't have the money to give to Hornby Railways for the investment to finish the hardware development and actually manufacture the hardware. If Hornby Railways did finally release LD I suspect it would take a few years to recoup the manufacturing development cost and Hornby Hobbies PLC probably doesn't want Hornby Railways making any investments that don't at least break even in the first year, not Until Hornby Hobbies PLC are back making an actual profit. 

[Nick_]

The likes of digitrax and Uhlenbrock already make detection systems. The trick is to integrate it with RM......

But with these detection systems don't you have to physically break down your track into electrically isolated sections? Not to difficult to plan and do in the layout design stage, but not so easy to retro-fit. Hornby's LD system appears to just require sensors to be fitted at appropriate places and wouldn't require any changes to the layout wiring. In fact it would even work for those layouts that use point clips and a single power connector!

[Fishmanoz]

Quite correct Nick, it is completely independent of track architecture and wiring. So it is very different to block detection systems that require separate wiring to each block, and you need a different mindset to envisage how you might use it.  

 

The fundamental difference is that it has no idea where anything is, but you do and can program accordingly.   A simple example might be that loco A is detected at Sensor 1.  You know that sensor 1 is just before platform 5, so you command loco A to stop a train length past sensor 1.  But loco B is a through train, so when it arrives at sensor 1, you do nothing.

[hosh]

It all seems fairly simple ...

...so why can't RM /LD do this yet:

11trains under control...

 

😆

 

And this is just one bloke who did all the software on his own just for something to do! As anyone with a bit of ability and perseverance could!

 

There is no reason, other than having no clue, that Hornby have not incorporated something into RM that works with existing hardware.

[hosh]

Quite correct Nick, it is completely independent of track architecture and wiring. So it is very different to block detection systems that require separate wiring to each block, and you need a different mindset to envisage how you might use it. 

 

 

It seemed to me that Nick understood all that just fine.

 

The fundamental difference is that it has no idea where anything is, but you do and can program accordingly.   A simple example might be that loco A is detected at Sensor 1.  You know that sensor 1 is just before platform 5, so you command loco A to stop a train length past sensor 1.  But loco B is a through train, so when it arrives at sensor 1, you do nothing.

 

 

So it can do kindergarten simple stuff? Great.

 

So how does it cope with trains heading in different directions and heading towards the same set of points? As shown in RAF96's youtube video, a hobbiest has worked it out just fine in a bit of his spare time! 😆

 

Give the man a job Hornby!

[Nick_]

But RailMaster wasn't actually developed by Hornby but by a 3rd party who must have then entered into some sort of agreement with Hornby. Presumably they could easily add support for other block detection systems, but for some reason Hornby won't let them. Which wouldn't be a problem if LD existed, but is a pain as, so far, it doesn't. 

[Howbi]

I believe RailMaster was designed and is maintained by PowerPoS Systems, an EPoS company at a secret address in Milton Keynes.......they are experts at providing E-Commerce systems.........maybe they are too busy with supplying EPos terminals to spend much development time on Loco Detection?......... 🤔...........HB

[Fishmanoz]

PowerPos have done their bit, it's been sitting in RM for years waiting for Hornby to produce the hardware.  See third from the top sticky thread in this forum.

[hosh]

Why am I not surprised to see so many "PoS" about Hornby LD?

[MetmanUK]

PowerPos have done their bit, it's been sitting in RM for years waiting for Hornby to produce the hardware.  See third from the top sticky thread in this forum.

I still take the opposite view.  When you take a very simplistic view of responding to a LD event (a loco passing a detector) then what Hornby have revealed so far in RM makes sense.  However, you quickly realise that the interacting of locos, signals, points etc requires a more complex solution and the RM programming language and editor is not capable of doing that, at least not without a huge amount of redevelopment.

My guess (and hope) is that the penny finally dropped and RM is being re-written in a modern, supported language and in such a way that the current simple programming tool can be sat in front of a more sophisticated product that will blow JRMS etc out of the water for those that want to produce customised solutions.

[hosh]

I assume you meant JMRI?

 

Don't see anything ever blowing that out of the water. It is infinitely adaptable, developable and updateable by the international community!

[MetmanUK]

Sorry, I meant JMRI - that's the trouble working from memory !

 

The problem (if it is a problem) is that JMRI doesn't work with eLink and the Hornby solution.  If the theory of LD works then it will be better than other equivalent solutions, in my opinion.  For me, therefore, the ability to retro fit a superior LD solution would is the best option.  Obviously, JMRI v current RM code is a non-contest.

[Nick_]

The fundamental difference is that it has no idea where anything is, but you do and can program accordingly. 

 

But is that true? 

I agree that RailMaster doesn't know where the locos are in physical space (no system will) but given the mimic represents your layout and the sensors are positioned on the mimic then it knows where they are on the mimic. When a loco passes a sensor it know which loco it is and from that it knows what speed it is traveling at and in which direction. If there is a point before the next sensor it knows which way the point is switched so it knows which sensor it will arive at next. Thus I don't see why RailMaster with LD is any less able to 'know where locos are' than any other detection system.

[96RAF]

You can remove all the straight and curve bits from your mimic and RM will work just as well.

You can stack all your points in a grid or in a line up, down or across the screen and RM is no wiser.

The intelligence of the points is when told to switch it will.

The intelligence of the sensors relative to anything is lodged in their settings, not by way of location. e.g when loco 1 passes sensor 1 switch point 2, etc. 

To have any form of live transit tracking intelligence requires a much more sophisticated sensor system.

[MetmanUK]

Each event, whether points changing, signals changing, locos being detected etc stands by itself and has to be able to generate actions that are appropriate, regardless (almost) of anything else that is happening.

 

It's a difficult concept to get to grips with but if you take the screen you are looking at now, whatever you click on will generate an 'event' which then has to be dealt with.  The program (web page) does not know what you are going to click on or when or in what order - it just has to work it out from the data passed, with the click, to the program.  Trust me, it is complicated.

 

I think Hornby are grappling with this way of working, trying to make it simple for non-techies, but failing because it isn't !  I recall the fun and games PJMT had with trying to get signals to set other signals.  It makes your brain hurt working out every permutation.

[Fishmanoz]

Nick, I'm fully in agreement with Rob and Metman on this, in fact I think some years back I was the first to propose this self-evident truth. But just going a little further than Rob, it's not a matter of it works just as well without the simple bits of track, it's that it doesn't interact with them at all. 

 

I agree that once you've designed your layout, you have sitting in front of you a Mimic that shows all of your railway lines and how they are connected.  The trouble is that, when you look at how RM operates, it is 150% abundantly clear that it does not use this spatial information at all and, as Metman says, would have to be completely redesigned to do so.  Currently, the only things that actually do anything are things like points, signals, TTs and accessories that do something when they are clicked on.  If it's not clickable, RM does nothing with it and can't. The only exception to this is LD sensors and that is because they have separate physical connections to them to record detections, not because you have represented them somewhere on your Mimic. 

 

So how might LD improve things?  Well currently, the only interactions between things which can be achieved is points triggering signals and other points and signals triggering points, as per the setup information you put into them.  The answer is, when you look at the range of commands available in the 3rd top locked thread, there is an order of magnitude greater degree of complexity in what you can do based on a detection.  More than an order of magnitude in fact because one of the things you can do is run a whole program. 

 

Consequently, LD will be able to do a lot more than the simple examples I used and which hosh then criticised as kindergarten. But the limitation is that you can't program in an interaction between detections, they are each independent. The result of this is that hosh's example of 2 trains approaching the same set of points from different directions cannot be solved by what we know currently. You could say, well don't program them to do this in the first place.  That has some validity, why would you, but what about avoiding an unintended consequence when a point doesn't fire as it should, well you can't. And Murphy says that any failure to operate as intended will set up a head-on collision or other equally disastrous outcome.

[hosh]

Thus I don't see why RailMaster with LD is any less able to 'know where locos are' than any other detection system.

 

The simple answer to that is in the to date design. As you can see, the system is moronically simplistic and only gives commands at the moment a train triggers a sensor. At that moment, the system has no concept of where anything else is and can thus not prevent collisions between trains travelling in opposite directions. It can only stop trains rear ending each other via the signalling.

 

This idiotic "design", for want of a better word, will either be entirely scrapped or the entire project will, as it has been to date.

 

Again, it is a bad sign that that command list is still posted here.

[hosh]

To have any form of live transit tracking intelligence requires a much more sophisticated sensor system.

 

Nope, the sensor systen only needs to be very simplistic. All of the sophistication needs to be in the software.

 

I'm surprised to hear you say that since you're the one that posted the youtube video - those sensors look pretty basic to me.

[Fishmanoz]

Can't see how it's bad PJ was good enough to publish this list for us, saves us looking at a sensor setup in layout design to figure it out.  Not sure if anyone has checked recently to see if any other commands have been included though. 

[Fishmanoz]

Agreed the sophistication needs to be in the software, and beyond what is currently if there is to be interaction between detections. 

[hosh]

That has some validity, why would you, but what about avoiding an unintended consequence when a point doesn't fire as it should, well you can't. And Murphy says that any failure to operate as intended will set up a head-on collision or other equally disastrous outcome.

 

Points should be designed so that the system knows whether they have properly been set ot not. A matter of money I guess. Anyone know if such points exist for model railroading? ie points that can physically detect that they are set the way the command software instructed them to and then report that back to the software?

 

The most fundamental fail safe on any automated system would be to have a timing setting for all trains approaching any given sensor. You would set the tolerance yourself, but the basic idea is that a train would be expected to trigger a sensor a time X, and if that doesn't happen by time X + T (T = your chosen tolerance), then that train, or the entire system, is shut down.

[hosh]

Can't see how it's bad PJ was good enough to publish this list for us, saves us looking at a sensor setup in layout design to figure it out.  Not sure if anyone has checked recently to see if any other commands have been included though. 

 

My simple point was that it's bad that Hornby haven't taken it down out of embarrassment. That indicates to me that no one @ Hornby cares and no one has a clue - still.

[hosh]

The problem (if it is a problem) is that JMRI doesn't work with eLink and the Hornby solution.

 

Well there you go, another blotch on Hornby. How could you release a product like the eLink that doesn't even interface with JMRI? And imagine how many sales that's done them out of! How can you have the Elite supporting JMRI and not an even newer product like the eLink?

 

Probably want to hog their own customers and force them to use their own LD, even though there isn't any yet! Sorry, but those running Hornby are not model railroaders, they're just a bunch of marketers!

[96RAF]

To have any form of live transit tracking intelligence requires a much more sophisticated sensor system.

Nope, the sensor systen only needs to be very simplistic. All of the sophistication needs to be in the software.

I'm surprised to hear you say that since you're the one that posted the youtube video - those sensors look pretty basic to me.

 

I was referring to the sensors as a complete system, not in isolation as components, so yes the software is the critical part, but to have live tracking then you need more than just a gateway sensor here and there if such tracking is to be live and representative of actual track position, which is what I was referring to.

 

Changing track, whilst constructive criticism on subject is welcomed, could I please ask you to defer from manufacturer bashing, passionate as you are about Hornby's perceived failings, as it contravenes forum rules and guidlines - thank you.

[Fireman_Ian]

I dont know what the fuss is all about, I have been using loco detection for years.

 

I have two sensors that keep an eye on all my locos as they move around my track, these sensors let me know when to switch points and whan to slow a train and stop it in my station.

 

These sensors are called eyes and are pretty reliable unless I fall asleep at the controls.