idlemarvel

It has been some time since I updated this thread. I have been trying on and off for some months now to get this working and I have to admit defeat and will be trying no longer. For new readers I have been trying to "crack the code" between RM and loco detection equipment. I made some early progress but I have been trying "trial and error" as there is no information available on the protocol used between components. Without such information from HRMS or a sample device to monitor I am stumped. I don't know if @zeroOneman has made any progress but I'm sure he would have told me/us if he had. As mentioned in previous posts we can't be sure the current version of RM even contains the loco detection code. There were some vague hints in my email exchanges with HMRS that the very long overdue loco detection might eventually appear, but that was back in September and nothing has happened. Sorry but there we are.

@zeroOneman I have posted a message on your blog. The more hands the merrier. I will write up what I have discovered so far so anyone else can have a go.

Sadly no. I have been trying various combinations of commands but none seem to be of interest to RM. We have no idea of the format, length or structure of the command from the sensor. We don't really know if the loco detection works at all with the shipped code. Rumour has it that LDM was demonstrated but that may have been on a development version of the code. I will keep trying with fingers crossed!

Again I don't think I am breaking any confidences by showing the response to my follow up question to RM Support about "when": "It is difficult to say exactly when this will be released as several things are going on, which will become apparent when we do announce the availability of the loco detection hardware. You will understand the problems we have experienced when this happens. Nobody more that our team, want to see this system on the market as it would immediately elevate RailMaster to being probably the best model control system on the market, certainly the best value system, without a doubt. Hold tight and await the announcement." So make of that what you will. Lots of hyperbole and scant detail. Given the public silence on this from Hornby for so many years it would be right to be skeptical. As @96RAF says the "techies" may want this to go ahead but the "suits" will be looking at the likely sales. It costs money to produce, launch and support a product even if it has been developed and there will be many calls on that money from competing Hornby products. Having said that I am the eternal optimist. In the meantime I will continue with my efforts. How successful this will be I don't know but at least progress is in my hands! In answer to @96RAF I will be happy to publish details of what I have done once I have something vaguely working, with suitable warnings. From my investigations so far, there are two kinds of sensors supported by the loco detection module, what they call "Optical" and "Magnetic". My assumption is the Optical is the barcode reader, the Magnetic is the magnet/reed switch reader. I am focussing on the latter for now.

Bit more progress on my DIY sensor. I managed to get past the initial handshake so that RM thought it was talking to a Loco Detection Module. Log entries: 15/09/21 10:06:53 Initialising loco detection module 1 with 9600,N,8,1 15/09/21 10:06:55 Opened com port for Loco detection receiver 1: Hornby LDM40 15/09/21 10:06:55 Loco detection module 1 firmware version: ÿþ 15/09/21 10:06:55 Loco Detection timer running (Detection delay: 10 secs) Now to try and fool it into thinking that a sensor has been triggered. That should be a bit easier as I don't have to stop and start RM every time I have a guess.

So, make of this what you will. I don't think I am breaking any confidences by showing the reply to my request for information. Question: "Hi there, Are there any specifications of the communications over the COM link between the announced but not shipped Loco Detection Module and Railmaster? In particular what does it expect in reply to the version request and what the LDM sends when a sensor is triggered. I am investigating whether it would be possible to connect an alternative sensor system like S88, not on a commercial basis. Thanks for any info you can provide. Kind regards, Dave Miller" Answer: "Dear Dave, Our loco detection system is more sophisticated than anything else on the market and therefore only our system will work with RailMaster. We cannot release details of the protocol used for the system as this is commercially sensitive. We do understand the frustration that the system has not been made available yet, however rest assured that it will be released and an announcement made at the same time, which will explain everything, including why it has been delayed for so long. Regards, RailMaster and TrackMaster Support Team" Not an unreasonable answer, prompt and friendly tone. Much as I was looking forward to learning python, no-one would be happier if they were to release their product. I will ask as a follow-up if they can provide an approximate timescale!

To report on (limited) progress: 1 - I have sent a request off to RM support as per Rob's suggestion, I'll let you know when they get back to me. I'm expecting a simple "no" or perhaps "no, it's proprietary information" or maybe even "no, we don't know" but we'll see. 2 - I have set up a test environment on my Windows PC to allow me to intercept the RM version request and provide a guess at the response, which seems to work as a mechanism, but the issues are that you only get one guess then you have to shutdown and restart RM, and you only get about a second to reply. There is no way to stop and start RM cleanly under program control so each guess takes a couple of minutes with human intervention. Given that I have no idea of the length or format of the required response the "guess" option is not going to be viable. If this idea is going to proceed we need the cooperation of RM support.

