Room lighting with RemoteSign

After 6 years, I decided to upgrade my layout room lighting so that I could also control it from the layout software.

I wanted to be able to dim the room lighting automatically so that sunrise and sunset sequences could be done smoothly. Until now I had to manually adjust the dimmers of three lighting circuits which was somewhat tricky.

Purchasing digitally controlled lighting would have been prohibitively expensive and furthermore I was not prepared to remove the existing LED strips from the ceiling above the layout. I decided to implement digital access to the lighting by adding electronics where the existing lights obtained their power and were controlled by the dimmers.

I have four circuits:
  • Warm white ceiling lights - drawing about 3.5 Amps at full power.
  • Cool white ceiling lights - drawing about 5 Amps at full power.
  • Mountain backdrop lights  - drawing about 2.7 Amps at full power.
  • Hidden area lighting  - on/off - which draws about 3 Amps.
I decided to use an ESP8266 NodeMCU processor to control the lights. This is a small processor about 1" x 2" in size and can be bought for less than $5. It is capable of connecting to WiFi and has a number of outputs that can be used for the lighting, but these outputs are only 3.3V and only capable of 12mA, so those logical level outputs had to be fed to some components that amplify the signals and drive the high current load of all the lights.

I also found some technology called Blynk which includes the ability to easily create an app that runs on mobile devices and can 'talk' to the ESP8266, thus providing a handy visual interface to control the lights. Here is what my Blynk app for the lights looks like:

  • The ceiling lights and hidden area light can be turned on and off with single button presses. 
  • Each of the dimmable light circuits also have a slider that controls their brightness from 0% to 100%.
  • At the upper right corner I can set a transition time, so for example, if I want the lights to go to 12% over a period of 25 seconds, I set the transition time to 25 and then set the sliders to 12%
  • In addition to the direct controls there are also some preset scenes that can easily be selected. These also honor the transition time.
  • I was also able to create a lightning effect that uses the cool white lighting circuit and can be activated at any time using the 'Blitzen' button. This is more effective than what I could achieve using a Hue light.
  • Below all that (out of sight above) is a button to initiate a firmware update over the air and to show network connectivity strength.
Blynk also has a handy restful HTTP API - that means it is very easy to link a voice command to the Google Assistant to trigger virtual pins - So I can command my lightning effect by saying "OK Google, Blitzen", or "Turn ceiling lights on", etc.

Since the layout lights also have a main switch that energizes the 12V 30A power supply it uses, I made the ESP8266 switch on one set of lights right away when it starts up. This ensures that when I switch the lights on I get light right away. Once it has connected to WiFi (which can take a few seconds) it also turns on the other set of ceiling lights.

There is also a small switch that will toggle the hidden area lights on or off, removing any need to have the phone app or external computer software running.

In order for my layout software to access the functionality of the ESP8266 I decided to extend the RemoteSign API that my layout software already understood. This enabled me to create very efficient direct control of the lights from the layout software without having to go through other layers of software such as MQTT. It also enabled the ability of such a device to pass capability information to the layout software.

So much for the software side, the tricky part for me was getting the electronics right. I had to learn a lot about MOSFETs, MOSFET drivers and how seemingly simple circuits are not so simple in a radio frequency electrical environment that comes with the pulse width dimming (PWD) of lots of power.

MOSFETs take a logic level signal and allow a much heavier current to pass when the logic signal is 'high'. So, for example, when the software in the ESP8266 causes an output pin to pulse on and off so that it is on  60%, a MOSFET can take that signal and allow a larger current to be on 60% of the time.

I ordered some FQP30N06LE MOSFETs and connected up a test circuit. It worked, but only sort of. It would drive an LED, but when I connected up a reel of LED lights (5m long) I could only get 7 Volts out of the MOSFET. It turns out that yes the components I ordered could switch very small currents at 3.3V but to do anything useful, I would need to add a MOSFET driver chip to apply a bigger voltage to the gate of the MOSFET. I ordered some TC4427 chips and some little capacitors that they need and connected them up as follows:

which, when connected up on a breadboard, looked like this:

That setup worked perfectly. I could now set any circuit to any brightness and the whole LED strip would respond as designed. All I had to do then was make four such circuits and solder them all together.

Since the MOSFETs have to drive a fairly large current (up to 5 Amps) I decided to place some heat sinks on them to dissipate heat. The current that is supplied to each of these MOSFETs is the negative side of the 12V and they switch that current to what is called the drain pin. The wires carrying those large currents were soldered directly to the pins and do not rely on the traces of the solderable breadboard I used for the other wiring. They are the large white wires visible below.

Since the heat sinks have a pin that goes into the same trace as the drain pin I decided not to attempt to electrically insulate the heat sink from each MOSFET. When soldering them in place I used some cardboard as a spacer to keep the heat sinks off the circuit board.

The screw terminal in the foreground was for two of the input signals, I decided later to wire a ribbon cable to the board directly and so I removed the screw terminals.

I used an old ribbon cable to make the connections between the ESP8266 and the circuit board

Once everything was connected up, I found the ESP8266 would not get onto the network. Since some pins are sensitive to being loaded when these things boot up I did some tests and decided that one pin I was using was preventing it from booting so I used a different pin. Satisfied that all was OK, I then ripped out the old dimmers and installed the new electronics under the layout.

Once all in place, it would no longer get onto the wifi network again! I pulled the ESP out and experimented with it upstairs. I substituted another device and that one worked fine so I decided that the different brands just work differently.

I was able to easily add the networked device to my layout software as a RemoteSign client and add the commands to dim the lights for my sunset and sunrise routines. I added the lightning event to my thunderstorm too, and it is much improved over the old flashing Hue light.

I tested the start up process and it all worked as designed. Next day, it would not get onto the network again.... it seems that the problem I ran into after assembling, and after the initial installation is the same one that is simply erratic, and switching pins and the device never solved the problem. If I power up the ESP8266 after the 12V power supply it seems to work. I intend installing a buck converter to power the ESP8266 with 5V converted form the 12V so perhaps that may solve the problem if it is power related. I will update here when I get to the bottom of that issue.

Update 2019-01-19
I placed a metal barrier between the 12V power supply and the ESP8266 and it seems to improve its ability to join the network, so I suspect some RF interference, but net yet sure. Buck converters arrive today.

The heat sinks do not get hot at all, I ran all the lights at full brightness for about 30 minutes and they were just above room temperature.

I really like the nice transitions that it achieves...


Here is what I used:
  • 1x ESP8266 NodeMCU
  • Blynk 
  • 1x Solderable Breadboard Proto Board
  • 4x FQP30N06LE MOSFETs
  • 2x TC4427 MOSFET drivers
  • 2x µ1F film capacitors
  • 2x µ0.1F ceramic capacitors
  • 2x 10Ω resistors
  • 4x 10KΩ resistors
  • 1x switch (reset button from an old PC)
  • Ribbon cable (from the old PC parts box)
  • 1x Euro connector strip


I would like to thank the numerous people on the various fora that helped with my noob questions at various steps along the way, and Debbie for putting up with the excitement of working milestones!


For a handfull of dollars, it is possible to create a very flexible system for lighting. The lighting can be controlled in multiple ways:
  • From the Blynk app
  • From the Google Assistant
  • From my layout software using RemoteSign commands
  • From a physical push button


Dr Sp L 60

As much as possible (and practical) I have adopted the look and feel of the prototype control desk as used in Germany for decades. They are called "Drucktaste Spurplanstellwerk" and there were two main manufacturers, Siemens and Lorenz. Siemens used rectangular shapes tiles, and Lorenz used square tiles. Since I had already been using a square matrix to lay my track diagram out, I decided to emulate the Lorenz version. This type of control desk is known as the SpDrL60.


(Updated) updated user interface

