This is a follow up on that proof-of-concept I made at CMRS about touch panels for the mainline.

I'd like to elaborate a few points, with some pros and cons, which I had been thinking about when I started the project. Upfront I want to make it clear I am not advocating for one solution or another. I am offering "food for thoughts", pros and cons, and matters of discussion. Some of the discussion involves industries or city names which are specific to CMRS’ layout. A map of it can be found in the link above.

1. Overall Thought on Project

First of all, I'm all for that project, first and foremost:

• The proposed touch panels would supplement existing control panels and not replace them.
• Usage would be voluntary. Members can just keep using the existing switch panels.
• It adds to the layout experience, does not replace existing stuff nor changes any behavior in the control of turnouts.

To extend:

• The scope is limited to mainline turnouts.
• As proposed, the goal is to have a quick overview of mainline turnouts. One glance of the panel should be enough to determine if the mainline is clear.
• On top of that, the panel allows for toggling mainline turnouts by touch from a central location. Someone starting at Engine Facility in Oakland could thus realign the whole mainline without having to walk to the other side of Oakland. Typically, what I've seen is the cross-over at the end of the Oakland yard left incorrect. Yes in theory everyone would realign mainline switches when they are done but we do not live in that perfect world.

2. Panels & Location

My belief is that is the most important point that merits discussion. The rest are mere technical details of implementation.

So let's discuss this.

Location height, high or low

• Suggestion is to mount panels on the high part of the fascia (e.g. next to the engine facility panel).
• From an ergonomic perspective, one needs to realize that using a touch panel is harder than using a physical switch panel, especially for users with mobility challenges. The arm's movement is inherently less precise when lifted; combined with the lack of a surface for resting the hand, it makes touch panels located higher harder to use for extended periods of time. Here we are looking at very short periods of use; however accuracy or lack thereof, should be taken into account.
• Locating a panel lower, say at hip level, makes it less tiring to use as the arm doesn't need to be lifted. However this creates two other problems.
• First, if the panel is placed vertically at hip level, it provides a weird and unnatural angle to view the panel and interact with it. That's the reason such lower panels are generally tilted, as can be seen on this layout (Sparks, Sacramento are good examples).
• Second, if the panel is placed vertical, there is a lot of potential for people brushing against and triggering touches by mistake.
• A panel that is not vertical and is tilted takes more real estate.
• Because one important goal is for the panel to be informational, placing it higher means easier visibility. A lower panel would be obscured by people standing in front.

However in the proposed location, a lower-placed panel would be in the way of the staging area below, not to mention this area by Oakland Engines Facility can quickly get crowded. Given the pros and cons elaborated above, placing the panel higher on the fascia makes more sense; however we should understand this may limit usability by some members.

Distance to the panels also matters. In the Oakland case, people would be just under that panel so distance is minimal. Surveying other potential parts of the layout would be needed to plan ahead with future potential panels locations upfront, e.g. sacramento, sparks, etc.

Size of Panels

I'll just point some pros and cons for the benefit of an open discussion:

• The panel we tried for the proof-of-concept experiment is a 32-inch panel.  That size seems abstract, it needs to be seen on location to be appreciated.
• In my personal belief, I thought it was too large for the desired area. The panels next to it, engine facility and Oakland, are probably in the 20-24 inch size (I did not measure, this is just a visual estimation so I can be fully wrong here).
• Having a larger panel sitting next to a smaller panel cognitively emphases the difference in size. One way to accommodate this is to separate them. For example the proposed Oakland touch panel could be located next to the wall rather than next to the existing switch panels.
• I believe the large 32-inch panel emanated from a desire to have the largest touch area possible (within reason of cost of course). However from an ergonomic point of view, I am not sold on this approach. A smaller panel of appropriate size should not necessarily be less precise due to arm mobility control.
• I'd generally advise against a one-size-fits-all approach. The proposal should encompass and plan ahead for other future locations such as the mainline from Sellby to the helix, and above level. In some places, maybe smaller panels would be more appropriate to not be in the way of the view.

Overall the size of the panel used should depend on the content to be displayed on them, the desired visibility (from where should the panel be seen to estimate turnout alignment) and how much it impacts the view of the layout.

One mistake I made in my proof-of-concept prototype is that I placed all the yards around the mainline, from Oakland to Hercules. In retrospect, that was too much information. The goal was to provide context as for the location being indicated on the panel, but that could be summarized more succinctly, consequently providing a more compact display of the mainline.

