DCC Concepts Cobalt IP Digital & LocoNet

[Dungrange]

Apologies if this is a simple question, but is it possible to get the Cobalt IP Digital point motors to report their status over LocoNet?  I can't see anything in the information on DCC Concepts website, but then I don't know too much about LocoNet.  Looking at the connections, I suspect not.

 

I'm aware that a Digitrax accessory decoder such as the DS64 has LocoNet control and feedback, but the DCC Concepts site suggests that this is not recommended for use with the Cobalt IP motors and their own accessory decoders, which they do recommend (ie the AD-2fx and AD-8fx) don't mention LocoNet, although the user manuals state that there is a 5v output for Computer IO or feedback.  It can apparently be high or low depending on which of the contacts it is used with.

 

I suspect this will just be the first of a number of queries about LocoNet.

 

 

 

 

[newbryford]

Apologies if this is a simple question, but is it possible to get the Cobalt IP Digital point motors to report their status over LocoNet?  I can't see anything in the information on DCC Concepts website, but then I don't know too much about LocoNet.  Looking at the connections, I suspect not.

 

I'm aware that a Digitrax accessory decoder such as the DS64 has LocoNet control and feedback, but the DCC Concepts site suggests that this is not recommended for use with the Cobalt IP motors and their own accessory decoders, which they do recommend (ie the AD-2fx and AD-8fx) don't mention LocoNet, although the user manuals state that there is a 5v output for Computer IO or feedback.  It can apparently be high or low depending on which of the contacts it is used with.

 

I suspect this will just be the first of a number of queries about LocoNet.

 

The Cobalt Digital IP does not communicate back via anything other than a switch. (Either I/O level or a SPDT switch on the S2 contacts)

This switch can be wired into a suitable Loconet feedback module.

 

The DS64 is an analog output device and does not have the current capability to drive an Analog IP - hence the recommendation not to use them.

 

The Analog IP takes a larger run current than the Omega, but has a much lower static current than the Omega.

However - I think the DS64 will drive a Cobalt Omega (One would need to check the DS64 output spec) 

 

The AD-FX series will happily drive an Analog IP or an Omega and feedback from either can be from the I/O output or the SPDT switches on the Cobalt motor.

 

Cheers,

Mick

[fcwilt]

Hi,

 

I've never been a fan of using DCC for controlling turnouts, signals and such.

 

LocoNet (and the like) were designed for control and sensing and represent a much better approach.

 

There are simple, economical devices like RR-CirKits MotorMan which handle turnout control via LocoNet.

 

Highly recommended.

 

Frederick

[WIMorrison]

The cobalt io Digital are excellent motors and the built in SPDT switch is great for switching the frog polarity. I also recommend that you create a separate track and accessory bus by putting the track current through a circuit breaker of which there are many.

 

They do have an output that you could use but I think it will be at your DCC input voltage and you would need to limit it down to 5v which I think is the input that the feedbacks use.

 

You could look at the Digikeijs kit for more cost effective solutions for the feedback compared to Digitrax

[Nigelcliffe]

Apologies if this is a simple question, but is it possible to get the Cobalt IP Digital point motors to report their status over LocoNet?  I can't see anything in the information on DCC Concepts website, but then I don't know too much about LocoNet.  Looking at the connections, I suspect not.

 

 

Possible yes, with additional hardware to encode the binary switches on the Cobalt decoder to a loconet input device.   Commercially look at Digikeijs and RR Circuits for input devices, or DIY look up "locoIO" which can be built from kits or DIY'd quite cheaply from an Arduino processor.   Also, on loconet, look at Signatrak's range which they inherited from CML electronics. 

 

Is it necessary ?  That is more questionable, depends why you need the report of status of the Cobalt.   If you are using the local input buttons on the Cobalt to operate the turnouts, and are also using a central panel (software or hardware) or computer software to monitor/run things, then the operation via local buttons needs to be reported.   But, for other uses, it really depends if you really really need to know the motor has moved, or if you just trust your system to actually move a turnout. 

BUT, there is a different way to deal with local control buttons - don't use the inputs on the Cobalt for local buttons, instead use a LocoNet local button input device.   Then, your buttons will be known at the centre, and their commands included in the current state of the world.   

 

 

If really going "LocoNet", then there is some sense in taking accessory devices away from DCC, and putting them on LocoNet. Thus, accessory control is via an output device which receives instructions via LocoNet (eg. CML DAC20, and many other makers offer something).  Those devices will need power (so a power bus might be needed to operate accessories).    The DCC bus is only used to operate the rails and loco decoders.  

 

 

- Nigel

[Dungrange]

The Cobalt Digital IP does not communicate back via anything other than a switch. (Either I/O level or a SPDT switch on the S2 contacts)

This switch can be wired into a suitable Loconet feedback module.

 

They do have an output that you could use but I think it will be at your DCC input voltage and you would need to limit it down to 5v which I think is the input that the feedbacks use.

 

You could look at the Digikeijs kit for more cost effective solutions for the feedback compared to Digitrax

 

Mick / Iain

When you refer to a suitable LocoNet Feedback module, is that the same as the modules that are used for block occupancy detection?  I've been looking at the Digikeijs DR4088 and 5088 modules as a cheaper alternative to the Digitrax BDL168. 

 

Is what you are saying, I could use the switch on the Cobalt iP Digital and when that is turned on (ie the points are thrown), then this would pass a current through one of the inputs on a DR4088 such that if the point is thrown, it would be reported as though a track section were occupied?

[Dungrange]

Possible yes, with additional hardware to encode the binary switches on the Cobalt decoder to a loconet input device.   Commercially look at Digikeijs and RR Circuits for input devices, or DIY look up "locoIO" which can be built from kits or DIY'd quite cheaply from an Arduino processor.   Also, on loconet, look at Signatrak's range which they inherited from CML electronics. 

 

Is it necessary ?  That is more questionable, depends why you need the report of status of the Cobalt.   If you are using the local input buttons on the Cobalt to operate the turnouts, and are also using a central panel (software or hardware) or computer software to monitor/run things, then the operation via local buttons needs to be reported.   But, for other uses, it really depends if you really really need to know the motor has moved, or if you just trust your system to actually move a turnout. 

BUT, there is a different way to deal with local control buttons - don't use the inputs on the Cobalt for local buttons, instead use a LocoNet local button input device.   Then, your buttons will be known at the centre, and their commands included in the current state of the world.   

 

 

If really going "LocoNet", then there is some sense in taking accessory devices away from DCC, and putting them on LocoNet. Thus, accessory control is via an output device which receives instructions via LocoNet (eg. CML DAC20, and many other makers offer something).  Those devices will need power (so a power bus might be needed to operate accessories).    The DCC bus is only used to operate the rails and loco decoders.  

 

 

- Nigel

 

Nigel,

 