A friend, Boyd, has made himself a control desk that uses the push button approach to set tracks for trains to enter and leave his Swiss stations. The control desk is a set of push buttons which are connected to sensor inputs, allowing software to do all the grunt work of allocating and interlocking routes.

I configured my software according to how his buttons have been allocated, and in doing so, I decided to spruce up the user interface of my layout control software. (Updated again October 2018.)

Here is the result:

I looked up how such control desks look in Europe and settled on emulating the Sp Dr L 60 desk as used in Germany for many decades, as much as is possible and practical. I changed the old style check boxes into controls that use the appropriate background colors. Turnout positions are shown in yellow.

In the image above, the thick black lines represent trains. One route (indicated in white) has been set from the track he calls 33 Ost 4 to 24 MGB helix. The route was set by pressing the button on the desk at track 33 and while holding that, pressing the button at track 24. Since the track route was clear, all the turnout commands were sent out and the track marked as reserved for the train to depart.

I generate the matrix of squares that are used for the desk each time the software loads so that they simulate the different levels of fading and wear as seen in the prototype. Buttons and counters can be aligned with the grid of tiles that make up the desk.

The trains on Boyd's layout are run manually by humans and he expects the operators to set the signals appropriately before driving trains about, so what my software does in his case, is monitor occupancy and take that into account when setting routes when requested by the dual button actuations.

Part of the sprucing up of the user interface included the ability to add images anywhere as well as adding axle counters

Since my layout is also actually run by the software, I am able to display the timetable names of the trains that occupy tracks etc. in the style used in Germany by the Sp Dr L 60. A name in red indicates that the train is present and when in white it indicates that the tracks are reserved for that train, which is yet to arrive. In the example below, the train with timetable name "Baden" has been set on a route from the hidden station up to Wilsnack Hbf. where it will arrive at Platform 5 - and its name is shown in white there. Another train, with timetable name "GZ Trafo" is running out of the hidden station track 8 and will travel all around the layout and arrive in track 8 again.

When "GZ Trafo" passes the brown axle counter, the exact number of axles in the train will be added to the counter!

Control software and user interface design is © Copyright Dale Schultz 2018


Intellibox turnout speeds and special option 13

XTrnt response codes
I turned on the logging I have in my software and noticed that I was getting a lot of responses from my Intellibox warning me that the turnout buffer was 75% full, and also numerous rejections of turnout commands when the buffer was completely full. When this happens, my software throws the failed commands back into its own command queue so that it eventually gets accepted, so once the Intellibox buffer fills up, I get many rejections until the buffer is no longer full.


Loco going backwards only

I was running my Märklin 3511 „Schöne Württembergerin“ (which has done just over 600 scale km) and it was running beautifully as ever.

I reversed the train a bit and then I wanted to make it go forwards again, but instead,
it only went backwards! No amount of changing direction would make it go forwards. Even when its lights function was switched on, and could thus show that the locomotive was meant to be moving forwards, it went backwards instead.


LocoNet on Intellibox I

For some time I have had some concern about my digital controller failing. The hardware dates from around 1996. It is the first version of the Intellibox from Uhlenbrock. My concern is that if it fails, the new devices no longer support the command protocol that my software uses, so I would either have to source another Intellibox, or rewrite all the interface code.

Uhlenbrock devices now support LocoNet (from DigiTrax). Indeed even the Intellibox I supports a LocoNet interface from version 1.55 onwards. The Intellibox II uses Loconet exclusively.

So I decided to take a look at Loconet to see how much work it would be to redo the interface.


Ultrasonic humidifier as factory smoke generator

I was in a doctor's office when I noticed a small desktop humidifier that is typically used for burning scented oils. I realized that it would make a perfect smoke generator for a smoke stack on a train layout. I found that these units are not very expensive and one need not place any scented oils in them. They produce a small amount of water vapor that is visible but is insufficient to wet anything nearby.

I set about converting one so that I could switch it on and off from the layout software and also install it in such a way that I could easily add (distilled) water as needed. I am pleased with the result: