What This Is All About: JMRI Sensors Aplenty for Any Layout

JMRI is a free software application that runs on Windows, Linux or a MAC that can perform a multitude of functions. It makes programming complex DCC decoders much easier. It also is used for dispatching, signaling, switching, route control, train control, interfacing to WiFi controls and cell phone throttles, and more. A number of these options need to know where locos and cars are around the layout. That is, JMRI needs to “sense” where things are. Years ago I might use a thin metal contact pushed to closure by a loco or car wheel. That contact or switch closure might have lighted a panel indicator or even turned on a relay to throw a switch. JMRI can do a hundred things more interesting than that.

This project will show you how to connect up to 68 sensors to JMRI with a single Arduino, and what to do to set up your sensors in JMRI. From there, you are on your own as far as this article goes. It will allow you to choose any kind of sensor that will pull a signal wire to ground (including the switch closure of old) and route it into a JMRI sensor table with minimal load/disturbance to JMRI. It will also automatically initialize all the sensors you have set up, upon connection to JMRI. The hardware connection will be made with most any off-the-shelf Arduino board (unmodified). These will connect via any USB port, to your computer running JMRI. This will be the same USB serial port you use to load the Arduino board. I’ve written several times before about installing and loading Arduino software: in MRH December 2016, A modeler’s introduction to the Arduino http://mrhpub.com/2016-12-dec/online/ and here: in MRH March 2017, DCC projects using the Arduino  http://mrhpub.com/2017-03-mar/online/html5/

I’ll also show how to set up the sensor table in JMRI which will keep track of everything for you. If you need more info about JMRI, start here: http://jmri.sourceforge.net/help/en/webtoc.shtml

If you need some more info about Arduinos and sensors, look here:  https://www.arduino.cc/en/Tutorial/HomePage-0008  All code for the Arduino and for JMRI is available here:     JMRI_Channels_Rev2.zip

There is a companion article to this: SMA29 JMRI Turnout Channels – Direct JMRI to Arduino Communications - Simple Support for Lots of Data Out From JMRI  https://forum.mrhmag.com/post/sma29-jmri-turnout-channels-%E2%80%93-direct-jmri-to-arduino-communications-simple-support-for-lots-of-12210817  describing a JMRI to Arduino output channel.

Build Details

This “Sensor Channel” is built with an Arduino Mega2560 controller and an optional Mega Sensor shield, for about $12-16 total depending on where you purchase them. Here is what I used:

MEGA 2560 R3 ATMEGA16U2 ATMEGA2560-16AU Board + USB Cable For Arduino https://www.ebay.com/itm/253733606559  11.95 (you can get a Chinese knock-off for $7)

MEGA2560 ATmega2560-16AU Sensor Shield V2.0 

  https://www.ebay.com/itm/201004504826   $2.56

 

 

Arduino Mega2560

 

              

Arduino Mega2560 Sensor Shield

The Arduino Mega2560 controller is loaded exactly like the other Aduino’s I described in the December 2016 issue of MRH A modeler’s introduction to the Arduino http://mrhpub.com/2016-12-dec/online/

With exactly the same free tools that can be downloaded here:  https://www.arduino.cc/en/Main/Software

The sensor shield board literally plugs into the top of the Mega2560 board, and has two screw terminals where you can connect a 5 Volt power supply to power the assembly and even the attached sensors.  The shield board makes attaching your sensors easy. Each sensor (and its corresponding signal (S) pin) is numbered on the board from 2-53, and then from A0-A15 (corresponding to sensors 54-69). Pins 0 and 1 are taken for USB communication. Each numbered connection on the sensor shield provides a group of 3 pins with the sensor connection (S), a+5 Volt pin (V), and a ground (negative side connection G). Most sensors that are available will act as a switch, connecting the S pin to the G pin. You can use a switch or metal contacts on a relay or tortoise switch motor as a JMRI sensor by connecting the switch contacts to S and G yourself There are jumper wires already made of varying lengths available from many sources including Pololu.com and ebay.com that will slide onto these pins directly. With a little care, you can also solder connections too.

 

Jumpers from Pololu.com

Sensors can take on many forms. As said previously all the ones that are of interest here set their sensor output to ground when activated. Some are shown below, but there are lots more available. You can get an idea of the many available here: https://randomnerdtutorials.com/21-arduino-modules-you-can-buy-for-less-than-2/ 

      

IR Detector.jpg                                                      Infrared PIR (Human) sensor

 

 

Twin-T Detector   https://forum.mrhmag.com/post/sma26-revised-twint-block-detector-for-dc-and-dcc-train-detection-12208276

 

    

Point or Position Detectors  https://forum.mrhmag.com/post/sma23-%E2%80%93-a-new-dcc-dc-car-loco-detector-%E2%80%93-differential-absolute-position-detector-dapd-12203476

 

          

Track Contacts as sensor                                       Toggle Switch           Push Button

The Arduino Mega2560 will use all 68 pins as digital sensor inputs. An Arduino UNO, a Pro Mini, and a Nano will have 18 pins available (Digital pins 2-13, and A0-A5 or Digital pins 14-19) for sensors. There are two different pre-configured sketches to load either a Mega or one of the smaller boards. All files can be found here:  http://mrhpub.com/files/users/geoffbfiles/JMRI_Channels_Rev2.zip

 

Both sketches assume all pins are scanned as sensors and will match JMRI USER-DEFINED sensor names from AR:2-69 or AR:2-19 .  The AR designation is completely arbitrary, but if you want to change it you will have to edit theJMRI  Sensor_Scan Python Script provided. When you download the Arduino sketch into your board, you must make note of the Serial Port on your computer used for communication between the Arduino IDE edior and your board. Your should always  plug your Arduino USB cable into the same USB port/socket, so you will get your operating system to assign the same USB port. If your switch computers, it is likely the USB port number will be different. This is important because you must make sure the JMRI Sensor_Scan Python Script is edited (line 82:  a = SerialSensorMux("COM5")

with the correct COM port number.

 

Load the appropriate Arduino sketch onto your favorite board, attach a sensor shield if needed, and leave the board connected to your computer that you will run JMRI. Now before you start JMRI you must either have just powered on your board, or simply hit the reset switch on your board.

 

Open JMRI and open your sensor table, which may only have one entry for ISCLOCKRUNNING. Go to the bottom of the Sensor table window and click Add…

The System Connection: can be set for either internal or hardware addresses. I usually select “Internal” from the drop down pick.

In the “Hardware Address” space simply put “0” (zero) this can be most anything you want within limits

In the “User Name” space simply put “AR”

Click the box for Add a sequential range

For the Number of items enter 69 for a Mega2560 and 19 for an UNO, Pro Mini, or a Nano

Then click on Create

Go back to your sensor table and click on the “User Name” label at the top of the column to get a clean sort by all the user names you just created

Now delete the entry for “AR” and “AR:1” since we will not be using them. You should now have 68 sensors left in the table with user names AR:2 through AR:68. These will be initialized by your mega at start up. Last save your work as a panel by using Panels-> Save Panels… and name and save for later.

 

Now locate when you unzipped the Scan_Sensors.py file you edited with the correct COM port.

From the JMRI menu  go to Panels -> Run Script and find your up to date Scan_Sensors.py file, but before you click on Open make sure you reset the Arduino Mega board (with the push button).  Run the script and you should see all your sensor go from “Unknown” to either Inactive or Active depending on what you connected to each pin (remember connecting a digital signal pin (S) to ground (G or GND) will set the sensor active. If for some reason you use sensors that are “Active HIGH” that is when they sense something they go HIGH and are normally LOW, then in line 18 of the Arduino sketch change:

#define Sensors_Active_Low 1

To

#define Sensors_Active_Low 0

How This Works

Many  Arduinos have  a serial line available for general use. It is the same serial port used to load and setup the board. Once configured thee same serial port is available for communication back to your computer. There are actually many components internal to JMRI, and JMRI provides access to its internal structure via "scripts" wrttten in another language called "Python" along with an offshoot called "jython" for Java Python. These scripts allow modelers to add additional capabilities to JMRI without developing a major interface to JMRI like Digitrax, CMRI, or DCC++. The Arduino wakes up on power on to wait for a set of characters from the JMRI script to initiate communications. It is likely that if both are powered on simultaneously, the Arduino will sit waiting for JMRI to start. When the Sensor_Scan.py JMRI script starts it sends the initialization message to the Arduino, when then sets off to update every sensor it is responsible for (that is all valid pins it is configured for).  The Arduino then sends a sensor update message in 2 bytes at 19200 baud to JMRI which then updates the appropriate sensor, matching the sensor number received from the Arduino with the user defined name like AR:54. User defined names can be applied to either internal or system hardware numbered sensors -- it doesn't matter. The Sensor_Scan script is robust enough to handle undefined sensor names on the JMRI end, by printing a message on the script output window.

 

Additional JMRI Notes

 

Adding buttons to run scripts is pretty easy. Once you open JMRI PanelPro,
from the menu bar click Edit-> Preferences... a Preferences window will open.
Click  Start Up then at the window bottom click Add then Add script to button...
Give the button a name (this will be the text on the button) and browse to where
you put the script you want to want to run when you click the button and click OK

If you saved the sate of your panel, you can also click Add-> Open File... and have JMRI open your panel
file at startup

You can also click Add button to main window... to have buttons to open tables, script output windows,
turn on Power, etc.

All of these same actions can be set up to run at power up by selecting Add -> Perform action... in a similar manner

Once you have set all these up, make sure you order the list of start up actions, by selecting an item in
the list (single click) and clicking Move Up or Down  at the window bottom.

Once you are done click save on the lower left of the window, and it will ask if you want to restart. When
you restart JMRI it will come up with all the buttons placed in the entry order in the table,
and all the actions you specified to be done upon JMRI startup. Any or all of these can be removed
by selecting the action line and using the Remove button on the lower right of the window.

Before you start JMRI power on the Arduino channel, or hit the reset button on the Arduino.

There is a script called SensorSerialClose.py in the zip file. If you run this
it forcibly closes the serial port it is set up for. If the Sensor_Scan.py script is running,
it has the side effect of terminating that script. If you terminated the Sensor_Scan.py
script via the Kill button in the Thread Monitor window for any reason, JMRI would leave open
the COM port to the Arduino, preventing you from re-running the Sensor_Scan.py successfully.
So running SensorSerialClose.py will close the port and allow you to 1. Restart the Arduino via button push and 2. Then restart the Sensor_Scan script successfully.

The Sensor_Scan.py and the SensorSerialClose.py scripts should both refer to the same COM port.
You can copy and rename these 2 scripts for each COM port channel you create.

I should point out that you can have multiple Sensor channels operating at the same time via different serial ports. In the Arduino sketches you will find info on how to set the range of sensor numbers that each channel can be assigned. In order to run multiple sensor channels you will need to make each sensorscan script independent of each other. You will need to edit and copy each script for each COM port and change the following lines:

line 17:   global extporta                             # the name extporta must be unique for each com port

line 22:        self.port = extporta                   # same as above

line 23:   extporta = self.port                        # same as above

line 82:   a = SerialSensorMux("COM8")   # This COMx MUST correspond to a specific Arduino channel

line 85:   a.setName("SerialSensorMux8 script")  # Make this a unique name to minimize confusion

 

For some reason, I could not use export8, export9, etc. These had to be ending with an alphabetic character not a number, like exporta, exportb, exportc, ...

 

Last Note: There is a "feature" built into the sensorscan script: if it reads Sensor Number 1 as "1" it will terminate the sensorscan scrpt in JMRI. Normally pin 1 (hence sensor 1) is NOT used for data input on the Arduino. If you change the pin mapping beware of this built in termination facility. If you don't want it, you can delete lines 55-60 in the script.

 

Unfortunately, this does not tell you how to use sensors in JMRI. In the video I provided you can see how 2 sensors are used to operate a back and forth simple shuttle engine (you could use it for a trolley or MOW car too). This is a very simple example, but now you can have lots of sensors with which to be inventive. In the video it demonstrates how you can set up JMRI to automatically load up your sensor channel(s) at JMRI start. … and yes you can operate as many sensor channels has you have USB serial ports, and in MS Windows, that is a bunch!

 

Have fun! 

Best regards,

Geoff Bunza

Just what we needed

Geoff,

You have done it again!!!  Your $5 decoders and subsequent projects used to control things from DCC and JMRI have been very useful.  But we have needed some way to get sensor info back to JMRI.  This is the answer that we have been waiting for.

Thanks for your continuing help and for sharing so many great projects.

Gee Dr. Geoff

It’s a good thing you’re heading us toward a totally automated railroad.  With all these great projects to build we’d never have any time to operate it!

Thanks!!!  This one looks like a lot of fun!

Nick

My first thought is a Tortoise switch (on the bottom) showing position to the Arduino easily transmitted to JMRI.  Then.... and.... and....

I was just about to start

I was just about to start figuring out how to set up sensors. You've got my interest. I just ordered some megas and sensor shields. On to the adventures. 

Thanks

Thanks Geofff

Thank you for your help can’t wait to try it out.

thanks again

Mike

DCC Track block current sensing

Is the a low cost CT module to interface with this?

Nice Work

Great to see the animation factory back in production Geoff. My brain is already cogitating on how our club layout might use this to control our Faller car system.

 Not sure that Lin will be impressed about you spelling her name wrong tho

@Dave, Nick, Carolina Nothern (name?), & Mike

Hi Dave, Nick, Carolina Northern (name?), & Mike,

Let us know what you do with your batch of sensors, and Have fun! 

@Odynuck re: CT modules

Hi Odynuck (name?),

Have fun! 

@Peter re:Yet another typo! And Sensors for DC Layouts

Hi Peter,

Yup, you found another one of my 5000 typos!! 

Your comment got me thinking (an incredibly dangerous thing  ). When you have the ability to sense many points and feed them directly into JMRI, you can use all the display capability and Logix capability -- really most internal capabilities (exclusive of DCC control interfaces) with any external system or application, including DC layout controls. You would not have the throttle control (obviously) but the panels could still provide route indications, etc. There is an ArduinoCMRI library that also has the ability to drive outputs through the Arduino, but requires JMRI to be configured with the CMRI control interface to work. The combination might offer some new possibilities. A direct output interface from JMRI should be possible too, but there may be some timing issues with this that are unknown to me. Monitoring your club's Faller car system should be possible.

Have fun! 

So, I suppressed

this response the first time as being self serving.  How about an i/o interface?  34/34, maybe?  I can see using such an interface to handle either 34 or 17 tortoises with a single, albeit dense, shield - or maybe two.  I have four 16 or 17 tortoise staging throats (two double ended yards) in the plans which will need tortoise control and feedback, along with supervisory monitoring and control from JMRI.   I may also want remote button control and occupancy feedback, not sure yet.  I had resigned myself to writing this mess from scratch, but you've done at least a third of the work at this point, it seems to me.  Not sure where you're heading (e.g. I can almost see a hint above that your next post might be a completely output module, as opposed to sensors), but I'm very interested.  I have 64 tortii from my previous layout that were wired using recycled RJ45 cables, so I can see a shield board made up with RJ45 plugs to drive as many tortii as the 2560 would handle.  Of course, it might not be the same footprint as the 2560 itself, but in the spirit of the old PC104 formfactor, at least the cpu footprint would be standard.

And yes, I will do it myself if that's not where you're going.  But I like the idea of piggybacking on an existing comms standard, especially with the kernel of a JMRI interface established.  CMRI is interesting, but I smelled a layer of unnecessary complication that supported functionality I wasn't seeking.

Thank you, Geoff, for yet another stellar step forward.

Blair Smith

@Blair re: Future Developments

Hi Blair,

First, I'll give a little context. The DCC bus is a communications channel and a power distribution bus. It uses the command signal itself to carry the power -- not what I would have done, but that is the way it is. Nonetheless, with only two wires to route around your layout you can control many items. Next, there is no reason whatever that you could not have more than one DCC bus, and my focus on animation is to use a separate, high power (greater than 25 Amps) DCC bus to control layout-wide animation. This might not sound right-headed until you realize there will be no tracks attached to this DCC bus, and no exposed wiring. So the possibility of shorts will be limited to component failures and catastrophic clumsiness on my part -- both I hope will be unlikely. Hence a high power DCC bus is workable. My multifunction decoders help deal with output interfaces, and these sensor channels provide high bandwidth feedback back to JMRI. But there still may be a need for simple, high bandwidth output from JMRI, which led to my previous comments.

I would never discourage another modeler from pursuing their independent efforts to solve similar problems, and I encourage you on to explore your own ideas. Here are some things to think about that might be of interest. These sensor channels work very well because the bulk of the workload of scanning sensors for changes, and only updating JMRI when needed, is all on the Arduinos. So they are attached support processors for JMRI and reduce the load on the JMRI application. Initializing all the sensors is another obvious plus. 

Sending data out of JMRI is a different problem. First, when would this be appropriate? For simplicity's sake, let's consider the light table in JMRI as a simple example. It is essentially a digital, on/off indicator that can be controlled by different means. How would one get the lights info out via a bulk interface? There are at least two issues: Should the transfer occur periodically, or should the transfer be triggered upon a change in the table? If timing were not a serious problem, one could write another script for JMRI, which could wake up, say every tenth of a second or so and either transfer the entire table, or look for changes and only communicate those changes to an attached Arduino. I don't know if this would be "good enough" or not. There are ways internal to JMRI and Python to set up a "watcher" to initiate action based on internal events and changes, but I don't have a good understanding, as of now, as to how much overhead this places on JMRI, or whether this is even do-able for all table entries.

These are among the things that have influenced my modeling, and I share them with you and everyone else in the hope that they might be useful with your own efforts.

Have fun! 

Article on sensors

@Manos

Hi Manos,

I have built a number of small demo "layouts" or dioramas and the RPi running JMRI would be an excellent combination with these. I am working on an article directly related to this right now.

Remember, one does not need to use the sensor shield for this application, but with its very low cost, it can sometimes make things easier for many modelers.

Have fun! 

Who is Brian?

Blair

@Blair

Hi Blair,

Sorry about that chief! I'll mark that off to another momentary lapse of insanity... I have made adjustments!

Have fun! 

Hi Geoff

No problem, wasn't sure if that was for me, or if I was about to hijack someone else.

I wasn't looking to do anything with the DCC bus.  As for USB, my only problem with assigning one USB port for each 2560 is in the capabilities of Windows, etc. to support an array of devices.  For example, the JMRI-on-RaspberryPi implementations have at most 4 USB ports, as I understand it.  Not sure they allow port hubs in that instance.

But the command complexity of addressing many devices across one USB port, at least using a traditional RS485 (or similar) multi-device addressable series, becomes painful, and it also would make the JMRI support more complex.  So it might be best to just keep to one USB port, one device for now, until we exceed the OS' capabilities.

As for your 2560 implementation, all I'm looking for is the output equivalent of your 68 sensor(aka input) configuration of the 2560.  I wanted to know, will we see that as the 'next installment', making our efforts to do it counterproductive, albeit a learning point?  To be clear, it's the communications with JMRI, and the support therein, that I expect will take the longest to establish. 

More or less as you outlined, what I would expect is an engine within JMRI to allow two forms of 'send' - a dump of the entire output array of the 2560 on command (i.e. in a script), and a 'point update' that senses a change and transmits only that, to prevent backlogs - no need to send the whole thing every time a signal flickers due to unrelated logic errors, for example.  The latter would need to be launched as a thread that loops periodically at some rate, as you suggest perhaps 10 Hz, until it is shut down.  That loop might need to run faster while implementing some form of debouncing (i.e. run at 20 Hz, but only send point changes that have persisted across two loop iterations), again to avoid side effects of logic execution elsewhere in JMRI. 

This means the 2560 code requires response to three commands 

- an initialization command/response format

- the ability to receive and acknowledge single point updates

- the ability to receive and acknowledge blast updates

That's a pretty simple device, conceptually.  The devil is always in the details, though.  And the JMRI side is a mystery to me, right now.

I'm going to go look at your project, and decide how I will proceed.  

Thanks.  As always, your projects are thought provoking, as I'm sure they're intended to be!

Blair

@Blair

Hi Blair,

You can have a whole bunch of USB ports/serial connections with the use of USB hibs, and they are also low cost. To me this is a non-issue and I have no interest in using an RS485 alternative.

I've got a semi-operational interface to output via the Arduino USB link with no ETA for delivery. BUT, it does seem to indicate this is entirely do-able in the same fashion as the sensor channel. I will likely continue to investigate. This will likely be another simple one way transfer, if that is of any help to you. Experiments today were more promising than I thought they would be!  How about that? 

Have fun! 

Sounds good

And I agree, the port expansion solution if we need more input or output boards makes a lot of sense.  So you're working on an all-output version?  Any idea of the signal count, yet?  When I looked at the 2560, I thought 54 DIO and 14(?) AI was the limit, so if I didn't misunderstand it, the output count would be 54.  Still formidable.  One of the things I like about Tortoises and their cousins is that a contact pair can be read back to ascertain position at power up, allowing the controller to reflect the state of the tortoises without moving them.  However, that makes it necessary for the controller to have both inputs and outputs...

Anyway, thanks for your efforts, Geoff. With two yards with two 16 turnout throats in my future, I'm watching...

Blair

@Blair

Hi Blair,

This should give you some food for thought:

SMA29 JMRI Turnout Channels – Direct JMRI to Arduino Communications - Simple Support for Lots of Data Out From JMRI
http://model-railroad-hobbyist.com/node/34417
/> This is a low-cost, relatively simple project to use JMRI as switches to control most anything an Arduino can control.
Have fun!
Best regards,

A full meal,

Indeed!  Thanks, Geoff.  Time to resurrect my two 2560s and look this over.  Full speed ahead!  The two 2560s will cover off everything I need for one staging yard, or, since they're stacked, one can cover off the east end of both, while the other cares for the west ends.  Of course, it'll take a bit of work to get all the ins-and-outs sorted, but wiring is simple.  Gangbusters!

Truly, thanks a million.

Blair

Thanks for doing the hard work

Makes is easy for myself and I'm sure lots of other modelers to take their layouts to the next level. This really opens up all kinds of possibilities that I can now use.

I enjoy all of your articles that you have shared.

Tom

3 in 1 Configuration

Is it possible that one unit can be setup with three configurations?

Would like to use it for Inputs (Sensors, Push buttons) Outputs for servos and outputs for LED lights.

Can one Mega/UNO be setup with your sketch and shield and then in JMRI setup the tables to assign the 67 I/O's in groups as needed?

RCMan

@RCMan re: Combined Configuraton

Hi Dennis,

Quote:

Is it possible that one unit can be setup with three configurations?

Would like to use it for Inputs (Sensors, Push buttons) Outputs for servos and outputs for LED lights.

Can one Mega/UNO be setup with your sketch and shield and then in JMRI setup the tables to assign the 67 I/O's in groups as needed?

This sounds like one configuration supporting multiple channels. Short answer: Yes, it is possible, as long as you constrained which tables you wanted to access, and what degree of freedom you wanted to name the segments of the tables for sharing. You would have to decide on which side was in control: JMRI or the Arduino, how often were updates appropriate, and whether the naming conventions, and table amounts were known on power-up (that is statically) or subject to change (set dynamically by one controller). In case it is not obvious, this requires significantly more work. But in my case the real question is why would one want this? Both of these channels were designed as "bulk" data channels -- that is, lots of data exchanged quickly and easily. If you wanted a smaller amount in each direction, why not use 2 Pro Minis at $2 a piece for 2 x 18 points each way or 36 total? Or use 2 $7 Mega2560's at 2 x 68 points each way or 136 total? One would not be saving much of anything in a single combo, and certainly adding allot more effort for little to nothing to gain. Still, if you want to use these as a starting point, consider all the points I made above, which you will have to sort out.

 

Good luck and Have fun! 

Best regards,

Geoff Bunza