DCC and track (train location) circuits
Jerry
such TCs for signal/point interlocking purposes?
Nigel Cliffe
> Any pointers to web sites for such info, is it even possible to have
> such TCs for signal/point interlocking purposes?
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
--
Nigel Cliffe,
Webmaster at http://www.2mm.org.uk/
Jerry
"Nigel Cliffe" <m...@privacy.net> wrote in message
news:g7sjn4$jv8$1...@news.albasani.net...
> Jerry wrote:
>> Any pointers to web sites for such info, is it even possible to
>> have
>> such TCs for signal/point interlocking purposes?
>
> 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).
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?
Christopher A. Lee
wrote:
Try Dallee electronics.
simon
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
Jerry
"simon" <nos...@nospam.com> wrote in message
news:Tqudnb1enI_GZzzV...@bt.com...
>
<snip>
>
> 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.
>
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.
Christopher A. Lee
wrote:
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.
Jerry
"Christopher A. Lee" <ca...@optonline.net> wrote in message
news:p814a4h7dhgipg3uh...@4ax.com...
> On Tue, 12 Aug 2008 22:39:50 +0100, "Jerry"
> <INV...@INVALID.INVALID>
> wrote:
>
>>
>>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.
True, but that issue can be worked around.
Steve
> On Tue, 12 Aug 2008 22:39:50 +0100, "Jerry" <INVA...@INVALID.INVALID>
> wrote:
>
>
>
>
>
>
>
> >"simon" <nos...@nospam.com> wrote in message
> >news:Tqudnb1enI_GZzzV...@bt.com...
>
>
> Real trains don't have insulated wheels and axles.
>
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
> I know somebody who has been playing with RFID but I haven't contacted
> him for a while.- Hide quoted text -
>
> - Show quoted text -
Sailor
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
Dickie mint
> Any pointers to web sites for such info, is it even possible to have
> such TCs for signal/point interlocking purposes?
>
>
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
Nigel Cliffe
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 (http://users.pandora.be/deloof/). 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.
Jerry
"Dickie mint" <richard_ta...@trapyahoo.co.uk> wrote in message
news:6gfnfqF...@mid.individual.net...
<snip>
> Try http://www.Merg.org.uk . 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!
>
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! :~)
Greg.Procter
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.
simon
"Greg.Procter" <pro...@ihug.co.nz> wrote in message
news:op.uga9aybkt7a1n0@promodel-5a9821...
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
Jerry
>> One needs to distinguish between different types of detection:
<snip utter clap-trap>
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...
--
Wikipedia: the Internet equivalent of
Hyde Park and 'speakers corner'...
Wolf Kirchmeir
> "simon" <nos...@nospam.com> wrote in message
> news:XJydnexeROisqy7V...@bt.com...
>> "Greg.Procter" <pro...@ihug.co.nz> wrote in message
> <snip>
>
>>> One needs to distinguish between different types of detection:
> <snip utter clap-trap>
>
> 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:
http://homepages.paradise.net.nz/~rdmurg/clinic/detectit.htm
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. ;-)
--
wolf k.
manat...@hotmail.com
>
> 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
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
simon
<manat...@hotmail.com> wrote in message
news:86d01879-040f-4c82...@p31g2000prf.googlegroups.com...
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
simon
"Jerry" <INV...@INVALID.INVALID> wrote in message
news:g90k07$hpa$2...@registered.motzarella.org...
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
Jerry
>
<snip>
>>
> Yes Jerry, as I said, not everything is about you, theres a special
Yes, you're thinking of thread drift - I suppose I should just be
thankful that a couple of people understood the meaning of the phrase
"Track circuit" (as applied to railway use) and have answered the
original question...
simon
"Jerry" <INV...@INVALID.INVALID> wrote in message
on the topic.
cheers,
Simon
Wolf Kirchmeir
[...]
> 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.
AIUI, OP is just wondering if DCC, with its AC at a constant 20V on the
track, would cause a problem with occupancy detector circuits. Answer
(as with all things electronic) is "It depends."
HTH
--
wolf k.
Nigel Cliffe
> <manat...@hotmail.com> wrote in message
> news:86d01879-040f-4c82...@p31g2000prf.googlegroups.com...
>
> > 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?
> 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.
Unless I've missed something, the above is well known DCC occupancy
detection.
Example which I know works:
Digitrax block detector (16 blocks per board), feedback from the detector
wired to computer via LocoNet and suitable Loconet-computer adaptor. Would
work easily with a Digitrax DCC command station, and I think it would be OK
with other makers DCC command stations (though would need second computer
interface from "other maker" command station to the computer, this is fine,
it just means buying two interface boxes).
Software to run it would be one of PanelPro (part of the free JMRI tools),
RocRail (free) or RailRoad & Co (commercial). And possibly others.
I'm confident it would work with other makers block detection and feedback
systems.
manat...@hotmail.com
> <manatba...@hotmail.com> wrote in message
Like I asked, how do you propose to do that for the decoder connected
to the track? Are you proposing digitrax decoders with transponding or
Lenz et-al with Rialcom? Either way it's a totally OTT suggestion when
you might just as well fit such decoders in the locos.
MBQ
manat...@hotmail.com
> Any pointers to web sites for such info, is it even possible to have
> such TCs for signal/point interlocking purposes?
DCC is "always on" so you always have something to work with. Even a
stationary loco will draw some current that can be detected, if it's
not enough then the old trick of a resistor connected across the
pickups will do. Ideally you want galvanic isolation between the
traction power and your track circuiting logic. Since DCC is (barring
pedantry from some) AC, a current transformer is ideal for this
purpose.
MERG have at least one circuit and kit of parts.
MBQ
simon
to that stage.
Hopefully will be able to use own software, may be an interesting bit to add
on.
Cheers,
Simon
simon
<manat...@hotmail.com> wrote in message
news:0d971106-5d72-40ed...@j22g2000hsf.googlegroups.com...
Like I asked, how do you propose to do that for the decoder connected
to the track? Are you proposing digitrax decoders with transponding or
Lenz et-al with Rialcom? Either way it's a totally OTT suggestion when
you might just as well fit such decoders in the locos.
MBQ
from your reply it would seem I didnt explain the idea very well. But not to
worry, got all the info I need now.
Thanks,
Simon
Jerry
>
<snip>
> Thanks for that- tis useful, will look into whats available when get
> round to that stage.
> Hopefully will be able to use own software, may be an interesting
> bit to add on.
>
Would I be right in assuming that the above (most snipped) is in
effect "Loco/Train reporting", rather than just indication that
something is causing section occupancy, if so I can see a use for it
as a means of allocating - from a time table held in computer
software - a train reporting number (aka Head Code) to the motive
power used to pull the train and feeding this to track diagrams etc.
Or have I got completely the wrong grasp on this?!
Nigel Cliffe
As what I wrote was snipped :-)
The basic occupancy detection with Loconet bits and pieces (or equivalents
from other makers) reports that something is on that block section. The
detection itself could be current draw (DCC chip, even on idle, resistor
over wagon wheel, etc), or could be optical or magnetic switch. That far
can drive a simple block diagram which can indicate occupation or clear on
sections. The diagram could be on a computer or a stand alone "traditional"
display panel (eg. CML Electronics do a Loconet board for this purpose).
Combined with signalling and turnout control, this could give a prototypical
interlocking signalbox, and drivers of trains would be "commiting offences"
by deciding to drive past signals at red (just like a real railway before
any form of automatic train control).
I think its possible to introduce "automatic train protection" where a
signal passed at red causes an instruction to be sent to shunt down the
train on the section in question (essentially an "all trains in section
stop" instruction).
If the computer monitors turnout settings, which trains are driven, which
blocks are occupied and released, it can (if detection locations are well
designed) work out where trains have moved to. This can then display train
numbers (etc) on a track diagram, or operate a layout to a timetable. But,
as the system involves dead-reconing, a weak design could get things wrong.
Railroad & Co (commercial software) does this job, and its ability to do it
well is one of the makers main claims as to why their software is superior
to alternatives.
The more advanced forms of train reporting require transponding where
information comes back from the locomotive to the control system.
Digitrax do their own system which requires their block detectors and their
chips in locos (they sell a transponder chip which can sit alongside another
maker's loco control chip). The Digitrax system has been around a while and
has mixed views (even on the Digitrax owners forums) as to how well it
really works. Digitrax themselves have said that transponding has been a
technology seeking a practical use, and that application might be the new
track-side surround sound system from SoundTraxx (source: AJ the owner of
Digitrax at a recent conference, video available on the web).
Lenz have a different system (Railcom), but to date there isn't much you can
actually do with Railcom (lots of promise and neat ideas but few actual
products).
Ian Jackson
simon <nos...@nospam.com> wrote:
>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.
In my system I don't bother with any loco-to-computer transmissions.
The computer knows where all the trains are and can detect their
presence as they enter new blocks. It can therefore compute which
train must be occupying a particular block: it's the one from the
adjacent block which it just told to move in that direction.
--
Ian Jackson personal email: <ijac...@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Ian Jackson
Wolf Kirchmeir <ElLob...@ruddy.moss> wrote:
>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.
My current flow based track circuit detection has no problem detecting
an idle DCC decoder. It's a circuit of my own design, so I can't say
whether all of the commercial offerings manage the same feat, but it's
certainly possible. I would say that if you adopt a reasonably modern
digitally-based approach it's not even difficult.
>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.
>http://homepages.paradise.net.nz/~rdmurg/clinic/detectit.htm
The transistor- and relay-based circuit shown there probably won't
spot a DCC decoder with all of its outputs turned off.
I use the four diodes and optocoupler trick. It's very sensitive and
gets the cost and component count per block right down. I rely on
firmware in my microcontrollers to debounce with the `present-absent'
oscillation caused by the fact that the circuit only detects on one
half of the DCC waveform.
beamendsltd
Ian Jackson <ijac...@chiark.greenend.org.uk> wrote:
> In article <OsqdnaVNYPB76inV...@bt.com>,
> simon <nos...@nospam.com> wrote:
> >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.
>
> In my system I don't bother with any loco-to-computer transmissions.
>
> The computer knows where all the trains are and can detect their
> presence as they enter new blocks. It can therefore compute which
> train must be occupying a particular block: it's the one from the
> adjacent block which it just told to move in that direction.
>
Just like the real thing! Very prototypical ;-)
Cheers
Richard
--
www.beamends-lrspares.co.uk sa...@beamends-lrspares.co.uk
I have become... comfortably numb
manat...@hotmail.com
wrote:
> In article <OsqdnaVNYPB76inVnZ2dnUVZ8j2dn...@bt.com>,
>
> simon <nos...@nospam.com> wrote:
> >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.
>
> In my system I don't bother with any loco-to-computer transmissions.
>
> The computer knows where all the trains are and can detect their
> presence as they enter new blocks. It can therefore compute which
> train must be occupying a particular block: it's the one from the
> adjacent block which it just told to move in that direction.
How do you cope with the hand of god moving a train when the layout is
turned off? How do you introduce a new train to the system?
MBQ
simon
<manat...@hotmail.com> wrote in message
news:0dec9c4e-aac3-419e...@x35g2000hsb.googlegroups.com...
MBQ
If hand of god tries to move locos then he gets knuckles wrapped. Time
stands still when the layout off - its as though the universe doesnt exist.
You keep sending decoder address requests ...... :-)
Theres also the problem of what happens when the layout is created.
Cheers,
Simon
Ian Jackson
manat...@hotmail.com <manat...@hotmail.com> wrote:
>On Aug 28, 11:52=A0am, Ian Jackson <ijack...@chiark.greenend.org.uk>
>wrote:
>> The computer knows where all the trains are and can detect their
>> train must be occupying a particular block: it's the one from the
>> adjacent block which it just told to move in that direction.
>
>How do you cope with the hand of god moving a train when the layout is
>turned off? How do you introduce a new train to the system?
If the hand of god moves a train, the train must be placed in its
designated start spot. And if there's another train already there it
will also have to be moved by the hand of god, etc.
This turns out to be less annoying than one might expect. If it gets
too bad I might provide a function on the computer screen to specify
where some train is, or to allow the computer to know more accurately
the exact length of a goods train, the but I haven't found it
necessary yet.
The system knows about all the trains that might be on the layout and
I have to update the computer configuration to introduce a new train.
But that's really trivial compared to the effort of selecting and
purchasing it, fitting the decoder, etc.