DCC Train Information System

[garethevans1986]

So my background is IT, a software engineer / network engineer / devops / technical architect / solution architect of 10+ years and I've always been intrigued with the DCC system that our club layouts use and what could be picked up "off the wire".

 

Using a NCE DCC Analyser (now unfortunately discontinued) with a Serial port on, I managed to be able to do just that, seeing the DCC Id, Speed Step and Direction of a loco moving was pretty cool.

 

We started off storing this data in a database and querying the movement data, coupled (no pun intended) with a seperate database with train information in, we combine both datasets when we query the movement data to give the following output on a screen for the public to see.  See below.

 

 

We're able to "see" a loco appear on the TV around 5 seconds once it's Speed Step being greater than 1. We were able to handle, single direction and dual direction trains with separate data eg DMU on the Up and Down with different headcodes and train information.

 

It's first outing was at the Great Electric Train Show at Gaydon as part of the Mostyn layout in early October this year, having been kept under wraps for a few weeks.

 

It's first outing went well, we had a memory leak on the Saturday which was fixed pretty quickly and due to the amount of data it was storing (everything) we decided to ignore anything where the Speed Step was at 0 for the time being.

 

Over a 2 day exhibition, we we're storing 70k+ movement records where 7k were where the Speed Step > 0.

 

I have a document covering the entire system, which I can grab and publish here if anybody is interested. It's a work in progress but anybody interested in knowing how it's been built or anything, just get in touch.

 

If you saw it working on Mostyn at the GETS, I'd love to know what you thought. We had plenty of people talk and ask questions about it over the weekend.

 

Edit - Attached Solution architecture document.

 

Thanks

Gareth

DCCTrainInfoSystem_v0.1.pdf

Edited November 2, 2017 by garethevans1986

[Gordonotron]

Very interested! looks nice and a cool touch these days.

 

On the IT side, can you make the browser window full screen?

[leopardml2341]

Well, I was impressed!

 

It certainly adds another dimension to the operation of a layout. Over time, I think I've come to the conclusion that authentic operation of a layout iaw real railway principles and recognisable traffic flows is what makes a favourite layout for me.

 

I count myself fortunate to be one of the operating team on this layout:

 

http://www.rmweb.co.uk/community/index.php?/topic/64065-leeds-city-the-midland-side-in-4mm/

 

I'm starting, I think, to get the hang of it - but others are probably a better judge, eh John? (aka The Laird).

[Phil Bullock]

Always fancied something like this for Abbotswood

 

But not sure IT skills up to it!

 

Phil

[leopardml2341]

Always fancied something like this for Abbotswood

 

But not sure IT skills up to it!

 

Phil

My plan is to use the info to announce and progress a train (by its headcode) through a signalling area; of course this will require a loco shed roster board to be completed as well and thus the allocation of a loco to service in the WTT.

 

That'll be enough to keep 'control' off the signalman's backs

Edited October 23, 2017 by leopardml2341

[Phil Bullock]

Nice plan Andy - we already have locos allocated to trains and with correct headcodes - easy for you with all those disc headcode 24s!

 

Phil

[garethevans1986]

I've edited the original post and added the document showing how the system works and the solution architecture too.

 

Interesting Gareth. Just wondering why would you want to store all this data? It's of little value once it's out of the DCC system, unless you have the ability to replay the exact sequence, timed to perfection with perfectly consistent rolling stock behaviour on the exact same layout for an attempt to automate things. In which case there are better programs to sequence through some sort of timetable

 

Technically speaking, you're just reading the DCC output stream. Which is a fairly easy interface to make using a microcontroller, or even a serial port on its own. The rest of course is code. Which I can't

 

To be honest with you I dont know why we store data once it's over 30/60 minutes old, the other thing is the database we use (MongoDb) is very flexible and will handle lots of data so it's not really an issue. We have added a little extra and have time v speed step by loco graph so we can see how the locos were driven over time too. I've not looked at it yet but it'll be interesting to see.

 