Is it necessary: I don't know.  I ask because I've been looking at the Signatrak (formerly CML) SIGM20 Signal controller, which is LocoNet enabled, but I'm not sure whether I actually need LocoNet to use it.  My DCC Command Station is the Signatrak ACE-2, which is not (yet) LocoNet capable.  I chose the ACE-2 because it has a simple interface, which I like and it seemed like a good starter set to learn the basics.

 

However, reading the board set up instructions for the SIGM20 User Manual there are two options which appear to state that a LocoNet Command Station is not required.  These are:

1. Use LocoNet SWRQ - When ticked, the SIGM20 ignores DCC commands and takes point commands from LocoNet instead.  Useful on "private" LocoNets with no command station; and
2. Report Signal States after power on - If clicked, the board ALWAYS reports signal states to LocoNet, even if it hasn't yet been asked to do so.  This option can be used on non-Digitax systems to allow normal operation in the absence of a Digital Command Station.

However, if a LocoNet Command Station is not required - what is LocoNet used for (in relation to the SIGM20)?  That seems to be:

1. To report the signal states to other SIGM20 boards;
2. Receive Block occupancy detection messages from a Digitrax BDL168 (or alternatively from the Digikeijs DR4088/5088 - I think / hope); and
3. possibly to receive details of the status of the points

