When are Hornby going to fix gap in dcc solution with loco detection?

[37lover]

Ray,

One only has to take a look at the thread with members predicted LD release dates to appreciate the frustration many feel, me included. I am currently working full time but early next year will be retiring. And with that "extra" time would love to develop the "Auto-running" of my layout. As it stands I was considering replacing RM with Digikeijs Dr5000 with detection via iTrain as mentioned in anther thread, this would also mean disposing of my Elite controller. Not without substantial cost

However, you seem to have another option but I can appreciate that having "created my own RM replacement software" you may not be willing to give away your hard work. So my question is are you willing to share more details? Even if that means me contacting you privately outside of the Forum using the Admin facility to exchange contact details.

Kind regards

Martin

[Chrissaf]

Just to point out, that Admin facilitated contact has been discussed by the mods with the current new forum administration team. The feedback we have had is that this was something the previous administrator did basically as a favour and will not feature as current 'policy' on the new forum. Any members wanting to make contact will have to find an alternative method, such as meeting on another forum that supports 'private messaging'.

[St1ngr4y]

@37lover

Hi Martin,

I am registered on the RMWeb forum with the same user name - st1ngr4y. If you are registered there, we can pm each other and exchange email addresses.

The software I created was for my own amusement, just to see if it could be done. Like RM it is capable of using either one or two Hornby controllers (eLink or Elite). If two are used, like RM, A is for locos, B for accessories. It can import a track plan from RM, and it can import RM programs, doing its best to convert them into the program format used by my software. The documentation is all in my head at the moment, but I can send you a summary of its capabilities, with screen shots.

Ray

[37lover]

@ Ray,

I have just set up an account on RMWeb and it looks very comprehensive. I will take a look around because there are certainly several posts on loco detection which I think will help with my background knowledge and where I might want to go. I'll get in touch soon.

Thanks

[ColinB]

I see what you are saying, so yes you can do it that way but you are duplicating the data. So effectively when you set the DCC address into Railmaster you would also have to set the corresponding ID that is on the loco. So how did Hornby propose doing this, a bar code under each loco? Anything is possible it is just how much time and money you want to spend on it. As I said, I can understand why Hornby hasn't implemented it. One of the things I would like them to do, is implement the reduced voltage DCC feature as in Zima and certain other decoders, where if the loco sees a reduced voltage the motor stops but all the other features work. On my DCC layout I have lots of switched sections which stop the loco if the points are against it. As the sections are controlled by relays it would be really easy to add the reduced voltage feature, but my TTS powered locos don't support this.

[St1ngr4y]

@ColinB

Hi Colin,

Could you say to which post/person your last post was referring?

Ray

[ColinB]

I was answering Fishmanoz and 96RAF. I suspect the system Hornby were thinking of probably didn't work that reliably or the person that was working on it left. It sounds like the system they were proposing was just a proximity detector either picking up the magnetic field of the motor or using other sensors. Trouble is you would probably feed the data into RailMaster, so if you changed the loco you would have to change all the data. I can see how you would do it. I suspect the changes to RailMaster ruled it out, that is a lot of programming effort. You can probably easily detect the loco by having an isolated section that detects the loco as it crosses into it, bit like the autofrog device, then once it has detected the loco switches the DCC to that section.

[Fishmanoz]

Colin, if I can emphasise that my post was a summary of the published information at the time LD was first proposed. Your hypothesised EM detection is not what was published, the detection tags were, even prices for a pack of I think around 100 of them.

And again, RM is currently fitted for but not with LD while it waits forlornly for release of the hardware.

If the system were released as previously published, it would be quite powerful given you can effectively program “if-then-else” commands including running programs which can be very comprehensive. But I agree with Ray that it doesn’t appear to be capable of dealing with a detection interrupting a running program, the user would be challenged to ensure that doesn’t happen. Not sure on Ray’s other point.

[96RAF]

I concur with Fishy, the system was fairly well documented at the time including a section in the RM manual that later got deleted around the time of the Eureka moment.

The detection mechanism was based upon sticky labels under the rolling stock. What was not clear was if this was a bar code (passing loco ID and direction) or simply reflective tape (passing traffic indication).

There was a limit of two collector modules each processing (from my memory) up to 48 sensors flags back to RM.

...end of my available info.

Ray has flagged up a serious flaw in operational integration of their system, but I don’t suppose this has actually been recognised by them yet.