Thanks Fishy. I have already looked at the list of commands and there are many that require that the loco id is somehow provided. However I doubt the sensor will be detecting speed and direction, I think RM would do that based on readings from two sensors for the same loco id and would estimate the speed based on the x/y coordinates of the sensors and the time between the readings. But this is speculation. There are two sensor types, what RM calls optical and magnetic. I assume the optical sensor is the one that detects the loco id (reading barcode maybe?) and the magnetic sensor is the equivalent of a magnet and reed-switch that will just say some loco has triggered the sensor. Again this is speculation. My supposition is that for the magnetic sensor types all RM will be expecting is the sensor id that has been triggered. But who knows. I will take up Rob's suggestion of contacting RM support but I will not be holding my breath in anticipation of any response, useful or otherwise! :-)

Thanks Rob and Ray. Indeed, without specifications or an actual device we will have to guess. That would seem to be a Herculean task but I think all we need is: 1 - The response to the "v" command that will satisfy RM into thinking it is talking to an LDM 2 - The command to RM that indicates that a sensor has been triggered. I think those two will do for starters. I don't think we need an "untriggered" command (which S88 could provide) as RM has a setting that states how long until the sensor resets, 10 seconds by default I seem to remember. There may be ongoing "heartbeat" requests from RM but these will become apparent if we get past steps 1 and 2. I suspect these will be short and simple responses and commands, one character and a decimal value for the sensor number, for example. Lots of assumptions here but without any more knowledge that's all we can do. Now off to google "how to write a python program" :-)

As it seems increasingly unlikely that Hornby will ever release their Loco Detection Module, I thought I would investigate producing some kind of emulation of that device. These are my thoughts and limited findings so far. The LDM communicates over a COM port, presumably via a USB connection not an actual serial port. You can use a COM port sniffer to determine what data is exchanged over that port. I suspect the LDM protocol is going to be fairly simple. For example, from my investigation so far, at startup RM sends the command "v" to what it thinks is an LDM, looking for a version number. When that fails RM issues a message like "failed to get response to version request" and leaves it at that. At the other end, we need a sensor system which uses a COM serial protocol. S88 is a serial feedback bus based on the industrial ISA-88 protocol. S88 is used by several manufacturers, such as Maerklin, ESU, ZIMO, Uhlenbrock, to collect sensor data, and Littfinksi (LDT) produce a relatively cheap S88 interface with a COM port. In essence the system sensors are 5v switches, on or off. These can be triggered by train magnets passing over a reed switch, micro switches, infrared sensors or any mechanical or electronic on/off switch. I like S88 because it is a simple, non-proprietory published open standard. The downside of S88 is that it is just "on/off" so there is no loco ID information. This will limit the potential use of the sensors but it would be better than the nothing we have now. In the middle would be something that translates between what LDM is expecting and what S88 provides. Initially I am thinking of a software solution, such as a python program running under Windows. I have never written a python program in my life but I'm sure this sort of thing is possible. In order to do the translation we need to know the commands at each end. LDT publish a list of S88 commands as part of the documentation for their HSI-88 product, so that end is relatively well known. The big unknown in this exercise is, what is RM expecting to see from the LDM? Does anyone have the specifications for this, or even an actual LDM that we can use to monitor the traffic over the COM link? Without this information we would have to resort to guessing and trial and error. So that is my plan. Any information, comments, ideas or suggestions welcome.

Automated coupling / uncoupling is done using an LGB uncoupler with a point motor which can be controlled from RailMaster. Then it is just a matter of getting the timing right to raise the uncoupler as the train passes slowly over it to uncouple. To couple again just drive the loco slowly into the parked rolling stock.

It might be down to the DNS servers used by different ISPs. Maybe the ones BT use by default don't resolve the address RM is trying to contact. I don't know what that address is so hard to test this theory.

I have an HD screen 1920x1080 and I get that message too. I think it is because they take into account font magnification, which in my case is 150%, which if you do the maths takes the effective resolution down below the trigger value for that message. If I set the magnification to 100% the message goes away.

For a bit of fun, here's a video of my automated layout using RailMaster. No sensors were involved in the making of this film.

Yes thanks @westernwill it worked fine for me too. Helps a lot to copy activate.dat to the new PC first, it automatically fills in all the details including the licence key.