Very interesting discussion here: http://cs.trains.com/mrr/f/744/t/230553.aspx

Summary, TL/DR: We can power a LED directly from DCC, just add a resistor to limit to about 10 mA (or less if too bright).

Suggestion is "nice to have" a reverse parallel diode to limit the reverse voltage on the LED:

However another comment indicates it's enough to compute R to be within the specs of the reverse voltage of the LED (assuming I have the specs).

I tore down my previous layout #2 since it didn’t have a purpose anymore -- originally it was for the kids to play with and for me to play with cameras recognition of trains and automation. I’ve done my part, and the kids didn’t show interest anymore. Being a 4x9”, it was still taking valuable space in my small room. Time to update.

What I cared for is having a workbench and a simple test track on top of it. I came up with a very simple L-shaped workbench design. The workbench is designed to not have any legs in the way and lots of storage space underneath. For the test track, I have a bunch of EZ-Track around so I just used that. It’s suitable for minor switching. I won’t add any scenery, it does not need to look like a shelf layout since it’s a workbench.

“Conductor” is the name of the software that controls the automation on the Randall Museum Model Railroad. It’s written in Java and integrates into JMRI. The other part is the Android tablet display software. Combined, both create “RTAC” -- the Randall Train Automation Controller. I started the conductor project in mid-2016 and by the end of 2016 I had a working version deployed on the layout at the museum. Immediately after that, I started thinking about extending it already :-)

The RTAC / Conductor source can be found in this Bitbucket repo https://bitbucket.org/model-railroad/conductor with a GNU GPL v3 license.

--

Here's a rethink of the automation software.

Right now I have JMRI for sensor management and DCC throttles. Conductor acts as a plug-in that drives the automation purely on sensor+timer event based script.

To detect trains on the branchline, I experimented with using IR reflective sensors instead of block detectors. These have the advantage that they are inexpensive and can be connected directly to an NCE AIU01 board.

The original idea was to embed the sensors in the track bed. The sensors are fairly small and fit nicely between ties. The one chosen have a detection range of 2-15 mm, which would be ideal to detect when an engine truck passes over the sensor.

The IR reflective sensor used are TCRT5000. The Vishay spec can be found here.

This model is nothing more than 2 separate "LEDs" stuck together in a flimsy small plastic shell. They can be easily removed from the plastic shell and mounted in the track flush with the ties, pointing upwards (technically one LED is an emitter and the other is a receiver so calling it a LED is abusing the term, although it may look like one).

The photodetector on the TCRT5000 varies its current based on the amount of light received. No light, no current; lots of light, more current. The amount of light that bounces and the collector current depends on the distance between the detector and the object. The nominal distance is 2 millimeters and experimentation showed that I could get away with much more.

One of the LED is an emitter and needs to be powered by 5 V and a resistor (to limit and adjust the current). The other side is a phototransistor, NPN type.

How is the IR sensor going to connect to the NCE AIU01?

Looking at JMRI Logix, this is a non-script click-o-drome if-this-then-that.

Conditions range from block, sensors. Actions are signals, turnouts, scripts or warrants.

Conditions can act when set or on change.

No direct throttle control, maybe indirectly via warrant scripts to run "auto trains".

One possibility is starting a script when some condition happen.

Seems interesting for people who don't want to write scripts. Tons of clicking to get things done.

Seems ideally suited for simple linear decision trees, not for free-form scripting.

Examples would be signals or turnouts set depending on block usage.

For my automation purposes, it seems fairly weak and I’ll design my own software that uses a text file for configuration. Somehow it makes non-tech people very nervous and Windows users especially seem to enjoy clicking ad nauseum in poorly designed modal dialog boxes instead of having a single text file script they can look at quickly.

https://ncedcc.zendesk.com/hc/en-us/articles/200933425-Common-Cab-Questions 

