Jump to content

Loco Detection


Recommended Posts

  • Replies 72
  • Created
  • Last Reply

It all starts somewhere and at sometime.

Switch on the layout, crank up RM and then what: - press a button, or wait for the clock to hit 'time to go', or blow the whistle and hopefully it all kicks off.

After that future events can be triggered by previous events, but as rpj says how do you set it off initially.

I shall wait until you guys prototyping LD with signals, routes and whatever else, have sorted it all out and I will poach your findings.

Rob

Link to comment
Share on other sites

So, PJ, the first command in the list you put up earlier is - on signal green. How does Loco detection know which signal and whether or not it's green?

 

Hi rpj

 

Basically you set up your system, the correct way to start wouod be for all signals to be green for blocks that are not occupied. A block being the gap between two signals for instance, but is actually the gap between the two sensors near to those signals.

 

It is therefore not until a train/tender and a last carriage passes over a sensor that LD knows and tells RM.

 

Let's take out of the equation the tender and last carriage to keep it simple for the example. Let's just say we are running a 0-6-0 round the track. When the train passes over the sensor it sends two items to LD to inform RM of them, e.g. TRAIN0-6-0  and senser30 for example.

 

This is the first RM s aware and looks up these two codes in the sensors list of pre-programmed commands, it this carries out the instructions relating two the above two codes. One will probably be when TRAIN0-6-0 passes this sensor change the signal near it to RED. Being a small train it may also have instruction to alter the previous signals depending on what aspect they are.

 

e.g. a two aspect would be no additional instructions for previous signals as it is either R or G.

 

A 3 aspect signal on the other hand could request the previous signal SIG25 to change to Y and SIG20 before that to G.

 

A 4 aspect signal could request the previous signals down the line to change SIG25 Y, SIG20 YY, SIG15 G

 

So LD knows where your train is (by codes picked up when the train passed over the sensor) and has carried out commands pre-programmed to that LD sensor through the LD controller and RM. None of this is shown on your RM screen (except signal colour aspect changes). You are the engine driver.

 

PJ

Link to comment
Share on other sites

The thing I wonder about is, if LD knows what is where and when and can change signals, etc, why can't RM then paint the locos progress along a route in real time.

And if it knew the length of a train (by prior definition in a table) then it could show representative train length as well on the plan.

Link to comment
Share on other sites

The thing I wonder about is, if LD knows what is where and when and can change signals, etc, why can't RM then paint the locos progress along a route in real time.

And if it knew the length of a train (by prior definition in a table) then it could show representative train length as well on the plan.

 

Hi RAF

This was mentioned previously, I think the answer is LD Pro!!!

PJ

Link to comment
Share on other sites

The thing I wonder about is, if LD knows what is where and when and can change signals, etc, why can't RM then paint the locos progress along a route in real time.

And if it knew the length of a train (by prior definition in a table) then it could show representative train length as well on the plan.

 

Hi RAF

This was mentioned previously, I think the answer is LD Pro!!!

PJ

 

No doubt another 30 quids worth on top of the basic three figure system cost...

Link to comment
Share on other sites

Something extremely important has been forgotten in this argument:  RM has absolutely no idea where any of your locos or rolling stock are on your layout!!

 

Let that sink in for a minute, then ask me your next question:  that may well have been true before LD Fishy, but LD changes all of that doesn't it?

 

Let me assure you - NO IT DOESN'T!  Neither will it with some mythical LD Pro.

 

What LD gives you is that, whenever a tagged loco passes over an LD detector, it is detected for which loco it is, and its speed and direction of travel are known (although what "direction" might mean is interesting).

 

The fundamental problem though is that RM has no idea where the detectors are, only that they exist.  Just as it has no idea where your points and signals are, only that they exist.  You know where they are, you can see your actual layout.  You've also designed your layout into RM, but it isn't your real layout, just a representation of it for your convenience, and certainly not to scale.  From RM's perspective, the only things of interest in your layout are the points, signals, LD detectors and any other operating accessories like a TT.  Having designed your layout and put everything in, it would make no difference to RM whatsoever if you were now to remove every piece of straight or curved track that doesn't incorporate a signal or an LD detector.  It's knowledge about your layout remains exactly the same.  Try thinking about removing all of that track yourself and see if you can figure out where anything is.  You can't can you?  Neither can RM.

 

The only way that this can change is if RM were to completely change its layout design philosophy.  The change would mean that you would have to put a scale model of your layout into RM.  Now, distance and time could be meaningful to a point.  In fact a number of points being the LD detectors.

 

But I'll suggest to you that such a change isn't going to happen in any LD Pro anytime soon.

 

And yes, I've put my hat at risk again.

 

And apologies in advance if you think I've been condescending here.  I'm sure that some of you realised all that I've said, but I'm pretty sure others haven't, given the discussion so far.

 

PS.  There have been a few more posts while I was typing this, in fact only the post at the top of the page was there when I started.  But none of the subsequent posts change anything.

Link to comment
Share on other sites

Yes but the rest is explaining how it will work in quite fine detai, yet nobody knows epccept the boffins developing it. 

 