The SIGM20 board does have it's own Sensor Input Connector, which the user manual states is provided to allow up to 8 track sensors.  The examples given are how to connect an IRDOT, BD4 sensors or a pushbutton or toggle switch to force a signal to red from a local panel.  If I could connect the output switch on the Cobalt iP Digital to the Sensor Input Connector on the SIGM20, then there may be no need for the points to convey their status over LocoNet as it would feed directly into the signal interlock, but if that won't (or doesn't) work,then I'd like to know what the fall back position would be - hence my question.

 

I'm a long way off actually purchasing any of this 'kit', but I have a lot to learn in the meantime.

[WIMorrison]

I think that if you take the frog output on the Cobalt IP and pass it through resistor and a pair or back to back diodes with a LED in series with the diode you could then put that input into a 4088/5088 and it will show as the ‘track being occupied’ depending on the way the point has operated.

 

I am not 100% certain this will work and will try it some time this week when I find some diodes

 

In theory should work

[Nigelcliffe]

David,

 

LocoNet's exist in two forms:  those with a command station (classically Digitrax, but there are many others now possible) and those without.  The "without" is know as a "Stand Alone LocoNet".  Typically this is achieved by putting DC power into a LocoBuffer (puts some power on the LocoNet wires), and using the LocoBuffer to send commands back-and-forth to a computer, but it would be possible to do similar without the computer and just use the CML boards.   That said, you're going to need a computer to configure the CML boards, so will end up needing a LocoBuffer (or Digitrax PR3/PR4) anyway, so will probably need the LocoBuffer (or PR3/4) configured as "stand alone" to get anything to work.   

(My use suggests that the CML DTM30 needs the RailSync signal from a command station to be present to function, so I don't think that board is easy to use in a stand-alone setup - so you may be needing the RailCom upgrade to the ACE to get everything to work ).

 

 

I think it all comes back to "what are you trying to achieve" ?  And combined with that, is "are there any constraints on the plans ?"    So, whilst the Sig20 is a decent bit of electronics, I'd suggest you can do the same signalling logic control (and a lot more besides) with a Raspberry PI running JMRI software.  However, the PI would still need an output device to run the signals (can be done a lot cheaper than a SIG20, but if wanting off-the-shelf model railway electronics, then it may not be massively cheaper).   And, in addition, there are about 30 input pins on the Raspberry PI which could be used for input sensors from the layout, without any additional hardware. 

 

Back at the SIG20, yes, you could use the inputs on that to connect to the switches on the Cobalt, and that provides sensor input.  You could use sensors as proxies for turnout position in the SIG20 (ie. it only listens to the turnout position feedback from the cobalts as sensor messages - its a slight bodge as you really want to be listening to "confirmed turnout has moved" messages, but that needs a computer to integrate the initial turnout message with the sensor feedback).    

 

 

A lot of this is going to come down to "what are your real aims here", as there are an awful lot of possible ways to do things, some will be more sensible than others in cost, complexity and flexibility.   I see you are Lothians and Edinburgh - if you fancy a longer chat about it all, I'm about 40 miles south in the borders, or sometimes I get up to the Scalefour group meetings in the Edinburgh area.

[Dungrange]

Nigel,

 

Thanks for taking the time to explain the basic forms of LocoNet. 

 

At the moment, my only constraints are my knowledge, skills and time available, or lack of all three.  My DCC set up is literally just two wires to the track.  The Signatrak ACE2, two wires, a yard of track and a Realtrack DCC Sound fitted Class 156, so that I can have a play with changing CVs.  Apart from that, I pretty much have a 'blank canvas'.  The proposed layout is, at the moment, a plan, a couple of part-built baseboards, a box of C&L track components, track gauges and various lengths of wire, all rated at more than 6A and therefore capable of handling the current output from the ACE2 or any other DCC command station.  I think my proposed bus wire was rated at something more like 20A.

 

At the moment, my main concern is where to place insulated fishplates and power feeds for the (future) track circuits; type of point motor; and frog switching arrangement.

 

Ultimately, I'd like a 'traditional' panel with physical switches and a series of LEDs to display the status of the layout.  A line of white LEDs indicates that a route is set.  Red LEDs indicate which sections of track are occupied and the panel indicates the status of the colour light signals.  I also want these signals to be driven automatically.  That is, they will display a red aspect when a point is set against them or the track ahead is occupied and that the aspect will change from green or amber to red when the signal is passed (as I'll forget if I have to do it manually).  I think I'd rather do that via track circuits than using infrared detectors. 

 

I've looked at the Signatrak DTM30 to control the proposed panel, although I agree with you that I don't think that would work with regards controlling points and routes without a LocoNet command station, as I think the input switch to a point cell on the DTM30 generates a LocoNet command that is sent to the command station, which in turn converts that into a command on the DCC Accessory Bus to actually change the point.  I'm not sure whether the status display on the DTM30 from the point cell is simply controlled by the input switch (ie it indicates that the command has been issued), or whether there is feedback from the point motor to the panel to indicate that it has actually changed.  I suspect that it is the latter, but assume that the feedback path must be via the DCC Accessory Bus to the command station and then via LocoNet to the DTM30.  That means that it wouldn't work with my ACE2.  However, I'd be perfectly happy to simply connect a switch to the point motor and feed the indicator panel from the output switches on the point motor to overcome the lack of a LocoNet enabled command station.  I'm not looking for computer control.

 

Regarding signal interlocking, I'm aware that I could do what I want electrically, using a series of relays and I could also have an electronic solution using a series of logic Integrated Circuits with AND and OR gates, but I'm not sure that my electrical / electronics knowledge is sufficiently good to allow me to design and test such circuits.  I'll have a look at the Raspberry Pi idea, although again, I'm not sure about the level of programming that may be required, which is why I'd probably prefer an 'off the shelf' or 'plug and play' solution and the set-up instructions for the SIGM20 look fairly straightforward - that is, I think I can follow how to programme the logic, and if it doesn't work, I think I should be able to identify the problem and reprogramme the board.  I've seen a few essentially similar boards from other manufacturers, but the manuals seem slightly less easy to follow. 

 

I'm not sure that I have actually decided what I ultimately want to achieve, but I want to try and avoid buying things that ultimately don't work together in the way that I think they do. I am therefore simply at the information gathering stage.

 

Unfortunately, none of Edinburgh and Lothian's club layouts uses DCC, which is still very much a minority interest in the club, although that may be changing, as, like me, there are a few members who have bought a DCC controller fairly recently to experiment with.  There are however a couple of members who are keen on DCC, albeit we rarely attend on the same evenings.

Edited May 6, 2018 by Dungrange

[Nigelcliffe]

David

 

 

I'm not sure whether the status display on the DTM30 from the point cell is simply controlled by the input switch (ie it indicates that the command has been issued), or whether there is feedback from the point motor to the panel to indicate that it has actually changed.  I suspect that it is the latter, but assume that the feedback path must be via the DCC Accessory Bus to the command station and then via LocoNet to the DTM30. 

 

 

Not quite.  The Point Cell has optional feedback from the layout.  So, it can either just change the LED indicator(s) when the command is actioned at the command station, or it can wait for a confirmation message back from the actual turnout (eg. microswitches attached to blade movement).   That feedback comes via the LocoNet system (so needs a LocoNet input device near the turnout to take the switch input onto LocoNet).   DCC bus signals are one-way (from the command station to the device), there is no return message path (unless you have a RailCom capable system). 

 

 

 

Raspberry PI method for signal logic control - use JMRI, which is free public domain software.  There is a build for a Raspberry PI which is "operating system and JMRI on a single download".  That's put onto a SD card, into the PI, and turn it on.  
Quite a few years ago, I wrote a sequence of tutorials ("clinics" in JMRI terms) on UK signalling and UK signal interlocking.  The basics are still accurate, though the software in JMRI has improved considerably over the years, so a lot of the faffy setup of "devices" followed by "heads" and eventually "masts" can now be skipped and everything set directly from a "signal mast".    I'd suggest that its simpler to do in JMRI than it is to set the rules in the SIG20.   

Whether the PI has a screen or not when in use on the layout, or whether you use a physical panel of LEDs/lamps, etc.., is a detailed decision, which can be taken later.   But, using a screen during the design/testing phase allows things to be changed very quickly.   

 

 

 

- Nigel

[WIMorrison]

​the one thing that I would say is that anyone joining the hobby now and building a new layout should go with DCC, it doesn't make sense not to. The reason most people remain with DC is the investment that they have - made - both financially and in time - with the DC layouts that they have already and the cost with associated steep learning curve required to go DCC and get the same effects that may have achieved with the DC systems  over many years is sufficient to stop them dead, and then often be very negative about DCC.

 

You are starting afresh and therefore should plan for eventual full automation - that doesn't mean you do it now, but a little planning will make it possible - and easy - should you decide to later. You are asking the right questions and I admire you for taking on the challenge, I can assure you that when you get to a stage with full automations, all points switching automatically, signals all showing the right colours and locos stopping beside the signals and only going when permitted you realise why you did it. Seeing half a dozen trains all running automatically is wonderful - especially with a cuppa in the hand

 

Feel free to keep asking, that is the only way you learn! 

[Dungrange]

Raspberry PI method for signal logic control - use JMRI, which is free public domain software.  There is a build for a Raspberry PI which is "operating system and JMRI on a single download".  That's put onto a SD card, into the PI, and turn it on.  

Quite a few years ago, I wrote a sequence of tutorials ("clinics" in JMRI terms) on UK signalling and UK signal interlocking.  The basics are still accurate, though the software in JMRI has improved considerably over the years, so a lot of the faffy setup of "devices" followed by "heads" and eventually "masts" can now be skipped and everything set directly from a "signal mast".    I'd suggest that its simpler to do in JMRI than it is to set the rules in the SIG20.   

Whether the PI has a screen or not when in use on the layout, or whether you use a physical panel of LEDs/lamps, etc.., is a detailed decision, which can be taken later.   But, using a screen during the design/testing phase allows things to be changed very quickly.   

 

Nigel - I found your 'clinic' from 2011 and the worked example doesn't look too dissimilar from what I am trying to achieve.  If the setup has got easier, then it's an option worth looking at, as I have a couple of concerns with the SIGM20: I'm not yet sold on it as the ultimate solution.

 

I'm only looking to control five signal posts, so on first glance a single SIGM20 is more than adequate.  However, because there are only two routes from what the SIGM20 calls a diverging signal, and I have three routes (ie two turnouts one after the other), I think I need a 'Virtual Signal'  at the second turnout.  Then as I want to have more than one track circuit in the platforms, I think I will require two more 'Virtual Signals' because each SIGM20 'Block' can only refer to a maximum of three track circuits.  However, although these signals don't physically exist, I think they use up cells on the board - ie reduce the number of physical signals that can be controlled.  Then, the SIGM20 instructions don't specifically mention Position Light Signals.  Three of my five signals will need a Position Light Signal for Permissive Block working.  I'm assuming that these could be set up as two aspect signals (even although they are not Red/Green), but again this increases the signal count and finally, my inner home signal should have a Theatre Box indicator, which would display the number of the platform that the route is set for.  There is nothing in the SIGM20 User Manual, that indicates the SIGM20 could control this.

 

Therefore, would it be easier to set up Position Light Signals and Theatre Box indicators in JMRI?  Your 'Clinic' highlighted Permissive Block (which is good) and suggested a separate Logix module would be required to control route indicator 'feathers', so I assume that the same approach could be adopted for a Theatre Box.

 

Finally, what does the Raspberry Pi replace in terms of other equipment?  I assume that I would still need a LocoBuffer-USB, which I would connect to a Digikeijs DR4088 (or similar for block occupancy detection).  Would the Raspberry Pi replace both a SIGM20 (ie provide the signal logic) and a DTM30 (ie be able to drive a mimic panel), or am I just replacing the SIGM20 with something called a LocoIO?  I've noticed that there are several different Raspberry Pi models - should I be looking for any particular specification?

[Dungrange]

Nigel,

 

Having taken the time to read through your tutorial on the JMRI website and watch all of the accompanying YouTube videos, I agree that this looks reasonably easy to set up.  However, I have a couple of questions.

 

The tutorial contains a number of 'Panel Files' and states that "If you wish to use these and do not have a Digitrax/LocoNet system, then we recommend you set your JMRI preferences to "Digitrax - LocoNet Simulation", which will allow the files to work correctly without connection to external layout hardware".  Does this mean that I can download JMRI onto a Windows laptop and set up a working Signal Setup in advance of actually building the layout?  That is, I can in effect set up my logic now to check that JMRI can actually do what I want before I commit to the hardware?  I assume that this will have an output file that can be exported to another operating platform such as a Raspberry Pi at a later date, as long as it has a compatible version of Java - is that correct?  Finally, the current production version of JMRI seems to be 4.10, but would I be correct in assuming that files will be forward compatible?  That is, if I create a layout plan in JMRI version 4.10, I should be able to update to 4.11.5 and other future versions as they become available, without having to recreate the layout plan and logic with each update?

[Nigelcliffe]

David,

 

yes, you can do the entire layout in JMRI in "simulation".   You create sensor devices, but have to change them manually to represent train movements.  This can be with the sensor table, or put them on a panel in a convenient place to change them.   With that you should be able to test whether you can create all the signal logic you require without massive hassle.   

I'd suggest you work up little sub-sections of the signalling until you start to get a feel for things, and be ready to chuck away stuff which isn't working correctly and start again (part of a learning process). 

 

JMRI for this application should be OK across production releases, though I'd suggest you avoid being more than two versions behind the current production version.  Once the layout is built and working, then you can, if you wish, just "forget it", as its doing its job and won't need updating.   JMRI production releases are every six months (July and December), test releases occur in between.  Even point-numbers are production releases, thus 4.8, 4.10, and this July expect 4.12.    

 

I was going to suggest this course of action after reading your earlier message of the two above.  And then answer the detailed questions therein.  But a full answer will take time to think about and type out - perhaps tomorrow or Weds. 

 

 

The panel file created in JMRI is the same file used regardless of hardware platform.  Thus, one can copy the panel file from Windows to Mac to Linux (Raspberry PI runs Linux).  If done really carefully, a panel built in simulation works without change attached to the real layout, though in practise there are usually minor adjustments to make it work with the layout hardware.   Further comments on PI's later.  

 

 

regards

 

Nigel

[Nigelcliffe]

Nigel - I found your 'clinic' from 2011 and the worked example doesn't look too dissimilar from what I am trying to achieve.  If the setup has got easier, then it's an option worth looking at, as I have a couple of concerns with the SIGM20: I'm not yet sold on it as the ultimate solution.

 

I'm only looking to control five signal posts, so on first glance a single SIGM20 is more than adequate.  However, because there are only two routes from what the SIGM20 calls a diverging signal, and I have three routes (ie two turnouts one after the other), I think I need a 'Virtual Signal'  at the second turnout.  Then as I want to have more than one track circuit in the platforms, I think I will require two more 'Virtual Signals' because each SIGM20 'Block' can only refer to a maximum of three track circuits.  However, although these signals don't physically exist, I think they use up cells on the board - ie reduce the number of physical signals that can be controlled.  Then, the SIGM20 instructions don't specifically mention Position Light Signals.  Three of my five signals will need a Position Light Signal for Permissive Block working.  I'm assuming that these could be set up as two aspect signals (even although they are not Red/Green), but again this increases the signal count and finally, my inner home signal should have a Theatre Box indicator, which would display the number of the platform that the route is set for.  There is nothing in the SIGM20 User Manual, that indicates the SIGM20 could control this.

 

Therefore, would it be easier to set up Position Light Signals and Theatre Box indicators in JMRI?  Your 'Clinic' highlighted Permissive Block (which is good) and suggested a separate Logix module would be required to control route indicator 'feathers', so I assume that the same approach could be adopted for a Theatre Box.

I imagine that JMRI can do what you require. But exactly how it needs to be setup will depend on your detailed track requirements. So that's going to need some work experimenting to get your basics setup (track diagram, various block detectors, stop markers on buffer stops, etc..), and then finding out how difficult to do what you need.

 

It also may depend how your signals are represented in model form - do you have a Theatre Box device already, or one under design somewhere ? Or is this purely a "control panel" thing.

 

Best way might be for you to experiment, and if stuck, post the JMRI panel file for someone to help with.

The official place for JMRI support is the email+web discussion group called "jmriusers": its currently on Yahoo! groups, but the announcement of an intended move to the far less bug-ridden Groups.IO service has been made, so expect it to move within the next few weeks.

 

 

Finally, what does the Raspberry Pi replace in terms of other equipment?  I assume that I would still need a LocoBuffer-USB, which I would connect to a Digikeijs DR4088 (or similar for block occupancy detection).  Would the Raspberry Pi replace both a SIGM20 (ie provide the signal logic) and a DTM30 (ie be able to drive a mimic panel), or am I just replacing the SIGM20 with something called a LocoIO?  I've noticed that there are several different Raspberry Pi models - should I be looking for any particular specification?

This is heading into a "how long is your bit of string" type of answer.

 

 

Basics - start with a Raspberry PI model 3 B+.  That costs about £35.  Its the newest version and highest power.  You'll also need a power supply for it, and a micro-SD card for the operating system and software (JMRI).  Optionally a box to put it inside, but get a box with a fair bit of room if you plan to access the hardware pins.    That is a small cheap computer, and can replace a Windows PC for this application.   To do setup work you need a screen and keyboard - either a HDMI screen (TV often works for this) plus USB keyboard+mouse, or can remote control from another device (Windows laptop or a tablet computer).   

JMRI can be loaded in two ways, either once you have the PI running with "Noobs" (Linux pre-configured for a PI for beginners), then download and install JMRI to it,  or by searching Steve Todd's JMRI build for a PI - that's a single file which is loaded to a blank micro-SD card, containing Linux and JMRI, with a lot of pre-configuration done for you.  The latter is less work.  

And, finally, if running without any screen access on the layout (screen access from somewhere is the simplest!), its a good idea to do something to enable a controlled shutdown rather than just removing the power - removing power does work for most people, but eventually its going to corrupt the SD card.  Two main routes, either a little script in JMRI which can be invoked, or a hardware button on one of the GPIO pins. 

 

 

LocoBuffer - depends, if you've still got any LocoNet devices after all of this and still need a LocoNet to computer interface, then yes.  But, depends where this thread takes you.....

 

 

 

SIGM20 - PI with JMRI is to replace the logic (or a lot of it) in the SIGM20.  

But, you still need a means to get block occupancy information into the PI.   That can come from three main methods: 

• (a) human, the human uses buttons (software/screen buttons) to tell the PI about occupancy state.  This can work well (I know a layout which used this for years to great success), but might not be what you want.
• (b) some other device which talks back to the PI.  Here LocoNet devices might be an option, which will then need the LocoBuffer/PR3/PR4 (you mention the Digikeijs boards as one possible, there are much cheaper DIY LocoNet options using Ardunios).  And there are "something other than LocoNet" devices options as well.
• © using the 30 input (GPIO) pins on the PI.   If you look at a photo of a PI, there is a double row of pins on the board which are known as GPIO.  Those can be connected via a ribbon cable plug, and 30 of them can be used as "sensor" inputs to JMRI running on the PI.   So, if the PI can be placed reasonably near where the track sensors are located, you can use those pins.  Which then just leaves the detail of a sensor.  Lots of options for a sensor, such as IR beam devices (IRDOT), or can be track current sensors such as the NCE BD20 block detector (good value at £12 considering what some companies charge for model rail electronics).   Or DIY options for sensors which will cut the price further.   Option © can also be used for the human method, by using physical switches to indicate a piece of track is occupied. 

And there is the outputs to the Signals themselves, which needs something to drive the signals, such as a DCC accessory decoder.  And, that in turn requires that the (or at least a separate DCC accessory bus only) command station is connected to the Raspberry PI.  And, at the moment, the Signatrak ACE doesn't have support in JMRI - ask Signatrak to do some work on that and it could happen.  Or, you need another command station for the accessories - a Sprog may be the cheapest option.  

 

So, whether its is either cost, or complexity, worthwhile to drive the signals in a different way to the SIGM20 is going to be "depends on.....". 

 

 

 

DTM30 - a bit more string :-)

Could use the DTM30 with the above, but that needs the LocoBuffer, and I think it needs a LocoNet capable command station (my memory says the RailSync signal is required for the DTM30), which means getting another command station (get Signatrak to confirm whether you really need the LocoNet command station with RailSync). 

But, could do pretty much all the DTM30 achieves with the stuff outlined above on the SIGM20. 

The input switches/buttons go to the PI's GPIO inputs.   If the wiring of the layout means the cables are too long or complex, then nothing to stop two PI's being used, networked together, with one running the primary JMRI, the other acting as a secondary device.  

Outputs (ie. LEDs).  Those can go to a low cost DCC accessory decoder, positioned behind the panel.  So, the PI has to talk to the DCC system (as per discussion in SIGM20 above).   There may be a way of using the GPIO pins on the PI for outputs as well as input (no fundamental reason why not, but I've not researched it).   And, if LocoNet is being used, then the output could be a LocoNet based output device, the price of which depends on how much "DIY" you're prepared to undertake.    

OR, alternatively, if you're content with display screens, then either the display, or display plus input, can be on a touch screen computer - a cheap Android tablet being the lowest cost option.  That tablet talks to JMRI running on the PI. 

 

 

 

So, lots of string, try not to get it tied in too many knots !

 

 

 

I think the big issues are:

a - cost effectiveness of alternative means of driving signals compared to SIGM20

b - whether DTM30 will work with your current command station (buying a LocoNet capable command station is minimum of £150 for a Digijkeijs unit - though going for one of those means you might not need the LocoBuffer (this keeps getting more complicated as I type more stuff).   ). 

 

 

 

Hope this helps rather than confuses things further.  

 

 

 

 

[WIMorrison]

Well, nobody can say you don’t provide a full answer Nigel

[Dungrange]

So, lots of string, try not to get it tied in too many knots !

 

(this keeps getting more complicated as I type more stuff). 

 

Hope this helps rather than confuses things further.   

 

 

Nigel,

 

Thanks, I probably need a bit of time to do some research and fully digest your extensive answer.  My hardware 'shopping list' seems to have changed completely, which means I am now back at 'square one', with a whole different set of questions!  However, I think if I have understood what you are saying, I can scrap the Signatrak SIGM20 and DTM30, the Digikeijs DR5088 and the LocoBuffer-USB along with the need for a Stand Alone LocoNet or the need for Signatrak to issue a LocoNet upgrade to the ACE-2. 

 

Instead, I now have one (or possibly two) Raspberry Pi running JMRI and a number of NCE BD20, with the possibility of also needing a SPROG (but I think I may be able to get by without one).

 

It also may depend how your signals are represented in model form - do you have a Theatre Box device already, or one under design somewhere ? Or is this purely a "control panel" thing.

 

I'd like to use the 4mm range of Absolute Aspects signals and ultimately I may have a Working Theatre Box on the layout - see https://www.absoluteaspects.com/gauge-aspect-with-route-indicator-p-373.html.  However, that is very much long term.  Phase one is to build the terminus, station throat and fiddle yard, which means that this signal will be located around the baseboard joint between the scenic section and the fiddle yard and I'm loath to spend £115 on a signal that effectively sits at the end of the fiddle yard and wouldn't technically be part of the scenic area.  For the time being, it is therefore purely a 'control panel thing'.  However, once everything is working, several years from now, I may extend the layout to represent more of the station approach, in which case this would become a real signal.  I'd therefore like to consider it as a real signal that's not yet connected (if possible).

 

SIGM20 - PI with JMRI is to replace the logic (or a lot of it) in the SIGM20.  

But, you still need a means to get block occupancy information into the PI.   That can come from three main methods: 

• (a) human, the human uses buttons (software/screen buttons) to tell the PI about occupancy state.  This can work well (I know a layout which used this for years to great success), but might not be what you want.
• (b) some other device which talks back to the PI.  Here LocoNet devices might be an option, which will then need the LocoBuffer/PR3/PR4 (you mention the Digikeijs boards as one possible, there are much cheaper DIY LocoNet options using Ardunios).  And there are "something other than LocoNet" devices options as well.
• © using the 30 input (GPIO) pins on the PI.   If you look at a photo of a PI, there is a double row of pins on the board which are known as GPIO.  Those can be connected via a ribbon cable plug, and 30 of them can be used as "sensor" inputs to JMRI running on the PI.   So, if the PI can be placed reasonably near where the track sensors are located, you can use those pins.  Which then just leaves the detail of a sensor.  Lots of options for a sensor, such as IR beam devices (IRDOT), or can be track current sensors such as the NCE BD20 block detector (good value at £12 considering what some companies charge for model rail electronics).   Or DIY options for sensors which will cut the price further.   Option © can also be used for the human method, by using physical switches to indicate a piece of track is occupied. 

And there is the outputs to the Signals themselves, which needs something to drive the signals, such as a DCC accessory decoder.  And, that in turn requires that the (or at least a separate DCC accessory bus only) command station is connected to the Raspberry PI.  And, at the moment, the Signatrak ACE doesn't have support in JMRI - ask Signatrak to do some work on that and it could happen.  Or, you need another command station for the accessories - a Sprog may be the cheapest option.  

 

Of these options, I think © is the one that I would be looking at.  I notice that the latest Raspberry Pi models have 40 GPIO pins, although it appears that only 26 of these are usable inputs, the remainder being Ground (8 pins), 3.3V (2 pins), 5V (2 pins) and reserved (2 pins).

 

This is where I return to my original question.  Since the Cobalt iP Digital has a 'feedback' output, which seems to be a logic +5V / GRND depending on the throw the points, I assume that I can connect this directly to a Raspberry Pi GPIO pin?  That is, I will have a single wire from the Cobalt iP Digital motor 1 to GPIO  pin 1, a wire from Cobalt iP Digital motor 2 to GPIO pin 2, etc.

 

Then the output from the NCE BD20 would also appear to be a logic +5V / GRND output depending on whether current is detected in the feed or return wire.  Therefore, I assume that I could connect BD20 block occupancy detector 1 to GPIO pin 5, etc.

 

Finally, it seems that the GPIO pins can be configured as either input or output pins, which means that I should, in theory, be able to use these to drive the signals directly and a pair of GPIO pins should be capable of driving a three aspect colour light signal.  Effectively, I'd be interpreting the output as something like IF GPIO pin 20 is 'High' AND GPIO pin 21 is 'Low' THEN 'Aspect' = Red.  IF GPIO pin 20 is 'Low' AND GPIO pin 21 is 'High' THEN 'Aspect' = Green.  If GPIO pin 20 is 'High' AND GPIO pin 21 is 'High' THEN 'Aspect' = 'Yellow'.  Unfortunately, I have two problems with this.  It's reasonably easy to write the logic as though it were some form of computer code or a formula in Excel, but as this is outside of the Raspberry Pi, I think this would have to be some form of logic Integrated Chip.  That is I would need a series of AND and NAND gates to derive the correct logic as to which LED is to be lit based in the combination of two outputs.  I think this would need two NAND gates and one AND gate for each three aspect signal, with the AND gate driving the yellow aspect and the NAND gates driving the red and green aspects.  A single GPIO pin would be required for each Position Light Signal to control Permissive Block working.

 

The other issue is that I assume the voltage on the Raspberry Pi GPIO pins will be either + 3.3V or + 5V.  This is obviously enough to drive an LED on a physical control panel, but the Absolute Aspects signals are, according to their website, designed to be operated using 12V DC.  This means that I need something (not sure what) that would translate the GPIO output into sufficient voltage to drive the physical signals.  I'm not sure that I need a DCC Accessory Address for each signal aspect, but equally, I'm not sure that I know how to do this.

 

Each NCE BD20 seems to be capable of powering an LED that would indicate occupancy, so if this LED is on the panel, then I just need a ribbon cable with a sufficient number of wires to connect each BD20 to the appropriate LED on the control panel.  Similarly, each Cobalt iP Digital, can drive an LED indicator output, so I should be able to route that signal via the same ribbon cable to an LED on the control panel.  Then if I can use the Raspberry Pi GPIO output pins to drive the panel representation of the signals directly, I suspect that I will have enough GPIO pins to achieve what I want.

 

Obviously if I don't need an accessory decoder to drive the signals (ie they are driven purely by logic to switch a 12V DC supply) then I technically don't need a SPROG (or for the ACE-2 to interface with JMRI).  It would mean that JMRI would have no ability to control the points, but would act simply as a monitoring device to ensure signals are interlocked with the point positions and occupancy detectors.  The ACE-2 could control the points via a DCC Accessory Bus, but it effectively would know nothing about the rest of the layout - ie signal states or block occupancy.  Only JMRI would know about these.

 

It's perhaps not the 'best' solution in terms of 'full automation', but I still want to drive the trains - I just want the 'system' to act as signalman and control the signals, so that I can focus on driving (and obeying the signals).

 

I'll give this a bit more thought before I ask too many new questions.

[Dungrange]

​the one thing that I would say is that anyone joining the hobby now and building a new layout should go with DCC, it doesn't make sense not to. 

 

Iain,

 

I sort of agree with you, but DCC can get quite complex as Nigel has demonstrated in the last few posts, and that is sadly beyond some people.  On the whole, DC control can be more straightforward.  I was in my local model shop recently and an elderly gentleman who seemed to be returning to the hobby after many years had bought a new Gaugemaster Handheld DC controller.  However, after looking at his new purchase, he noticed that his new controller had four wires hanging from the end, along with a small plug and socket and this made him change his mind: he didn't want the controller after all.  The shop assistant explained that all he needed to do was fix the socket into his control panel, connect two wires to the track and the other two wires to a suitable transformer, but said gentleman decided that was too difficult and he'd just stick with his old H&M Duette.  He therefore got a refund for the controller that he'd just bought.  If a DC controller with four wires is off putting, I'd like to see you try and sell him DCC with full layout automation. ;-)

 