• The NCE PowerCab / DCC Twin can only use cab bus addresses up to 10.
• 0-1 are the internal twin cabs.
• 2-7 are for throttles.
• 8-9-10 are for cab devices.
• The NCE AIU01 can use only cab bus address 4 or 48-63. That means effectively on a PowerCab bus it can only use address 4, there can't be more than one on the whole bus. Quite disappointing but OK enough for home since I had no plan to have more.

I got an NCE Switch-8 to learn what I can (and cannot) do with it for Randall.

Looking at the electronics on the board… If there’s one thing I like about the NCE electronics, it is that they are not fancy. This is the tech I grew up with and I can look at the board and recognize the components and understand what they do. I hope it will stay like that.

Microproc: PIC16F1936

http://www.microchip.com/wwwproducts/en/PIC16F1936

http://ww1.microchip.com/downloads/en/DeviceDoc/41364E.pdf

Pin 1 = Vpp (programing voltage)

Pin 8 = Vss (-)

Pin 20 = Vdd (+)

Power: MCC 7805CT

http://www.mccsemi.com/up_pdf/MC7805CT(TO-220).pdf

Front Left to Right : Pin 1 / 2 / 3

Pin 1 = Input / Left

Pin 2 = GND

Pin 3 = Output / Right

On the Switch-8, the large programming header can be used to get the +5 from the 7805.

From top, #2 is the +5 and #3 is the Gnd from 7805 (shared with the GND headers).

NCE AIU01: there's a similar 7805. A +5V can be soldered on the little through-hole just on top of the 7805 on the board. Measures 5V. For a single IR sensor, use a 220 Ω resistor.

From both the NCE USB v7 doc (see NCE website) or from

http://jmri.sourceforge.net/help/en/package/jmri/jmrix/nce/packetgen/NcePacketGenFrame.shtml

Example: 0xAD is for switching an Accy/Signal. There is no provision to read the state.

• E.g. 0xAD 0x00 0x03 0x03 0x00 ⇒ throw 0x0003 in normal direction
• E.g. 0xAD 0x00 0x03 0x04 0x00 ⇒ throw 0x0003 in reverse direction
• 0 is an invalid address.
• Max address is 2044 (0x7FC) which is a broadcast address for Accy.

Note: when trying in JMRI > NCE Command, "Binary" means hex without x, seriously \o/ ?

Lockout CV 556:

• Use on Address of input #1, which is 4 for my home one.
• 556 = 0x022C
• 0xAF is Ops ACCY programming.
• AF 00 04 02 2C [0=unlocked | 1=locked]
• This works. It locks buttons out.
• ACCY on controller can still be used to throw turnouts.

That means I can trivially command that from an Arduino and bypass JMRI if needed.

Experiment from tonight: control the EZTrack #6 crossovers using the NCE Q-Snap. ⇒ Failed.

I have 2 EZTrack #6 turnouts mounted in cross-over configuration. The idea was to power them from a single Q-Snap output to save one output for each cross-over.

The Q-Snap has no problem driving a single #6. But ever the largest timing I tried does not make the crossover (2 turnouts in parallel) toggle properly. They either bounce or switch half-way.

I also tried using a 9V DC power brick instead of the DCC power. That didn't help. Supposedly that way the turnout should get 9x2-2 = 16 VDC. However from experience I remember I always failed to trigger them in DC, which is why I previously used the AC from the EZTrack ACC power brick.

DigiX: 11 x 6 in

NCE Q-Snap: 4 x 3 in (DCC bus)

NCE AIU01: 4 x 3 (2 RJ12, comes with one cable)

XminiLab scope + board: 2 x 3 // 3.5 x 3 in

NCE UTP: 3 x 2 x 2 in deep

Notes:

• Q-Snap really needs 3 outputs per turnouts, it carries its own common per twin-coil. It's not clear whether I can share the commons since each one has its own capacitor.
• The DigiX relays OTOH work by sharing the AC common so I have 2 outputs per turnouts plus one common.