WTD, it is possible to talk in quite fine detail because we know an awful lot of detail.  We know that we can write programs for our locos and what the instruction set is for those programs.  And we know we can write instructions into the setup for our points, signals and LD detectors too, and what those instruction sets are.  The only thing is that these sets are almost certain to change as things develop, and we don't know what these changes will be.  But I would suggest at this stage that any such changes will be evolutionary not revolutionary so our current knowledge is a good starting point.

Link to comment
Share on other sites

I'll take your word for it fishy. All I'm saying is that any knowledge of LD you can obtain from RM is surely guesswork. Hornby would be daft to give any clue until patents have been applied. If you can work out what it's going to do then a boffin from another company will find it a piece of cake. Still keep it up it obviously keeps you all off the streets. 

Link to comment
Share on other sites

My belief WTD is that the patents relate to the hardware and how it operates, not the software.  The software instruction sets have been known for some time because they are in the existing latest version of RM and a number of previous versions.  Even if you don't have access to RM, PJ has posted the detector setup instruction set a couple of times recently.

 

Now they may have included a completely wrong set of instructions to put people off and will only put the real ones once the hardware is released, but I don't think so.

Link to comment
Share on other sites

My hat is on the patents relating to implementation of speed and direction into the detection system.

 

Imagine trying to keep ahead of the game by patenting some software logic, you'd get overtaken by the geeks in no time flat and be behind by the time the patent was granted. 

 

Maybe a sweep on this would be useful?

Link to comment
Share on other sites

My belief WTD...

PJ has posted the detector setup instruction set a couple of times recently.

 

Now they may have included a completely wrong set of instructions to put people off and will only put the real ones once the hardware is released, but I don't think so.

Hi Fishy

I cannot believe for one minute HRMS have put in wrong instructions to put people off!

What have you eaten or drunk over Christmas New Year? (Not to be taken the wrong way!)

What HRMS have put on to RM, as you and I have said before, are details to make us talk about the system, it certaily worked  ;o)  As WTD has commented 'Is it here then!'  as there has been so much talk!  LOL

HRMS have even added more commands to the LD sensors in track plan in RM when they were suggested to them.

That doesn't say to me they are laying completely wrong commands?

PJ

Link to comment
Share on other sites

Well I do think so fishy.  If what they have developed is a true 'eureka' moment they ain't going to give even a clue. They might have let their original idea float about to keep you all busy. 

You are right WTD

They can show us commands in RM but are not giving away the Eurika bit, the sensor/tag reading part which is so important to them and getting the patent, they are not going to give anyone a clue of those details and more than what we already know 

PJ

Link to comment
Share on other sites

My hat is on the patents relating to implementation of speed and direction into the detection system.

 

Imagine trying to keep ahead of the game by patenting some software logic, you'd get overtaken by the geeks in no time flat and be behind by the time the patent was granted. 

Fishy

 

I would agree totally as stated to WTD, Hornby patent is most important to them. 

 

But after this, after the installlation of the hardware that is being patented, after the connection of the LD controller, then we have data sent to RM for processing. It is how RM processes the data from LD that is part of the over all package but not part of the patent. That is what is being discussed regarding signals and sensors.

 

personally I am not bothered at alll about the patent, that will happen, production will happen, the launch will happen. The main points, I feel, are what we are discussing, regarding the workings of our trains with the commands we can see LD will have, supplied by HRMS for us to discuss. If we see something works good we share that information for others. If we something that could be an issue, we discuss it, as many minds and view points help see more areas. It is not wrong to say, I feel, hang on what happens if this or that and I see no way with the commands so far to get round this. Again this is another good reason for HRMS to float the situation for us to discuss.  It gives them feedback prior to launching the system.

 

PJ

Link to comment
Share on other sites

That's my point fishy. You have to keep everything from the geeks.  

 

One of you will touch a nerve eventually and the thread will be pulled. 

Hi WTD

 

Discussions are good, providing they remain discussions. 

 

It is when someone digs there heels in to only see one side that things can get stretched. There has been a couple of items in the last few days that fishy has mis-read or mis-understand. I have commented and said, lets move on... I have tried explain the mis understandings.

 

I also say, this is a very complex issue, signals and sensors and changing signals behind a train, I have found many times that it can be hard to try explain a situation, which means it can be easy to mis read.

 

I had a similar situation with HRMS this last week with signals down the line. They replied at one point to say I was programming signals up the line, they should be down the line. Looking on a screen it appeared that way, I then replies to show I wasn't and provided another image with 6 signals to show what was programmed was right. They are working on the issue, which I can confiirm is now down to one small item.

 

The situation here wass on screen what they said looked right, at one point the day before my head was spinning and I almost thought the same. If you look at a screen it appears one way, if you look at it as the engine driver it proved correct as did the codes programmed in to the signal. We have to be open to see things how someone else sees them, then assess the situation again.

 

I like the example of ,the car that crashes outside your window, you saw it!  The person dwn the road walking towards the car saw what happened also, as did the person behind the car and the driver. It is when you have the collective views you see better the fuller picture.

 

PJ

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
  • Create New...