Fast clocks on the CNOR permanent layout

On our fixed layout we use Timetable & Train Order scheduling during operation sessions. This means we need to know what time it is. Because of the scaling of the distances, we use a fast clock (3:1) that is separate from real time. That means there are never enough clocks showing the right time.

There is a computer attached to the DCC system that powers the layout. There is a program on that computer that serves as the primary operations clock for the room. (We do run a NCE DCC system that has a fast clock that can be displayed on the throttles, but only the expensive ones. Most of our throttles are the cheaper ones without a display.) The main clock program exports the time by 2 mechanisms: one is a ZeroMQ based network broadcast service, the other is by a temporary file on the computer’s RAMdisk for local needs.

Interface to the fast clock control program

For a number of years we have displayed the fast clock data on 2 monitors at strategic places in the room that are driven by 2 of the 4 RaspberryPIs scattered around the layout. These monitors use the ZMQ service over the room’s LAN to get the time. While they are strategically located, they are never where you would want them to be.

There are relatively cheap LED matrix displays that are large and bright. They use a shift-register to push the display data in with a 3-wire interface (select, clock, & data). The intent of these displays is to chain them together to make long active signs. However if they are hooked up in parallel, you get N displays showing the same information at the same time.

Our layout room has a WiFi access point that ties into the LAN spanning the layout. One of the uses of this is as a bridge from member’s phones to the DCC system using an app to act as a throttle for a train. There are relatively cheap micro-controllers with integrated WiFi antennas based around the ESP8266 chip. Take one of these, add 3 LED panels, and fold in some power management and you have a high visibility clock on a stick.

The electronics consist of the displays, a D1 type ESP board, and a buck converter. The buck converter is used to drop the layout-wide 12V supply to a local 5V supply for the displays and as a source for the D1 board’s 3.3V regulator. (Do not think that a 7805 type regulator can handle a project like this. The current needed is a function of the total number of LEDs lit. For a normal “time like” display, about 0.5A
of current is consumed. A 7805 under that sort of load needs a heatsink. A buck converter will run cool and efficient. Don’t ask how I know…)

3D printed parts in OpenSCAD
Glued together and wired up (note the soon-to-fry 7805 regulator)

The frame is all 3D printed and is glued together with CA. The displays are mounted to the frames with some M3 cap screws. The frame is mounted on a short section of 3/4″ electrical conduit that is clamped to the wooden structure that holds up the backdrop.

The parts before final assembly
As installed

The processor talks to a simple web-service that is setup on the room’s computer.
That web service reads the current fast time in the RAM-disk file and formats it appropriately for the display. It also does some sanity checks around the clock information before sending anything to the display (does the file exist, is it being updated, etc.). The web-service is written in Perl and was just added to the already running web server on the computer. The display’s processor will contact this service every 5 seconds.

Total Page Visits: 684 - Today Page Visits: 1