Whilst I agree that DCC will become (and probably already is) the dominant part of the hobby, I think there will always be a place for DC, where the perceived benefits of DCC do not justify the cost, remembering that the perceived benefits are subjective.

Edited May 9, 2018 by Dungrange

[WIMorrison]

​I think that DC or DCC can be as complex as you desire - I have seen some DC layouts that achieve amazingly complex feats - though they have often achieved this though electro-mechanical switches and/or digital additions which result in a hybrid solution that is ultimately much more complicated to maintain than a pure digital system.

 

I first entered DCC about 12 years ago and thought it was a mess of incompatible systems then, regrettably it hasn't improved a lot in the time since then although there is more capability available than there was then. I would recommend that whichever route you go down that your command station has multiple bus interfaces supporting as a minimum Loconet and Xpressnet which does limit the choice but ensures that as you learn you can expand the system incrementally rather than undertaking a complete refresh.

 

 

​

[Nigelcliffe]

Nigel,

 

Thanks, I probably need a bit of time to do some research and fully digest your extensive answer.  My hardware 'shopping list' seems to have changed completely, which means I am now back at 'square one', with a whole different set of questions!  However, I think if I have understood what you are saying, I can scrap the Signatrak SIGM20 and DTM30, the Digikeijs DR5088 and the LocoBuffer-USB along with the need for a Stand Alone LocoNet or the need for Signatrak to issue a LocoNet upgrade to the ACE-2. 

 