The one thing we're not interested in at all is automation, it just doesnt do it for us (as a group) or me either. Yes technically speaking all we are doing is reading off the DCC stream "off the wire", serialising it and then chucking it into a message queue. It's the electronics I cant do but the coding I can!

[garethevans1986]

Very interested! looks nice and a cool touch these days.

 

On the IT side, can you make the browser window full screen?

 

Thats something one of our fellas asked during the show - something we're going to look into. We used an Android TV box so may see if the TV has a browser on natively to do this.

Well, I was impressed!

 

It certainly adds another dimension to the operation of a layout. Over time, I think I've come to the conclusion that authentic operation of a layout iaw real railway principles and recognisable traffic flows is what makes a favourite layout for me.

 

I count myself fortunate to be one of the operating team on this layout:

 

http://www.rmweb.co.uk/community/index.php?/topic/64065-leeds-city-the-midland-side-in-4mm/

 

I'm starting, I think, to get the hang of it - but others are probably a better judge, eh John? (aka The Laird).

 

Thanks Andy. We hoped it would and it did. It's a shame I cant go to Warley with Mostyn this year

[Steven B]

A great bit of tech to add more intest to one of my favourite layouts!

 

Am I alone in wondering why SO (Saturday Only) trains are running on the same day as MSX (Monday/Saturday excepted). Has Mostyn moved to the international date line? 

 

 

Steven B

[davepallant]

This is really interesting and has sparked an idea for use on one of our club member's layouts - Alderford by Carl Bowden. Its around 40feet long and feeds trains in from two lines at the fiddle yard into a 5 platform terminus. The big problem is the huge amount of stock used which means the trains come in with locos that are effectively random as far as the station operators are concerned. The trains then go out with replacement locos leaving the inbound locos to go off for dieselling. That means that if you don't recognise the loco from the other end of the layout you need to ask for and be told the address of the moving train. All it turns out we need is to filter the DCC feed by speed and controller number and then put the inbound addresses up on a screen or some other display on the end they are coming from that can be seen at the other end. Simples!

 

I have a board with a DCC interface feeding an Arduino using the OpenDCC software. It might be that I can use that system as DCC sniffer and maybe some pre filtering and then pass interesting data out on the RS232/USB link to a PC. Its quite possible that the Arduino has enough computing power to decode the messages, filter then by direction and speed and display the operating addresses on a couple of (very) large seven segment displays.

 

The question is - are all of our locos going to be going in the same direction DCC message wise when coming into the station or is the system going to have to be taught the direction of each loco? If I were to sniff the Lenz bus presumably I might be able to get the controller number as well which would tell me which position on the layout was controlling the train and hence where it was coming from?

 

Dave

 

[NIK]

This is really interesting and has sparked an idea for use on one of our club member's layouts - Alderford by Carl Bowden. Its around 40feet long and feeds trains in from two lines at the fiddle yard into a 5 platform terminus. The big problem is the huge amount of stock used which means the trains come in with locos that are effectively random as far as the station operators are concerned. The trains then go out with replacement locos leaving the inbound locos to go off for dieselling. That means that if you don't recognise the loco from the other end of the layout you need to ask for and be told the address of the moving train. All it turns out we need is to filter the DCC feed by speed and controller number and then put the inbound addresses up on a screen or some other display on the end they are coming from that can be seen at the other end. Simples!

 

I have a board with a DCC interface feeding an Arduino using the OpenDCC software. It might be that I can use that system as DCC sniffer and maybe some pre filtering and then pass interesting data out on the RS232/USB link to a PC. Its quite possible that the Arduino has enough computing power to decode the messages, filter then by direction and speed and display the operating addresses on a couple of (very) large seven segment displays.

 

The question is - are all of our locos going to be going in the same direction DCC message wise when coming into the station or is the system going to have to be taught the direction of each loco? If I were to sniff the Lenz bus presumably I might be able to get the controller number as well which would tell me which position on the layout was controlling the train and hence where it was coming from?

 

Dave

 

DCC Arduino.jpg

 

Hi,

 

The controller number is not in the DCC protocol itself so you would have to sniff the cab bus as well to get the controller number (if the cab bus sends the controller number - it may not need to if the throttles send the DCC number to the command station followed by the demanded speed).

 