It is my unvalidated opinion that a smaller panel such as 20-24 inch would work well in Oakland; for other locations such as Sellby, Sacramento, Sparks, something even smaller in the 10-14 inch range might be just enough.

3. Hardware

For the proof-of-concept experiment, I was provided a touch-panel to work with. I chose an Intel Compute Stick to control it due to its low cost, ease of usage, and availability. The hardware I used cost $39 and only needs a small USB power supply (provided). Communication is over wifi with the central JMRI computer, thus removing any need for extra wiring except a nearby 120 V socket. This price I just listed does not account for the cost of the touch panel itself.

I'd like to point out a few alternatives and cost ranges to get some points of discussion. The approach above was based on having a hardware that is a touch + display panel, with a separate computer (albeit in its minimalist form) controlling the display. The other alternative to that is to use a computer + display that is already integrated as one. Luckily we have a few options here at adequate costs:

• For a screen size of 7 inch or 10 inch, nothing beats a tablet. I favor Android tablets as they are ubiquitous, and always getting cheaper.
• Android tablet 7 inch : cost range is around $50 per tablet these days. Amazon had a "fire sale" of their old Fire 7 tablets for $15 a piece last week, but that's unusual.
• Android tablet 10 inch : cost range is more in the $200 for something reasonable.
• For a screen size from 12 to 17 inch, I'd go for a laptop. I'm a big fan of older Lenovo laptops as they are easy to convert to Linux and ubiquitous surplus on ebay. Something like a 2013 model of the Lenovo Yoga S1 typically goes for $200-250 on ebay with a touch screen of 12.5".
• For a screen size above 17 inch, I'd use the current scheme of a separate touch screen with a compute stick to drive it.

Pros/cons arguments:

• Tablets and laptops need to be "hardened" in kiosk mode to prevent abuse from members or visitors. Meaning the tablet/laptop would boot, display a web page with the layout map, and the user would not be able to switch away from it... we're not creating a platform for visitors to play games here.
• A laptop booting linux can be made to be self-re-imaging at boot. A debian distro or similar can be stripped down to its bare minimum so that there's nothing else to run on the machine except the one app we need. It doesn't need any software updates.
• I treat these old Lenovo laptops as shells. For example at Randall I have 2 identical Lenovo T410 laptops. When one dies, I'll simply move the hard drive into the second one and drop it in place of the old one, without having anything to reinstall, thus having a turn-down time of a few minutes at most. Then I can just get a replacement off ebay because these surplus items are so easy to find.

One thing to finish here: the hardware/software used should be chosen with longevity in mind. Hardware is expected to fail sooner and later, and software deprecates. It's thus essential that part of the planning incorporate future-looking handling of both. E.g. do we have members who can and will know how to handle this when the system fails in 2+ years? Do we give them off-the-shelf replacement they can trivially find with documented procedures to reinstall them, or do they need to wonder in despair in front of an undocumented custom setup? In essence, it's not a viable solution for the club if only one member possesses the craft to understand and redo that solution.

4. Turnout Feedback

Now I need to bring this back in because it's an important aspect of this system. When we did the proof-of-concept, we all understood the implications, so it's worth pointing them out.

That's going to be technical. I'll try my best to simplify or over-simplify it so please bear with me.

What is the problem:  Let's say we have turnout #200 cross-over on the mainline. There's a button on the Oakland panel to set it to normal or reverse. All these buttons are 3-position switches: push up for one direction, pull down for the other direction, neutral in the middle. This physically moves the turnout by direct wiring to the Wabbit. However the DCC system was never involved here.

On the other side we have the JMRI computer that talks to the DCC system. The DCC bus is connected to that Hare or Wabbit that can control the same turnout. From JMRI (e.g. WiThrottle / Engine Driver app on cell phone), we can throw that turnout. This gives a signal to the DCC command station which sends it to the Wabbit which then throws the turnout.

There is an inconsistency when the push-buttons are not in sync with the DCC system. Here's a scenario:

• Member 1 uses WiThrottle or the Touch Panel to throw turnout 200 in Reverse position. The DCC system and JMRI are involved and they both know that the turnout is in Reverse. The touch screen shows the turnout in reverse and this matches the physical state of the turnout.
• Member 2 uses the physical switch panel to throw turnout 200 in Normal position. The DCC system and JMRI are not involved and know nothing about. The touch screen shows the turnout in reverse and this does noy match the physical state of the turnout.