Instead, I now have one (or possibly two) Raspberry Pi running JMRI and a number of NCE BD20, with the possibility of also needing a SPROG (but I think I may be able to get by without one).

 

Firstly, this is getting very complex and hugely layout dependent. So, at some place you are going to have to decide to start experiments one way or another to prove things work for you. I know you've started with signalling rules in JMRI in software, which is a good start, but the rest will need some testing. And, as the thread is showing, there are dozens of ways to achieve much the same - none is necessarily "better" than the other, just different. The big one is compatibility, such as the lack of LocoNet on the ACE controller: promised for the future, but not there yet.  (I can understand how Signatrak are where they are - they developed the ACE, and then, fairly suddenly, CML was going to close unless someone else took over production and support of the CML boards. )

 

 

I'd like to use the 4mm range of Absolute Aspects signals and ultimately I may have a Working Theatre Box on the layout - see https://www.absoluteaspects.com/gauge-aspect-with-route-indicator-p-373.html.  However, that is very much long term.  Phase one is to build the terminus, station throat and fiddle yard, which means that this signal will be located around the baseboard joint between the scenic section and the fiddle yard and I'm loath to spend £115 on a signal that effectively sits at the end of the fiddle yard and wouldn't technically be part of the scenic area.  For the time being, it is therefore purely a 'control panel thing'.  However, once everything is working, several years from now, I may extend the layout to represent more of the station approach, in which case this would become a real signal.  I'd therefore like to consider it as a real signal that's not yet connected (if possible).