Direction as you say is tricky as I think it depends which way the loco was put on the track as to which is forward.

 

If all the decoders had Railcom then a Railcom detector section at each entrance line to the station might do.

 

You could use RFID (radio frequency Identification) instead of Railcom but would have to attach a tag (typically 12mm x 2mm diameter) under each loco. I think RFID using cheap commercial tags is still experimental (£1.30 per tag).

 

You could also write the DCC address of the outgoing train on a small white board above the fiddle yard if they are within sight. You could write the DCC address on a piece of paper, put the paper in an ball shaped woollen pouch and throw it to the literally receiving operator.

 

If you are into Arduinos you could have two Arduinos the fiddle yard end with a keypad and display and a wireless or CAN bus link between them. Or maybe the Arduino would allow the direction info to be entered manually (one switch instead of a keypad) and then sniffing the cab bus at the station end (display only needs to be 5 digits 4 for DCC one for - or blank for direction).

 

Regards

 

Nick

Edited November 17, 2017 by NIK

[leopardml2341]

but as RFID has been mentioned, see MERG!

 

No connection, not even a member and haven't used the product; just sharing info

[Nigelcliffe]

This is really interesting and has sparked an idea for use on one of our club member's layouts - Alderford by Carl Bowden. Its around 40feet long and feeds trains in from two lines at the fiddle yard into a 5 platform terminus. The big problem is the huge amount of stock used which means the trains come in with locos that are effectively random as far as the station operators are concerned. The trains then go out with replacement locos leaving the inbound locos to go off for dieselling. That means that if you don't recognise the loco from the other end of the layout you need to ask for and be told the address of the moving train. All it turns out we need is to filter the DCC feed by speed and controller number and then put the inbound addresses up on a screen or some other display on the end they are coming from that can be seen at the other end. Simples!

 

I have a board with a DCC interface feeding an Arduino using the OpenDCC software. It might be that I can use that system as DCC sniffer and maybe some pre filtering and then pass interesting data out on the RS232/USB link to a PC. Its quite possible that the Arduino has enough computing power to decode the messages, filter then by direction and speed and display the operating addresses on a couple of (very) large seven segment displays.

 

The question is - are all of our locos going to be going in the same direction DCC message wise when coming into the station or is the system going to have to be taught the direction of each loco? If I were to sniff the Lenz bus presumably I might be able to get the controller number as well which would tell me which position on the layout was controlling the train and hence where it was coming from?

 

 

If you can read the Lenz bus, that will give you some information, but not all.    Ditto the DCC track feed.    What's lacking is where on the layout, and actual direction of travel because that's "loco front = forwards".   Actual direction of travel may not be critical.   But, none of these sniffing methods can distinguish where a loco is on the layout, you'll be told about a loco at the buffers, one running, one in the fiddle yard, etc..   

I think the only way you'll get that information out of DCC will be using RailCom, with readers on sections of track.  RailCom is present on a Lenz system, but needs RailCom capable decoders in locos.  You may need two successive RailCom readers on sections of track to determine actual direction of travel (if you find you need this).   Non-RailCom decoders will still work, but don't report anything.  You can fit second RailCom decoders to locos, but its expense if there is a big fleet.

 

If the layout was fully track-circuited for occupancy, then knowing the initial state of all locos, it would be possible to track every loco move and inform operators as to which loco was which.   But, if the layout hasn't been wired this way, and hasn't been fitted with occupancy devices, its a massively expensive undertaking.  

 

 

As Andy Sharpe says, RFID might be simpler for some of this.    If every loco carries an RFID tag, and there are readers on the exit of various fiddle yards, then the loco can be read as it passes a reader.  The RFID tag code can be matched to the DCC address, and that information displayed for operators to read.  (And as the loco goes off-scene to the fiddle yard, it could be read again and removed from the list of locos active on the layout).    A hand-held scanner can be used to identify any loco by waving it close to the loco. 

 

 

 

- Nigel

[NIK]