[ColinB]

Well Fishmanoz there was obviously a reason that they didn't realise it. Having spent most of my life working on this type of stuff I can think of a hundred and one reasons why they didn't and it doesn't always involve the bean counters. You would be amazed at the things I have worked on that never made it to market, generally having several prototypes that were demonstrated that worked. Once you go into production the game changes as you get tolerance stack up and no longer do you have the fine control in making things work. So as I said I can see loads of reasons why they didn't go any further. RailMaster I get the opinion is an old product where probably the person that wrote it has long since gone, so basically all you get is bug fixes because nobody wants to touch it in case it breaks. You can see this by the number of releases they make in a year, so I doubt they are going to rip it apart to put in some extra logic. As to the possible use of barcodes, firstly barcode readers generally need a laser, definitely not going to happen on something where a child could get near, then there is the issue of mounting it under the track reliably. Long term I would suspect DigiKeijs or DCC Concepts will bring out a system, they seem to be the companies that seem to come up with the forward thinking ideas.

[Fishmanoz]

Can’t see much point in hypothesising further Colin, especially where they are contrary to what has been published previously.

Yes, it may not work, as is borne out by its yet appearing. All we can do is wait or turn to alternatives.

[idlemarvel]

The lack of train detection is a recurring theme on this forum. It is a shame that Hornby announced this so many years ago and "dangled the carrot" but has yet to deliver and some believe never will. One can understand that Hornby, having been on the brink of collapse would not spend too much time and money on what is a niche product with a small customer base, but perhaps they should have made that clear instead of leaving the ball in the air.

However, moving forward I wanted to share my views about train detection in relation to automation. I have experience of this primarily with Rocrail (freeware DCC train control software) and to some extent iTrain (paid for software product) and I have built many automated layouts in OO and G scale. Warning: this is a long post, read on if you are interested.

What is RailMaster (RM) for? Well, automating the operation of model railways. But that can take many forms, and I can think of at least five modes or levels of operation / automation:

1. "Signal box" mode where you use the software to control points and signals on a "mimic" diagram on your computer screen, but the locos are driven manually. This would be like in the old semaphore signal era where the signalman watched the trains and changed the signals and points accordingly. No need for train detection here.
2. "Automated signalling" mode where the signals change as locos, driven manually, enter and leave blocks, This is more like modern colour light multi-aspect signalling where the signalman selects a route for the loco to follow but the signals change by themselves accordingly. This requires train detection.
3. "Timetable operation" mode where locos, points and signals all operate without manual intervention, and you can sit back and watch it happen. This works best with train detection but you can simulate this with timed operations. 
4. "Mixed operation" where there is a timetable in operation but you take control of individual trains - this is a mixture of modes 2 and 3 described earlier. This requires train detection as the software needs to know where the trains you are driving are as well as the ones under its control.
5. "Gold fish bowl" mode where locos, points and signals all operate automatically, but in a random way, where the software takes care of block occupancy and collision avoidance - this is like "timetable operation" but where the timetable is made up by the software as it goes along! Definitely requires train detection.  

So the possibilities are much greater with train detection, but at a price, of which more later. 

Where does that leave RM? Well it can definitely provide "signal box" mode which may be enough for most people. The "automated signalling" mode is perhaps beyond its scope, but people have found ways to supplement RM by using infra red, magnet or current detection to change signals set by RM to "green" to "red" when the train passes. There is no way to pass this information back to RM though so the user has to manually reset the RM view of the signals from time to time. Not very satisfactory, but again may be enough for some people. In the case of 3 or 4 aspect colour signals it is unlikely your model layout will have the room for 3 or 4 actual blocks big enough to accommodate long trains, so some "pretence" is required when switching though the red / single yellow / double yellow / green sequence which could be simulated by an RM timed program.

As mentioned, the "mixed operation" and "gold fish bowl" modes are beyond the scope of RM, which leaves "timetable operation". I have created this in past layouts using the facilities of Rocrail, which supports train detection using a variety of techniques, although I tended to use current detection within blocks. The results were very good, and I could achieve what I wanted, but at a price. First there is a substantial amount of planning, to decide which blocks are needed, how they are linked, which locos or types of trains are allowed in each block, at what speed, etc. Then there is the practical cost of the sensors. You typically need at least 2 per block, one to detect the loco entering the block, and another to indicate it has fully entered the block. These need to be wired to a control device of some kind which in turns needs to be be wired to the computer running the control software. You may also need, and perhaps are advised, to have sensors on points to make sure they have switched the direction you wanted them to. More expense and wiring. Once the hardware is set up, fine tuning is required to adjust the stopping position of each loco in each block, and to make sure the proposed trains fit in the blocks. Then you allocate signals to the blocks, and check they operate as the should when locos enter and leave blocks. Finally you are in a position to build a timetable and watch your trains go by!  