Had a very quick look at their website, and I think they require a +12v input to each of the connecting pins from whatever device is driving them (signal decoder, Raspberry PI outputs, whatever). Some decoders will do that. Using the PI will need additional transistors to step things up to 12v. But I may be mis-interpreting the very short instructions.  

 

Of these options, I think © is the one that I would be looking at.  I notice that the latest Raspberry Pi models have 40 GPIO pins, although it appears that only 26 of these are usable inputs, the remainder being Ground (8 pins), 3.3V (2 pins), 5V (2 pins) and reserved (2 pins).

28 pins available according to the documentation I have.  

 

This is where I return to my original question.  Since the Cobalt iP Digital has a 'feedback' output, which seems to be a logic +5V / GRND depending on the throw the points, I assume that I can connect this directly to a Raspberry Pi GPIO pin?  That is, I will have a single wire from the Cobalt iP Digital motor 1 to GPIO  pin 1, a wire from Cobalt iP Digital motor 2 to GPIO pin 2, etc.

You could do this, but I have to ask why? If the Cobalt motor is reliable, and is operated by the command system (ie. instructions to throw the Cobalt go past the signalling logic device (PI/JMRI or SIGM20)), then the signalling logic will know which way the turnout has been instructed to move. Only if the turnout fails to throw, or is moved by a method outside the command system does the signalling logic need this extra feedback. The first (failure) is a reliability issue, and I'd suggest for most model rail not important. The second can happen if local input buttons are used to control the Cobalt, rather than just using the DCC signal to operate it.

 

 

Then the output from the NCE BD20 would also appear to be a logic +5V / GRND output depending on whether current is detected in the feed or return wire.  Therefore, I assume that I could connect BD20 block occupancy detector 1 to GPIO pin 5, etc.

I think that works, which is why I pointed out the BD20. Needs testing to prove it.

 

 

Finally, it seems that the GPIO pins can be configured as either input or output pins, which means that I should, in theory, be able to use these to drive the signals directly and a pair of GPIO pins should be capable of driving a three aspect colour light signal.  Effectively, I'd be interpreting the output as something like IF GPIO pin 20 is 'High' AND GPIO pin 21 is 'Low' THEN 'Aspect' = Red.  IF GPIO pin 20 is 'Low' AND GPIO pin 21 is 'High' THEN 'Aspect' = Green.  If GPIO pin 20 is 'High' AND GPIO pin 21 is 'High' THEN 'Aspect' = 'Yellow'.  Unfortunately, I have two problems with this.  It's reasonably easy to write the logic as though it were some form of computer code or a formula in Excel, but as this is outside of the Raspberry Pi, I think this would have to be some form of logic Integrated Chip.  That is I would need a series of AND and NAND gates to derive the correct logic as to which LED is to be lit based in the combination of two outputs.  I think this would need two NAND gates and one AND gate for each three aspect signal, with the AND gate driving the yellow aspect and the NAND gates driving the red and green aspects.  A single GPIO pin would be required for each Position Light Signal to control Permissive Block working.

Most of this (certainly red/green/yellow) is done within JMRI. The output pins are just like a signal decoder, and defined as part of creating the signal head. So, when the logic requires "Red" on a three aspect, it will change the pins controlling the three aspects appropriately low and high. The Theatre Box will probably need something specific adding to JMRI to control it (possibly written using "logix"), but all can be written within JMRI, no external logic gates or processors required. Its pretty much the same as to whether the GPIO pins on the PI are used, or whether an accessory decoder is used.

 

The other issue is that I assume the voltage on the Raspberry Pi GPIO pins will be either + 3.3V or + 5V.  This is obviously enough to drive an LED on a physical control panel, but the Absolute Aspects signals are, according to their website, designed to be operated using 12V DC.  This means that I need something (not sure what) that would translate the GPIO output into sufficient voltage to drive the physical signals.  I'm not sure that I need a DCC Accessory Address for each signal aspect, but equally, I'm not sure that I know how to do this.

 

Using the PI needs a simple transistor switch circuit.   There will be PI tutorials around to show how to do switch a 12v system/device from the pins, its a normal thing for a PI to do.

 

Or an accessory decoder device assuming you have a DCC system connected to the PI, which could be a DIY one at low cost, or a commercial accessory device.

 

 

Each NCE BD20 seems to be capable of powering an LED that would indicate occupancy, so if this LED is on the panel, then I just need a ribbon cable with a sufficient number of wires to connect each BD20 to the appropriate LED on the control panel.  Similarly, each Cobalt iP Digital, can drive an LED indicator output, so I should be able to route that signal via the same ribbon cable to an LED on the control panel.  Then if I can use the Raspberry Pi GPIO output pins to drive the panel representation of the signals directly, I suspect that I will have enough GPIO pins to achieve what I want.

Yes, seems possible to do that.

 

Obviously if I don't need an accessory decoder to drive the signals (ie they are driven purely by logic to switch a 12V DC supply) then I technically don't need a SPROG (or for the ACE-2 to interface with JMRI).  It would mean that JMRI would have no ability to control the points, but would act simply as a monitoring device to ensure signals are interlocked with the point positions and occupancy detectors.  The ACE-2 could control the points via a DCC Accessory Bus, but it effectively would know nothing about the rest of the layout - ie signal states or block occupancy.  Only JMRI would know about these.

 

It's perhaps not the 'best' solution in terms of 'full automation', but I still want to drive the trains - I just want the 'system' to act as signalman and control the signals, so that I can focus on driving (and obeying the signals).

 

I'll give this a bit more thought before I ask too many new questions.

 

Yes you are correct on not needing a Sprog (Or ACE-JMRI interface) if you don't use accessory devices.  But, I think it will be simpler to drive the Cobalts via Accessory Bus, and it would also be easier to add the signals that way with accessory devices in future, rather than the GPIO pins.  Obviously this depends on number of pins available, and number of signalling outputs needed, etc...    The advantage of an Accessory Bus is reducing the wiring from PI out to layout, it becomes a two-wire system for output.   

Sensing could also be reduced to fewer wires by using some sort of databus for the sensors, but that's yet more stuff to pile onto an already complicated, and largely theoretical design. 

 

 

Coming back to the GPIO pins to sense the position of the Cobalts - clearly if there is no connection from PI/JMRI to the instructions going to the Cobalt, then the sensing is needed, or the signalling can't know the turnout positions.  But that uses up pins, and those pins could be doing something else, such as outputs to instruct the Cobalts to move. (Or put the Cobalts on a DCC Accessory Bus).

 

 

 

