DCC and track (train location) circuits

Can you be a little more specific about your requirements ?

Here's a quick outline:

There are lots of block occupancy detection methods for DCC, various makers sell devices which sense occupation through track current (a stationary loco takes a little through the decoder). Can also be done with other methods, such as beam-breaking.

Turnout and signal position sensing is also supported on some accessory decoders (so not relying on decoder to report that it "thinks" it has thrown the turnout, instead get positive signal back from turnout tie bar). Or can just rely on what the decoder has done.

Combine these together and you can build an interlocking system. What you need is a mechanism to relay the signals back to the control system. Digitrax' LocoNet system is one such (don't necessarily need to be using Digitrax throttles/command station), the MERG have their own DIY system, and there are others.

Interlocking could be done with specific hardware boards; CML Electronics (UK based) sell some for LocoNet based systems. Or it can be done on a computer, with either public domain software (eg. JMRI or Rockrail for two) or with commercial products (RailRoad & Co is probably the most common). The computer could be combined with a physical control panel (CML products again).

If you want to get as far as train identification, then its more complex. Can be done with various degrees of buggi-ness using proprietry systems by either Lenz or Digitrax, requiring both compatible DCC chips in locomotives and compatible command stations. Or can be done with dead-reconing memory (RailRoad & Co, JMRI with a fair bit of end-user scripting effort).

I leave you to google the various references here rather than spend my time digging them all out. Hope this helps.

- Nigel

Cheers for that! This is exactly what I was after, I want to detect occupancy that will get feed back to the signalling/point interlocking in a similar way as it is with the prototype - will go a "Googling", any brand names that will give better search results?

Try Dallee electronics.

Just an idea .... Put a decoder under track with one connection to one rail, second to plate or wire in centre of track. Have say a stud under tender or loco that is connected to wheel of other rail. use computer control to continually send request for address. When stud connects under track, decoder replies with address so occupancy detected.

Cheers, Simon

That would mean that every loco, coach and wagon would require such a stud, never mind the fact that the rolling stock could never be turned - not helpful if one is running steam locos... Duh! :~)

I want to detect any rolling stock standing within a track section, or for that matter a failed track (occupancy) circuit, just as on real signalling systems.

Real trains don't have insulated wheels and axles.

I know somebody who has been playing with RFID but I haven't contacted him for a while.

True, but that issue can be worked around.

Cheap enough to epoxy a surface mount resistor (1/8w) on an axle (as many as you want) and connect it to the rims with conductive paint. Somewhere about 22k would do the trick.

Steve Magee Newcastle NSW Aust

No matter which "current" type detector is in use it does demand that at least all of the wheel treads are metallic . The detectors which I have made all function for a loco at about 65 ohms through to test units at 16Kohm but very few items of rolling stock have metal or metalised wheels.

Regards

Try

. This is a not for profit group using electronics in Model Railways. The £13 year membership (plus small joining fee) is very good value for money.

There are plenty of kits available at very reasonable prices. There are some extremely knowledgeable guys there who have been there, done it and produced the Technical Bulletin and kit!

They've even done RFID.

There's also a Yahoo group available to members, to discuss all matters.

They're a very friendly bunch - give it a try.

Richard

Decide whether you want a commercial product or DIY electronics from MERG.

If going commercial, are you heavily invested in your existing DCC command station ? If so, start with that manufacturer and see what they offer (you may end up selling up!). Beware of "vapourware" announcements of products; check the user forums of the various makers to get a feel for which makers have announced products which could do occupancy related stuff several years ago and not actually released them.

I know my way round Digitrax/Loconet stuff (because its well supported in JMRI, been around a while, and has several other makers producing accessories which work with it). Therefore I would tend to steer you to LocoNet, but it can also be done with alternative makers (eg. Lenz and ESU, no doubt others). LocoNet detection solutions usually ends up with either the Digitrax block detector, or those sold by HDL

But there are alternative methods. I would suggest looking at CML Electronics control boards, though they still require external detection input (either current sensing or beam breaking or microswitches).

One approach would be to study control software systems and see what detection methods their users recommend ? Suggest starting with RocRail as a public domain software package designed for automation, though JMRI would be equally valid.

- Nigel

Yes, this might be my best way forward, from what I can tell (from reading the Digitrax site) commercial occupancy modules are designed to give a 0 ve output when the section has no occupancy and a +ve output when occupancy occurs, ideally I would really like it the other way around - this means that should the TC/occupancy module fail the preceding signal will remain at red, IYSWIM.

Before anyone asks, I'm wishing to model the signalling system as closely as one would the rivets on a tender (or the P4 modeller does the track), call me mad if you like, you wouldn't be the first! :~)

One needs to distinguish between different types of detection:

- detect item passing a point.

- detect stock within a block/area.

- ID address. One could multiply those divisions by general vs specific rolling stock items.

Passing a point can be detected by contact, light, magnet, finger ... Stock withing a block can be derived from 'passing a point', having numerous 'passing a point detectors' at closer spacing than the shortest rolling stock, or more reliably by detecting current draw, detecting capacitance, detecting weight ... I must admit I don't understand detecting DCC addresses - unless you also detect position, all you have is confirmation that a loco you already know to be on the layout is still on the layout. Perhaps useful on layouts accessable by the public?

Regards, Greg.P.

In the situation I was describing there could be several decoders at different points on the layout obviously with different addresses but simple electrics. each detection point would only cost the price of a basic decoder. start with a loco or train at a known point, computer controlled as to direction, then its progress can be monitored.

Yes Jerry, it was no use to you in your situation, but then it isnt all about you.

Suspect the basic idea behind detecting DCC addreses is to confirm the set address has been recieved correctly. Its also useful to those of us that are hopeless a keeping records :-)

Cheers, Simon

Or just what a track circuit is! I don't want to count how many trains pass a location, nor the number of axles, nor what loco is passing, I want to know if a track section is occupied - just like the real railway signalling does...

Method 1: Detect current flow across rails. Not much of a problem when loco is moving. If loco is standing still, it's a bit of problem, but even with DCC a loco may stand still yet draw a minimal current. If you program the loco to keep its lights one at all times, that current draw will be enough to use for detection. The Twin-T circuit (invented by Linn Westcott) does this. IIRC, it has been adapted for DCC.

Method 2: Detect entry and exit of trains passing through the control. You need some electrical or electro-mechanical device that changes state when a train passes. Micro-switches, photo-detector circuite, etc, have all been used. The only complication is the number of lights used to signal occupancy: if you use lit/unlit, the logic is obviously simpler than if you use two or more coloured lights. Since a separate power circuit is sued, there are no DCC issues.

The following website summarises methods, and is a good starting point:

Real railways of course use both methods. Central Traffic Control is a version of method 1, and Manual Block of method 2.

Now go and have fun! But be warned: signalling and control can become an obsession, erm, pardon me, a hobby within a hobby. ;-)

=46rom the thread title, I assume you mean DCC decoder? How do you propose to "continually send request for address". If you mean to use transponding or railcom then you are starting to add a lot to the infrastructure cost compared to more traditional track circuiting methods.

If that is what you mean then why not just request the address from the decoder in the loco?

MBQ

From the thread title, I assume you mean DCC decoder? How do you propose to "continually send request for address". If you mean to use transponding or railcom then you are starting to add a lot to the infrastructure cost compared to more traditional track circuiting methods.

If that is what you mean then why not just request the address from the decoder in the loco?

MBQ

Use a computer to "continually send request for address". But the idea would be given a known position of a loco at starting then be able to track its progress round a known track plan. The id of the loco would be known as it would also be under DCC control via the computer. The only problems I can see is may need two DCC controllers, one for track and the other for locos. Also need to determine the time interval between sends of request for address and length of isolated section in order for the request to be received and replied to.

cheers, Simon

Yes Jerry, as I said, not everything is about you, theres a special name for it on USENET - am sure you can correct me but its something like thread-nap - where a thread is stolen for a slightly differnt but related topic.

I'd apologise but its not a crime.

Cheers, Simon