As can be imagined this is not a trivial exercise, and can take many weeks if not months to get right on any but the simplest of layouts. Compare this with RM, where you basically define the timetable from the start - at time x set point, at time y start loco, at time z change signal, etc. No sensors to wire, or blocks to define, just a single DCC connection to the track. You can define each "diagram" (train movement through your layout) at a time and then combine them in a chained program, or to be triggered at a point in real or scale time. I have built several layouts with modest timetables using RM and they work fine and were a fraction of the work of a corresponding Rocrail train detection based implementation. The whole process is much simpler but of course less robust. If a loco stalls for example then it would only be a matter of time before a collision occurred, as RM would continue blindly on moving other trains. So depending on how clean your track is or isn't, how reliable your locos and points, you will need to keep an eye on things and be prepared to hit the big red switch! Then again if you're not there to watch it, what is the point?

In summary, I am not saying that RM does not need train detection, far from it. What I am saying is that you can do a lot without it, and more simply than with more sophisticated products. And remember that RM including an eLink costs less than an iTrain Lite licence. 

[Bexhill Donkey]

If you belong to the Isle of Wight Railway Facebook group you will know there is a project underway to upgrade the Island LIne. A passing loop has been constructed at Brading and the disused platform is being brought back into use. Of interest in this context is the revision to operating procedures and how they are implemented. The Youtube video which has been made on this subject shows that wheel counters have been introduced. This shows exactly where the train is, which is the key thing. A difficulty with Railmaster is that although you can programme an automated sequence, the software does not know where the train is, and the only way to fix this is to run the train slowly into the buffers are the beginning of the sequence. You don't actually need 'loco detection' if you can count the wheels, but that's not exactly easy in OO gauge either. A method that has been used is to fit each axle with a resistor to a specific value and measure the resistance. That does work, but it means all rolling stock on the layout must be so adapted and is only worth considering for a museum exhibit which only operates a fixed sequence. I think you could paint each axle white and detect each wheel with a barcode wand. Anybody got any other ideas?

[Deepfat]

I am not sure this is worth discussing Hornby are not investing in DCC Never mind the detection RailMaster has bugs, it doesn't work properly with Windows and not at all on OSX IOS android etc.

Their controllers are getting very long in the tooth and their promised expansion of TTS decoders has not been forthcoming.

Most importantly they are not listening or active on this forum.

They do still make some lovely rolling stock and I will still enjoy that

[idlemarvel]

@Bexhill Donkey

Yes axle counting is another aspect of train detection although on the scale of complexity it must rank rather high. There are many ways of implementing train detection at OO scale and smaller, well tried and tested, including infra red, magnet, current, RFID, etc etc. If you need train detection then Hornby DCC kit is a currently a dead end, and depending on who you believe always will be. Some alternative software may work with Elite (but not eLink) like Rocrail but iTrain for example says it may work (because they support Xpressnet) but is not supported.

@Deepfat

You may be right about future Hornby investments in DCC or otherwise. My point was to say RM is what it is, it may or may not get any future enhancements, but even in it's current form it is usable for the "signal box" mode or "timetable" mode. Stopping at buffers or along tracks using switchable "dead-zones" or ABC sections (see @ZeroOneman) means you can ensure fixed start/end points. My other point was that train detection is not a "free lunch" and involves a lot of work, planning and expense compared to the RM timed event approach.

[Brew Man]

Can I just ask what the particular purpose for loco detection is? Is it for block circuit track control? If it is then which particular loco it is doesn't matter surely. Anything on the track will suffice. Remember the Great Train Robbery?

If it's something else then I am obviously missing something.

[Howbi]

This is the original Hornby description of their proposed LD system.........HB

[idlemarvel]