I you do end up going this whole "do it yourself with a PI" route, then the accessory devices for the signals can probably be done with Arduino devices as DCC accessory decoders, with more flexibility and a lot cheaper than commercial units.  "Rudy" on this forum has posted quite a few articles on the topic. 

 

 

 

"Full automation" (ie. computer driving trains, or computer driving some trains with human doing a few others at the same time) is very different to "signalling system".   I'd be very cautious about suggesting JMRI for full automation.  It can be done, though I'd suggest looking at alternatives first.  And full automation is usually best done by "select software to do the job", followed by "buy hardware that works best with this software".   

 

 

 

 

 

Lots of possible solutions around, and which is cost and time-effective does come back to what you're end goals are, how complex the layout, and your interests.    I'd be considering the lengths of wiring runs before going too far - long distances from sensors to computing device may be unreliable (spurious signals from cross-talk onto long wires),  and lots of wire everywhere can be incomprehensible spaghetti under a layout.   In those cases, concentrating devices into smaller areas (perhaps at higher cost) may be more effective in the future.  

 

And, if the PI looks like a genuine solution, then before too much longer, it will have to be "buy a PI, and a breadboard, a few switches, some LEDs and resistors, a BD20 and build some test setups".  Which comes down to valuing things, including the amount of your time this might consume, and whether that time has been "well spent" doing the PI stuff, or is it a distraction from your real aims.   If its a distraction, spending more money on something which is more "out of a box" may be effective in achieving the end-goals.   

 

 

 

- Nigel

[Dungrange]

Nigel,

 

Thanks - unfortunately, I realised a flaw in my thinking even before I read your reply to my earlier post.  I was erroneously thinking that the GPIO pins are effectively logic-states (ie they are 'switched' by the Raspberry Pi to represent the state of something; thrown/closed, occupied/unoccupied, on/off etc), but of course, I assume that they can also be used to carry a pulsed signal, in the same manner, as a LocoNet is effectively six pins at each device interface and that is able to do so much more.  As such, the 26 or 28 pin limit (I'm not sure about the ones that I read were reserved for something) is perhaps not as big an issue as I thought it might be.

 

My erroneous thinking was then that since I don't need the Raspberry Pi / JMRI software to control the points (it can be done with a panel switch and a DCC accessory bus from the ACE-2 to the Cobalt iP Digital point motors) that means I don't need a connection between the Raspberry Pi and a SPROG.  That is, I don't need JMRI to issue a command to change a point, so it doesn't need a connection to a command station.  As such, I assumed that using the feedback logic from the Cobalt iP Digital would be all that I need as an input into the signalling logic in JMRI.  However, that bypasses two of my reasons for wanting an automatic signalling system.  Firstly, I want the signalling logic to be able to prevent me from throwing a set of points when the block that they are in is occupied (ie to avoid accidentally derailing a train) and secondly, I don't want to be able to set a route (or clear the signals) where one train may conflict with another that is sitting foul of its fouling/clearance point (ie a possible collision).  This is my reason for wanting to use block occupancy detectors rather than point detectors such as IRDOT.

 

However, to achieve what I want means that any command to change a point (whether that be via a switch on the control panel or via the DCC command station) must be routed through JMRI, since I'm effectively looking for JMRI to decide whether or not it is 'safe' to throw a particular point.  That, therefore, means that I can't have a switch on the control panel that interfaces with the Cobalt iP Digital directly and I need a signal to be sent from the switch to the Raspberry Pi, JMRI makes the decision that it is 'safe' to throw that point and then issues an appropriate signal to the command station to perform that action.  That, therefore, means that I do need an accessory bus that is linked to both a DCC command station and the Raspberry Pi.  I, therefore, need to ask Signatrak whether they have any plans for JMRI support in a future Firmware update.  I think they do have plans, but I'm not sure of the timescale.

 

As you say, I think I just need to start with the signalling logic in JMRI and then take it from there.  Once I know that JMRI can do what I want, I can then look for a Raspberry Pi and in the meantime, I can get on with actually building a layout.  I'm sure we can pick this up when I have made some real progress.  I am prone to trying to overthink things, which can lead to procrastination.

[Dungrange]

And there is the outputs to the Signals themselves, which needs something to drive the signals, such as a DCC accessory decoder.  And, that in turn requires that the (or at least a separate DCC accessory bus only) command station is connected to the Raspberry PI.  And, at the moment, the Signatrak ACE doesn't have support in JMRI - ask Signatrak to do some work on that and it could happen.  Or, you need another command station for the accessories - a Sprog may be the cheapest option.  

 

Well, having contacted Signatrak, the good news would appear to be that Signatrak are currently working on a major upgrade for the ACE firmware, with emphasis on the (USB) computer interface, which will enable control from JMRI and other proprietary layout control software packages.  This firmware update should hopefully be released later this year - certainly before I have the layout built.  It would therefore seem that I can create an accessory bus from the ACE and therefore won't need to purchase a separate accessory bus command station.

 

Below is the plan in JMRI so far.  Unfortunately, I seem to have accidentally added an icon that I can now no longer click on to remove and have inadvertently duplicated a ground signal at the same location, which I also don't seem to be able to remove, because clicking on the location seems to select the turnout.  Once I've sorted that, I should be able to try looking at the signalling rules and see if this can do what I want it to.

 

[WIMorrison]

I would caution on the timeline of a 'major upgrade' as this hobby is lttered with major upgrades that are being worked on and we are still waiting on many years after the announcment of them.

 

I wold also suggest that a USB connection isn't really the best form of connection since again there are numerous cases of people being unable to make a USB interface work with computer A or B due to incompatibility or unavailability of the appropriate driver software.

[Dungrange]

Iain,

 

To be fair, I think your caution with regards a timeline applies to more than just model railway electronics.  I think optimism bias is applicable to all development tasks whether that is a new wagon from Bachmann, a new corporate IT system, the construction of a new road or the reopening of a former railway line.  The time that it takes to overcome challenges that were overlooked at the scoping stages is a consistent problem in many walks of life.

 

The e-mail that I received from Signatrak actually said "I hope to have at least an initial release available in a month or so", which I interpreted as "hopefully later this year".  However, I'm not too bothered about an actual release date as it will hopefully be available before I actually get this far, even if it is delayed by six months or more - I've still to finish the baseboards, build the track and pointwork, start on the wiring and commission the signals before I'm going to need that JMRI to ACE-2 interface to work.  I'll also need to buy quite a bit of 'kit' in terms of block detection, so I don't need it now - just as long as it's likely to appear in the foreseeable future is good enough for now.

 

The ACE-2 already has a USB interface, although, at the moment, this is only to allow new firmware upgrades to be downloaded and applied from a PC.  As I've not had to do this yet, I'm only assuming that it works for that purpose.  I had actually thought that most systems used USB to interface with a PC for running one of the many computer control programmes.  I guess I'll just have to wait and see.