If you can read the Lenz bus, that will give you some information, but not all.    Ditto the DCC track feed.    What's lacking is where on the layout, and actual direction of travel because that's "loco front = forwards".   Actual direction of travel may not be critical.   But, none of these sniffing methods can distinguish where a loco is on the layout, you'll be told about a loco at the buffers, one running, one in the fiddle yard, etc..   

I think the only way you'll get that information out of DCC will be using RailCom, with readers on sections of track.  RailCom is present on a Lenz system, but needs RailCom capable decoders in locos.  You may need two successive RailCom readers on sections of track to determine actual direction of travel (if you find you need this).   Non-RailCom decoders will still work, but don't report anything.  You can fit second RailCom decoders to locos, but its expense if there is a big fleet.

 

If the layout was fully track-circuited for occupancy, then knowing the initial state of all locos, it would be possible to track every loco move and inform operators as to which loco was which.   But, if the layout hasn't been wired this way, and hasn't been fitted with occupancy devices, its a massively expensive undertaking.  

 

 

As Andy Sharpe says, RFID might be simpler for some of this.    If every loco carries an RFID tag, and there are readers on the exit of various fiddle yards, then the loco can be read as it passes a reader.  The RFID tag code can be matched to the DCC address, and that information displayed for operators to read.  (And as the loco goes off-scene to the fiddle yard, it could be read again and removed from the list of locos active on the layout).    A hand-held scanner can be used to identify any loco by waving it close to the loco. 

 

 

 

- Nigel

 

Hi,

 

Davepallent's first post proposing sniffing the layout busses might be close to a working solution.

 

The requirement seems to be identify trains coming from the fiddle yard and display their DCC address and direction (the direction specified in the DCC speed step message).

 

Trains coming from the fiddle yard might mainly be above a certain speed.

They will also have to traverse the approach(es) to the station.

They will be above a certain speed for a certain time due to the distance from fiddle yard to station.

 

So maybe there is enough information to do what is required:

a) Sniff DCC bus looking for DCC speed steps > than a threshold.

b) Also look for that DCC speed step/address combo to be above that threshold for n seconds.

c) Fit two infra red detectors in a row a set distance apart to each approach road to the station.

d) Use Infra red detectors to: 1) Confirm train is approaching 2) measure speed - if its way off the speed step profile it may not be the correct train - display eg: 1234?.

e) sniff cab bus to determine controller (only needed if  fixed controllers are used for fiddle yard to station moves).

e) use direction data for DCC speed steps that meets the criteria above and display that to the station operators.

 

 

Diy DCC sniffer designs exist on the Internet using Arduinos - I've made and used one. Might be able to modify interface and software to sniff cab bus.

Infra-red detectors are available. MERG also do a twin Infra Red detector - Ive used one to make a speedometer.

 

If there are a wide range of gear ratios in the locos on the layout then the above may not work reliably as the system may pick up slow moving shunting engines being sent highish speed step commands for a long period of time may look like a train approaching the station.

If the layout has signals on the station approaches and trains are ever held there then things become more complicated. 

If the all approaching trains are being driven from a subset of throttles that does make the task easier.

 

Regards

 

Nick

 

PS I'm researching a position sensing system for entire fiddle yard baseboards based on a video camera connected to a small single board computer, also Intel has released a video camera circuit that also measures the distance to each pixel - a potential train sensing system (might not work if train is under a dusty canopy).

Edited November 17, 2017 by NIK

[PaulCheffus]

Diy DCC sniffer designs exist on the Internet using Arduinos - I've made and used one. Might be able to modify interface and software to sniff cab bus.

Infra-red detectors are available. MERG also do a twin Infra Red detector - Ive used one to make a speedometer.

 

Hi

 

The Sniffer design on http://www.opendcc.net/elektronik/dcc_sniffer/dcc_sniffer.html is able to sniff the Lenz XpressNet with the correct firmware and a minor change to the hardware. I've built one and it works very well.

 

Cheers

 

Paul

[Nigelcliffe]

Hi,

 

Davepallent's first post proposing sniffing the layout busses might be close to a working solution.

 

The requirement seems to be identify trains coming from the fiddle yard and display their DCC address and direction (the direction specified in the DCC speed step message).

 

Trains coming from the fiddle yard might mainly be above a certain speed.

They will also have to traverse the approach(es) to the station.

They will be above a certain speed for a certain time due to the distance from fiddle yard to station.

 

So maybe there is enough information to do what is required:

a) Sniff DCC bus looking for DCC speed steps > than a threshold.

b) Also look for that DCC speed step/address combo to be above that threshold for n seconds.

c) Fit two infra red detectors in a row a set distance apart to each approach road to the station.

d) Use Infra red detectors to: 1) Confirm train is approaching 2) measure speed - if its way off the speed step profile it may not be the correct train - display eg: 1234?.

e) sniff cab bus to determine controller (only needed if  fixed controllers are used for fiddle yard to station moves).

e) use direction data for DCC speed steps that meets the criteria above and display that to the station operators.

 

 

I've got my doubts about the above actually working.  

 

DCC messages to locos under control are repeated regularly by the command station.  Consider two locos run up to a modest speed by human operators.  One leaving the fiddle yard, and one elsewhere on the layout.  The DCC packet messages will show repeats of speed instructions to both regularly.  Both were started at similar times, so can't tell them apart from their history of speed changes.  One loco now passes the IR detectors to indicate it has left the fiddle year.  Which loco went past the detector ?    I don't think you can tell. 

 

 

- Nigel

[davepallant]

NIK's solution with two keypads and two displays was where we started from a year or so ago. Someone started on that but it ran out of steam. I didn't chase it up because it is quite an imposition on a busy layout to type the address in twice, once on the controller and once on the display system. Thats where the idea above sparked me off again.

 

RFID would be a great idea and could be very reliable but we would need at least two detectors coming in and two or three going out so not so cheap. Also when I was looking up the injectable RFID tags the other day on AliExpress they were looking around 1$ each and we would probably need to get a hundred to ensure we had enough to fit to many different people's stock and they might not all want to do it.

 

Its looking like the combination of control bus snuffling and DCC snuffling might give me the information needed. I am lucky that the fiddle yard has two dedicated controllers sending trains toward the station and the station has two dedicated controllers back the other way. That will allow some filtering of trains based on controller number as to source/destination and can rule out the problem of loco direction which has rightly been pointed out to not be reliable. If I am allowed make some simple rules about which controller is used for which movements on the layout I might be able to narrow down the source/destination even further so that I merely end up with a remote display for each controller as to which loco it is controlling. That might give us all we need. Controller 1 is trains entering on the 'electric' line, Controller 2 is trains entering on the 'diesel' line, Controller 5 trains leaving the station for the fiddle yard, Controller 6 locos leaving the platforms for the loco shed. Alternatively a single pushbutton for each controller to confirm sending the snuffled address to the other end will reduce distraction from the addresses of shunting.

 

Thank you everyone.

 

Dave

[Nigelcliffe]

Alternative approach, which is built on some of the ideas in the thread so far: 

 

Packet sniffer, perhaps with control-bus sniffer, to determine trains currently being sent speed packets on layout regardless of where they might be on the layout.

From this, produce an ordered by DCC-number list of locos moving and display the list on a screen in Fiddle Yard. 

On the panel with the display, beside each loco listed is a button.  (Number of buttons required is a few more than the likely max number of locos moving together on entire layout).  

The Fiddle Yard operator pushes the button next to the loco address they are sending out of Fiddle Yard to indicate a train departing from Fiddle Yard.

In response to button press, information system displays information about train departing on larger display: DCC address, direction of travel, current speed, etc..

 

There are ways to put multiple OLED displays onto a single Arduino, so it should be possible to get a reasonable number of loco addresses covered on the Fiddle Yard operator's control panel.

 

 

There are variants of the above which might work, the main idea is that the Fiddle Yard operator needs to actively indicate a loco is departing, and indicate which loco from a list. 

 

 

- Nigel

[garethevans1986]

Mostyn with the DCC Information System will be at Ally Pally at the end of March 2018