Train Identification

[St. Simon]

Hi All,

 

For the next exhibition layout, I will have a full Train Describer on view to the public so they can 'track' trains around the layout via their alphanumeric headcode and to drive automatic route setting when I'm running light on operators during breaks. This is being driven by JMRI onto an IECC like screen. 

 

The problem I have is that I need to be able to identifying and then matching the trains waiting in the fiddle yard to an appropriate headcode in the train describer. The easy bit is actually matching the train to the headcode, my plan is to write a script that runs in JMRI to drive the train describer and automatic route setting. The difficult bit is identifying what is actually on the track.

 

I'm looking for something that:

 

1 - Can provide some form of input that can be interpreted by a computer (probably a Raspberry Pi) / JMRI

2 - Be separate from train control. The layout will be DCC, however, I don't want the DCC and signalling / train describer to interact with each other (part from Track Circuits), just so if the signalling fails, I can still run the layout

3 - Identify the train leaving the fiddle yard (which will be cassettes, not a fan of roads) before they reach the first track circuit to prevent a 'Non-Described Alarm' on the panel. This might be less than an inch.

4 - Not rely on a sequence or a 'one train per headcode' system

5 - If required, a simple interface for operators (i.e., they don't have to remember headcodes or special procedures) 

6 - Deal with trains which could be hauled be one of several different locos.

7 - Deal with two multiple units coupled together that can be split to form different trains (i.e., only identify the lead unit)

8 - Ideally no operating interaction other than placing trains on the track and running them.

9 - Requires minimal, preferably none, stock modification

10 - Allows me to add additional formation easily and quickly (although not necessarily during an exhibition layout)

11 - Is relatively cheap

 

The obvious answer is RFID tags, but I'm not 100% convinced that it meets point 7, and whether it will be reliable enough at an exhibition (paricularly if stock is shaken around in a stock box in a van).

 

The reliabilty at a show isn't 'mission critical' as I will have the option to override head codes from the panel if required, but I want this system reliable enough that I can operate by myself (manning both fiddle yards and driving trains whilst the ARS route sets) for an hour or so.

 

If anyone has any suggestions, please advise!

 

Simon

[Robin2]

I know little more about JMRI other than the name. However I have done a bit of PC and Arduino programming so the concepts you describe are understandable.

 

It seems to me some of your wishes are mutually exclusive - for example if you can't add some tell-tale to the stock (9) how could any system tell the difference between a pair of MUs operating together and later operating separately (7).

 

The DCC codes for the motive power units will (presumably) be unique and might be a useful indicator were it not for your (6). Other than that I suspect you could use the DCC code without conflicting with your (2).

 

 

While you have listed a lot of constraints that you want to apply you have not described how the trains will be managed. In other words, at what point in the system will a headcode be allocated, by whom and to what?

 

If this is to be a "standby" system for when operators are having a break then perhaps you should greatly simplify the system - for example by associating a headcode with a train in a particular place in the fiddle yard.

 

...R

[St. Simon]

34 minutes ago, Robin2 said:

It seems to me some of your wishes are mutually exclusive - for example if you can't add some tell-tale to the stock (9) how could any system tell the difference between a pair of MUs operating together and later operating separately (7).

 

Hi Robin,

 

I see your point, I would be willing to add discrete tags to rolling stock as long as I don't have to start hacking them about to accommodate them.

 

38 minutes ago, Robin2 said:

While you have listed a lot of constraints that you want to apply you have not described how the trains will be managed. In other words, at what point in the system will a headcode be allocated, by whom and to what?

 

To give the full picture:

 

Normally at an exhibition, each fiddle yard will be managed by an operator who will also drive trains away from them. The route through the layout will be managed by the signaller or ARS using information from the train describer. The operation will be that the fiddle yard operated places a train, within a cassette, at one of entry points to the layout,  the operator will then start driving the train onto the layout. As it is driven onto the layout (but before it reaches the first track circuit), the train will be identified by the system we are discussing on this thread. This identity (assuming a unique number, but could be anything I suppose) will be inputted into the 'signalling computer' which in turn (assuming I've understood what I can do with a script in JMRI) will look up the identity a spreadsheet I have created, an extract below with the train ID column highlighted in pink:

 

 

(Ignore the ARS Weighting Factors column and the fact that there is more than one headcode column, that's for something else, what I'm interested in is how to fill out the column highlighted in pink.)

 

The 'signalling computer' will then pick the appropriate headcode from the spreadsheet and then insert into the Train Describer on the panel (see below) and, if in ARS, will set the appropriate routes for that headcode.

 

 

54 minutes ago, Robin2 said:

If this is to be a "standby" system for when operators are having a break then perhaps you should greatly simplify the system - for example by associating a headcode with a train in a particular place in the fiddle yard.

 

I think I've given you a false lead there, this will be the 'primary' system for identifying trains, with the signallers manual override on the panel being a 'standby' system. My point with the operators having a break is more that this primary system doesn't have to be 100% reliable 100% of the time, just enough that I can totally rely on it for a short period whilst the signaller is away.

 

As said further up, the fiddle yard will be cassettes rather than a siding fiddle yard. I know that I could just use a cassette per train, but that involves ensuring that operators will use the correct cassette for the train (and thus meaning I will also have to transmit the train identity to the other fiddle yard), as well as a few more cassettes than I actually need to operate the layout. Neither of which is a best solution.

 

Also, to add a bit of information, I'll probably have circa 20 trains in total that would have to recognizable to the identification system.

 

Simon  

[Robin2]

40 minutes ago, St. Simon said:

As said further up, the fiddle yard will be cassettes rather than a siding fiddle yard. I know that I could just use a cassette per train, but that involves ensuring that operators will use the correct cassette for the train

That makes me wonder if it would be practical for the person putting the train into the cassette to do something at the same time which would identify the train. Various "somethings" come to mind including setting a DIP switch (or similar) with a code that could be read by an Arduino (or similar) when the cassette is dropped into place. Another "something" might be a card with a barcode that could be read when the cassette is dropped into place.

 

Just my few cents.  It's an interesting problem.

 

...R

[Nearholmer]

If I'm understanding this correctly, you want to implement some form of "associate" function, which links an identity unique to a particular string of vehicles (the train in question) to a particular head-code, then at a later stage to be able to break that association.

 

If so, I think the problem you have is that the 'particular string of vehicles' doesn't naturally have a unique identity, because it can be made up of any old units (locos, emus, dmus, w.h.y.) each of which will have its own unique identity (vehicle number, DCC address etc) - it only comes into being when they are coupled, so it needs to be assigned an identity for the duration that it exists, and only for that duration. 

 

So, does DCC create associations (presumably it must, to allow double-heading, multiple MU sets in one train etc), does it assign an identity to each block of associates, and can you get at that identity and use it?

 

If you can do that, but don't want to because it makes things too DCC-reliant, then I think you have to assign the 'particular string of vehicles' identity separately, and have the  'particular string of vehicles' either shout its identity out (which sounds like an RFID token applied as it is marshalled), or carry a passive identity token to be read from the wayside (QR or barcode?), but I think that some operator activity will be needed to assign/affix/key-in the identity (and to remove it when the string of vehicles is re-marshalled).

 

I have no idea how this sort of thing is done on mainline railways, but I'm fairly sure that on metros the association between 'string of vehicles' and 'train number' (similar, but not the same, function as head-code) is initiated by the train operator (or remote equivalent on unmanned systems) when the 'string of vehicles' is 'woken-up' in the depot, and before it is called forward onto the running lines ........ very analogous to the FY situation ....... and that a 'string of vehicles' can't be called forward onto the running lines until the association has been made and proven. IIRC, on pre-CBTC systems, the train radio set in the live driving cab is what usually issues the identity, based on its own unique identity (equivalent of its MAC address, not the equivalent of its IP address, IIRC, although I'm now vexed as to how the train retains the same identity when it reverses direction and the operator changes ends ........ maybe the train operator has to initiate re-association each time).

 

Are you going to make this even more difficult for yourself by having trains divide/combine on stage? 'Cos I think that will involve de-assigning and assigning identities, and breaking and making associations in public! 

 

 

Edited December 29, 2019 by Nearholmer

[St. Simon]

1 hour ago, Robin2 said:

That makes me wonder if it would be practical for the person putting the train into the cassette to do something at the same time which would identify the train. Various "somethings" come to mind including setting a DIP switch (or similar) with a code that could be read by an Arduino (or similar) when the cassette is dropped into place. Another "something" might be a card with a barcode that could be read when the cassette is dropped into place.

 

Just my few cents.  It's an interesting problem.

 

...R

 

Hi Robin,

 

That was my first instinct, however from my experience on Norwood Road where I used a rotary switch to select a train for a basic train describer, I have found that either we forget to set it, or that it doesn't necessarily corresponded with the train on the layout, so I would prefer something that either doesn't require that interaction or is totally fool proof for the operators. 

 

45 minutes ago, Nearholmer said:

If I'm understanding this correctly, you want to implement some form of "associate" function, which links an identity unique to a particular string of vehicles (the train in question) to a particular head-code, then at a later stage to be able to break that association.

 

If so, I think the problem you have is that the 'particular string of vehicles' doesn't naturally have a unique identity, because it can be made up of any old units (locos, emus, dmus, w.h.y.) each of which will have its own unique identity (vehicle number, DCC address etc) - it only comes into being when they are coupled, so it needs to be assigned an identity for the duration that it exists, and only for that duration. 

 

Yes, very basically all I need the system to say is that the train is a, for instance, South West Trains unit or a Car Carrying Train, I don't need it to report an individual unit number. The problem is that I don't want to rely on my operators remembering which trains match which operator / service, which means it has to be reported by the train itself (or something attached to the train).

 

Most of the trains will be fairly fixed rakes, the only completely adjustable rake is my engineers / ballast rake which can be made up of a number of completely different vehicles. The Multiple units will mostly work singularly, but I want the option to work them in multiple without confusing the system.

 

45 minutes ago, Nearholmer said:

Are you going to make this even more difficult for yourself by having trains divide/combine on stage? 'Cos I think that will involve de-assigning and assigning identities, and breaking and making associations in public! 

 

I don't think so, the train only needs to be identified when entering the layout, I have done the logic to 'track' it around the layout using Track Circuits and the train describer can handle trains dividing / combining  on scene. The only problem will be the system identifying the lead unit in a consist when entering the layout and then overwriting the identity / headcode when it detects the second unit.

 

45 minutes ago, Nearholmer said:

I have no idea how this sort of thing is done on mainline railways, but I'm fairly sure that on metros the association between 'string of vehicles' and 'train number' (similar, but not the same, function as head-code) is initiated by the train operator (or remote equivalent on unmanned systems) when the 'string of vehicles' is 'woken-up' in the depot, and before it is called forward onto the running lines ........ very analogous to the FY situation ....... and that a 'string of vehicles' can't be called forward onto the running lines until the association has been made and proven. IIRC, on pre-CBTC systems, the train radio set in the live driving cab is what usually issues the identity, based on its own unique identity (equivalent of its MAC address, not the equivalent of its IP address, IIRC, although I'm now vexed as to how the train retains the same identity when it reverses direction and the operator changes ends ........ maybe the train operator has to initiate re-association each time).

 

It is very simple on the real thing, the Driver of the train enters the headcode of the service into the GSM-R radio unit on the train, which is then transmitted to the GSM-R system in the control center and in turn passed to the Train Describer equipment using the location data in the GSM-R. What I'm trying to do is replace the driver input.

 

Simon 

[Nearholmer]

I think that unless you lock particular items of rolling stock to particular services (=head codes), which your Rule 4 says you don't want to do (I can fully understand why), then you will need a human intervention equivalent to that made by the mainline train driver or metro train operator to forge the association between 'this string of vehicles' and 'this head code'.

 

There must be tens of ways for a person to input the information (being a tad mature myself, I rather like the idea of a bank of decent-sized toggle-switches beside each FY track), but do it someone must.

 

Its no different in principle from the old-school layouts that are operate by bell-code, on which the FY operator has to offer a train forward or accept a train. The FY operator has more to do than simply teeing-up trains.

[Robin2]

9 hours ago, St. Simon said:

It is very simple on the real thing, the Driver of the train enters the headcode of the service into the GSM-R radio unit on the train

That's the same as your operator entering the correct code when loading a train onto a cassette. Be the boss - impose discipline!     

 

If a particular vehicle always represented a specific train you could put a barcode or an RFID tag on it. But if that is not always the case then IMHO human brain power will be essential.

 

Maybe you could make a card with a barcode that also has a small magnet and a piece of iron in one of the train vehicles so when a train comes out of service the card can be taken off the cassette and attached to the train. Vice versa when the train is put in service.

 

...R

[St. Simon]

2 hours ago, Robin2 said:

That's the same as your operator entering the correct code when loading a train onto a cassette. Be the boss - impose discipline!     

 

Hi Robin,

 

We've all found when operating that enforcing those rules makes it more of a chore than fun when operating and my operators tend to ignore them anyway!

 

Simon

[PaulRhB]

You’ve run into one of the problems automating real signalling has, we haven’t found anything that can completely eliminate the human! How does a system tell if it’s empty coaching vs a class 1,2 or 9? 
I think tagging a key piece of rolling stock in each train may work but how do you run a light loco unless a 0 head code is immediately ‘overwritten’  by the wagon / coach tag behind?

Is it possible to have an ID tag on the train that offers a default headcode that gives the FY operator a simple confirm prompt, if no is selected it offers a list of associated head codes to click on. 
I think simplifying the interaction is going to be the easiest way rather than trying to automate it out. 
Ultimately the pc can only process what’s input so you need something to select that input, either a pre determined sequence with manual override or just manual selection like the real thing, which is why manual input has lasted so long on the real thing. Mind you them forgetting to change it is also realistic as I’ve often seen trains shunt with their arriving headcode or where they change to empties carry on with the old one, that’s also usually true of the GSMR set up!

[Nigelcliffe]

There are several solutions, but I think all have the same issues around multiple units coupled together.  Doesn't really matter if its RFID, barcodes, IR transmitters (Lissy system), Ultrasonic identification, or something else.    And that it can be solved in the higher software.

 

First example:  Passenger train, loco hauled.  Here the Loco and the lead coach in the rake might be detected.  The software would identify both, and could look up a matching train number based on time, sequence through timetable, and stock which can "legally" make up that train number. 

 

Second example:  Multiple unit with two DMUs.   The lead DMU would be detected, and shortly after the second unit.   The software can match the lead DMU against legal train numbers. 

 

Whether you can do this without any human intervention depends on the rules in your system as a cassette is connected to the system.   You might need human intervention for some trains - ie the system goes "beep" and demands a human choose between potential train numbers, but it could be a short list based on the identity of the stock/loco.    (Which is essentially what Paul has said above ).

 

 

 

- Nigel

 

[Edwin_m]

If your DCC system supports Railcom, and you dedicate each cassette to a particular train, then you could have a Railcom-equipped decoder connected to the rails on the cassette.  That way as soon as the cassette was electrically connected to the layout, the system would identify it.  

 

Similar idea might be to have an RFID tag on the cassette instead, and a reader positioned so it was within range when the cassette was attached to the layout.  

 

If the cassettes aren't dedicated then the train identification would require the system to "remember" which train was on which cassette, assuming they aren't swapped around by hand in the meantime.  

[St. Simon]

Hi,

 

Interesting thoughts, in terms of loco-hauled stuff, I think I can get away with having a tag on the lead vehicle behind the loco, and ensure that this is always at the head of the train. I'll just to make sure there is at least a loco length between the reader and first track circuit.

 

Having thought about it last night, coupled multiple units could be dealt with by having a, say RFID, tag offset to one side like below?

 

 

In this case, to run the two units separately, you just turn the trailing unit around so that the tag is on the right side of the track. This might also work for light engines and loco hauled trains. Of course, this would limit me to two multiple units together, but that is the maximum that I can have on the layout anyway.

 

Is there a system that that can be precious enough to allow this, or would it pick up both tags as they would only be 20mm (or less) apart laterally. 

 

If not, I like the idea of a swipe card system that Robin suggested, how easy would that be to implement.

 

My concern about having even a simplified operator led system is that on the layout I would require a choice of at least a dozen simplified choices, which would either inquire a dozen separate inputs into the signalling computer or a complex communication arrangement between a TD computer and the signalling computer, it would also prevent me from easily adding to the roster later on as it would might require hardware modifications. I may be wrong on these points, and if I am, please say!

 

Simon

[Nigelcliffe]

I doubt your off-set tags would be reliable - the reader may still pickup the trailing tag. 

 

It may be simpler to have operator confirmation of actions, then the second tag doesn't get confirmed, and times-out on the system. 

 

 

- Nigel

 

[NIK]

Hi Simon,

 

I've done quite a bit of work on RFID for model railways.

 

You may find that with commercial RFID readers that the range across the track (parallel to the sleepers) is too much to facilitate ignoring a tag placed on the opposite side of the multiple unit or loco. Might be worth experimenting with (mustn't reduce the range parallel to the rails too much).

 

I'm not sure having two RFID tags on a train is deal breaker but I haven't used JMRI much for RFID tag reporting.

 

As to RFID reliability I've found with 125kHz RFID and OO DCC trains that an hours worth of running without an error may be achievable (might need to isolate the track above each RFID reader and provide track power feed on centre line of RFID reader).

 

EDIT I may have a similar application in future but probably minus the automatic route setting. At first I may just put simple information on the display facing the public such as details of loco/multiple units within train.

 

Can you put an extra RFID reader under where the cassette connected to the line leading out of the fiddle yard is placed?. Maybe that could read subsequent RFID tags before the train is too far on to the layout. END EDIT

 

Regards

 

Nick

Edited December 30, 2019 by NIK
Extra info

[Robin2]

5 hours ago, St. Simon said:

We've all found when operating that enforcing those rules makes it more of a chore than fun when operating and my operators tend to ignore them anyway!

That's why I had two smileys 

 

...R

[Robin2]

If a train is only intended to have one RFID tag then perhaps the software could be programmed to ignore any others that it detects in the same train.

 

...R

[St. Simon]

38 minutes ago, NIK said:

Hi Simon,

 

I've done quite a bit of work on RFID for model railways.

 

You may find that with commercial RFID readers that the range across the track (parallel to the sleepers) is too much to facilitate ignoring a tag placed on the opposite side of the multiple unit or loco. Might be worth experimenting with (mustn't reduce the range parallel to the rails too much).

 

I'm not sure having two RFID tags on a train is deal breaker but I haven't used JMRI much for RFID tag reporting.

 

As to RFID reliability I've found with 125kHz RFID and OO DCC trains that an hours worth of running without an error may be achievable (might need to isolate the track above each RFID reader and provide track power feed on centre line of RFID reader).

 

EDIT I may have a similar application in future but probably minus the automatic route setting. At first I may just put simple information on the display facing the public such as details of loco/multiple units within train.

 

Can you put an extra RFID reader under where the cassette connected to the line leading out of the fiddle yard is placed?. Maybe that could read subsequent RFID tags before the train is too far on to the layout. END EDIT

 

Regards

 

Nick

Hi Nick,

 

hmmm, what you say doesn’t surprise me, I thought the ‘detection’ field might be a bit large for offset tags.

 

Detecting two tags is only a problem because of the need to prove whether the second tag is  genuinely a second train or is part of the first train.

 

Simon

[St. Simon]

Hi,

 

Just had a brainwave, would it hurt an RFID reader to only be connect to power for a short time?

 

My think is that the reader is only ‘active’ whilst a button is pressed by the fiddle yard operator for a short time to identify the first vehicle in the train. There the reader is not active when a second tag passes over the reader.

 

Simon

[NIK]

Hi Simon,

 

There may need to be an infrared or similar position detector and timer function (JMRI?) in order to decide what forms one train or is two trains close together.

 

I'm helping others in MERG on developing a lower cost, higher reliability RFID system for model railways.

The tags and RFID modules used have the ability to write info to the tags.

 

So it may be possible to write specific train info to the leading RFID tag as the train moves towards the end of the cassette and on the scenic section.

 

Regards

 

Nick

[NIK]

2 minutes ago, St. Simon said:

Hi,

 

Just had a brainwave, would it hurt an RFID reader to only be connect to power for a short time?

 

My think is that the reader is only ‘active’ whilst a button is pressed by the fiddle yard operator for a short time to identify the first vehicle in the train. There the reader is not active when a second tag passes over the reader.

 

Simon

Hi Simon,

 

It depends on the design of the reader and the interface to JMRI as to how they deal with power ups.

 

Probably will be ok electronically.

 

 

Regards

 

Nick

[melmerby]

Keep it powered up and only take a reading when asked for (e.g. some sort of switching of the signal into the logic.)

[St. Simon]

Hi,

 

 Could you cut a push to make button into the data connections, so the data wires are only ‘complete’ when the button is pushed?

 

Simon

[Nigelcliffe]

 

I think my point is the same as the one line from Keith (Melmerby), above. 

 

If you're planning to script this into JMRI, then separate "register" button(s) could be added to the fiddle yards, and when pushed, that allows a RFID tag to be read in the next few seconds (time determined in software).   Can have lights (signals?) in the fiddle yard to indicate "reading due to happen (button push acknowledged)" and "train identified, free to depart (tag read, identified, matched)".     Thus, don't need to power on/off readers, they're active at all times.   It's the software which decides whether to make use of any RFID data.  

 

- Nigel

 

[5BarVT]

Hi Simon,

I haven’t read all the posts (sorry!), but I thought I would float a ‘simple’ system if it meets the way you operate.

Are your cassettes dedicated to a train or do you swap trains around? If not dedicated, stop here!  Otherwise read on.

Could you include a D connector on the end of the cassette that makes up when the cassette is pushed up against the departure track?  If so, then just strap a code on the the cassette connector to identify the train. (9 way D = 8 bits plus common.)

Paul.