For some purposes knowing there is a train, any train, passing a sensor or entering a block, is sufficient. If you want to monitor a train travelling along a route you may need to know which train it is to confirm it is correct, especially if the train is manually controlled not controlled by the software. Or if the train is trying to enter a route it is not allowed to, for example an electric train trying to enter a non-electrified block, then you need to know which specific train. But in general for model railways it is usually good enough to know that a train, any train, is on the track.

[ColinB]

Thanks Deepfat they are exactly my sentiments. I have never used RailMaster so I don't know how good it is, Elite does the job but is a bit dated. Hornby do make really good steam locos but I think that probably is because all the ground work was done years ago. As I have said previously, I think Hornby has the same issue as a number of businesses years ago they hired someone that could do all this stuff, but they have long gone, so support is now an issue.

[ColinB]

Having read the description, has anyone any idea how the detector pads work? It doesn't mention power and the sleeper tags sort of indicate magnetic detection of some sort. unless it is optical. Anything optical would need more room.

[Fishmanoz]

Colin, HB’s post above gives you 99% of the published info about Hornby’s LD hardware. There is no further info on what technology is used by the tags and sensors or the LDM. The only additional that I remember from back when this was published, at least 5 yrs ago, is that the sensors mount through holes in the sleepers that you must drill. Look at the sensor track piece in RM layout design mode.

I can also see why you might be having trouble getting to grips with this as you only use Elite without RM. Can I suggest you download RM from the link in the sticky post at the top of the RM forum. It is free in evaluation mode and works for 90 days. First connect your Elite to your laptop and install the Windows driver (if you are yet to do so by doing a firmware upgrade. If you haven’t, do that upgrade first). Then with the driver installed and the Elite still connected, install the RM file in administrator mode. This way it should get all of the RM setup parameters correct and the RM manual will be downloaded to your desktop.

Then do as I suggested and set up a layout in design mode and install a sensor on it and play with commands as I said in a previous post.

Back at the time that command list was produced (see date on it), there was extensive discussion in the RM forum about it. But still no more facts than HB has given you above.

[ColinB]

Thanks for the info Fishmanoz, but I have no need of RM. I read how it works from the data that came with my copy that I got packaged with my second hand Elite. It came up with the demo package when I installed it. I understand completely how the loco detection would work with it. So I can see how it would all work and if you only have one loco on a given circuit then you don't need to know the locos id. The system proposed is supposed to give the loco id from tags attached to the loco. So yes if you gave it to me as a project no big deal, the biggest issue is drawing on the screen with Railmaster, graphics programming is difficult and time consuming. No my issue is with the sensors. Reflective optical is what I would suspect that would do the job, or magnetic.

Magnetic is out as it only gives you a there/not there signal. So optical seems the most logical. Now I am a bit out of touch, but 5 years ago I was still working and there were no sensors on the market that small. Optical is also problematic, with getting the signal right. The tags have no power to them so it looks like a printed bar code or the like.

[96RAF]

The clues are all in the blurb Howard has posted Colin.

The sensors go in the sleeper gaps and link back to the collector modules. Any power requirement is gleaned from the module, after all the sensor circuit only needs to be a simple hi-lo logic.

The loco/rolling stock tags are simply unpowered reflective stickers hence the track sensors are going to be basic IR.

All this rhetoric is a waste of typing effort of course if the hardware never gets released.

[ColinB]

Yes 96RAF I understood that, I read the information. So we are talking about reflective with a infra red LED coupled to a photo diode or transistor. Now if you look at what is commercially available although they might well fit between the sleeper but they are rather large. The numbers involved wouldn't make it economic to make your own. Then you have the issue of range, not all locos are the same so with some locos it might not even work, the distance between bottom of loco to sensor being very different. That is why a lot of people use lasers. I think I can now see why Hornby didn't pursue it any further. One of my jobs in my previous life was in test instrumentation where we used a load of this sort of sensor, eventually we binned them as they were too unreliable, the gap, ambient light and dirt being big issues (yes I know they are infra red, as were ours).

[Chrissaf]

This is an image of the prototype Hornby LD detector that never went in to full production. The wires route back to an external sensor concentration module that contains the electronics. It is not clear, but it looks like there might be three wires. If there are three wires?, then that could be considered typical for an IR detector. Two wires for power and the third for the detection signal.

I have built some simple IR detection circuits to control things like signals. I used the commercially available RPR220 IR detector. These are also used by 'Block Signalling' with their automation products.