What is needed here is a way to tell the DCC system "hey that button was pushed, and the turnout has changed now". This is called Turnout Feedback.

There are multiple ways to make this happen, and my point is that this is an important part of the proposal that should be discussed from a technical point of view.

Let me elaborate on a few technical ways to solve this:

• The "obvious" NCE way is to use the Wabbit output pins, and connect them to NCE AIU01 sensor cards, which are then connected to the NCE cab bus. JMRI needs to be set to configure sensor monitoring for each turnout.
• Cost: $50 per NCE AIU01 card, which has 14 inputs (thus in theory can monitor 14 turnouts, or 7 if you want precise thrown/closed monitoring).
• Hidden cost: a lot of wiring from each Wabbit to the NCE AIU01 + connecting the AIU on the NCE Cab Bus.
• Hidden cost: a lot of manual configuration in JMRI to match the AIU sensor bits to the proper turnouts.
• Main drawback: Polling time from the NCE AIU on the NCE AIU cab bus is appalling. Feedback will appear within 2-3 seconds. That means there's a time gap between when a turnout is changed to when it is shown as such on the touch panel.
• The Digitrax way is somewhat similar. Since the layout already has a a Digitrax PR3 and an LocoNet, there are similar ways to do that. The Wabbit doc has all the gory details so not going over the details.
• Cost is similar to the NCE case since it requires some extra sensor card.
• Still needs JMRI configuration to match sensors to each turnout.
• Still needs a lot of wiring from each Wabbit to the digitrax sensor card.
• The LocoNet bus is way more robust and polling time is < 1 second IIRC. From memory, I haven't played with that in a while.
• I’m being told: Use a Digitrax SEC8 and DS64 directly instead of the Wabbit, and this already provides turnout feedback to JMRI via LocoNet.
• The "less obvious" way is a roll-your-own Arduino solution, which I gave some thought and experimented it a bit at home:
• Use an ESP32 or similar (~$20 or less) that has wifi. Depending on the arduino or ESP we can expect 10-20 digital inputs to monitor. They need to be wired to the Wabbits and can be used to send orders to JMRI. Now the difference here is that they do NOT need to be used as sensors. Using the JMRI JSON API, the ESP32 can be set to simulate throwing the turnout. So for example a user pushes a fascia button, the Wabbit closes the turnout, the arduino detects it and then sends a similar order to JMRI to throw the turnout. JMRI will thus know the state of the turnout. It will then try to relay that to the DCC system which will send the same order back to the Wabbit, thus keeping everything in sync.
• Use an Arduino Nano or similar with an RS485 interface ($5 or so). Again we can monitor about 15-19 inputs on this, and we can program it to act as an NCE cab device that would simulate a turnout being thrown. The idea is to close the loop but this time we tell the NCE command station to throw the turnout. It will relay that to the Wabbit and to the JMRI server.

Both solutions above require a lot of wiring from the individual Wabbit back to a central Arduino. Can we dispense with that effort? Well actually yes, we can. We just need to think a bit outside of the box. Well we were doing that but let's go further. We have a central location for all these switches, the switch panel itself. All the switches control the Wabbit. We don't need to go from the switches to the wabbit back to a central arduino when we can go directly from the switches directly to the arduino which can then send an order to JMRI which sends orders to the DCC command station and in turn back to the Wabbit. So in essence, rewire the panel to not act on the Wabbit in the first place, and this closes the feedback loop properly. The draw side of this is that it requires JMRI to be functional and set up for the corresponding turnouts, but that's a basic sine qua non requirement for this whole project anyway.

5. Beyond Mainline Turnouts: Block Occupancy

One thing worth mentioning here is that such a display could also easily integrate block occupancy to indicate where trains are located on the mainline, provided the layout is wired for it. In places where block occupancy sensors will be installed for signaling, that information can be provided on the touch panel as well. The JMRI server will have all the information and the panels could indicate both occupied blocks and signals aspects.

It's my belief that for places where traditional wired current-based block detection is not installed, block occupancy can be detected by other means, but this is out of the topic of this discussion so I won't go into details.

Voila. Just a few quick thoughts on this whole project.

---