Jump to content
 

Arduino, Day night lighting


Adamphillip
 Share

Recommended Posts

The cheap LED strips don't have a specified CRI, but 'warm white' usually is quite OK. It's also possible to combine a white strip with an RGB one and mix in just a little bit of yellow, or red or blue.

 

LED strips with a specified CRI can also be had, they are used for more critical applications, like photography. I got myself two different shades of white CRI specified strips for a photo booth I made. They usually are about 5 times more expensive at around $25 vs around $5.

Edited by RudyB
Link to post
Share on other sites

1 hour ago, RudyB said:

The cheap LED strips don't have a specified CRI, but 'warm white' usually is quite OK. It's also possible to combine a white strip with an RGB one and mix in just a little bit of yellow, or red or blue.

 

LED strips with a specified CRI can also be had, thay are used for more critical applications, like photogrphy. I got myself two different shades of white CRI specified strips for a photo booth I made. They usually are about 5 times more expensive at around $25 vs around $5.

InInteresting: have you a link to the CRI specified strips?

Link to post
Share on other sites

 

2 hours ago, RudyB said:

 

I got mine from Aliexpress. There are plenty to be found there:

 

https://www.aliexpress.com/wholesale?catId=0&SearchText=led+strip+cri95

 

Interesting - those do have a good CRI.

 

Controlling them is a complex thing: ultimately, one would want to control them from TrainController, iTrain or similar (I use TrainController) so that the lighting matches the time of day. This requires being able gradually to transition between different brightnesses and colour balances.

 

Digikeijs supply a DCC controlled unit that tries to do something like this: it will transition smoothly (by a timer) between about four set scenes with different balances of RGBW, but the LED strips supplied are CRI unspecified and therefore probably <80 CRI, which is very poor. Also, they are stated to be "warm white", which is wrong for simulating daylight: daylight is circa 5500k, whereas "warm white" is generally circa 2,700k (i.e., the colour temperature of a tungsten filament bulb).

 

I wondered about swapping the LED strips with those from Ali Express, but the wattage suggested that each 5m strip for each colour would take about 8A, which is more than the 6A for all four colour strips combined for each 5m segment on the Digikeijs module. This might be dealt with by using a resistor and omitting the useless green (and replacing red with orange), but I am not sure what sort of brightness that I might then get nor how well that the software would cope with the colours being meddled with in this way.

 

Another problem with the Digikiejs unit is that it will transition between fixed states by a timer: if I were to pause the layout near the beginning of the day/evening transition (e.g. at 5 p.m. in spring), on resuming, the layout would be put immediately into full evening light (e.g. 7.30 p.m. in spring), which would look silly.

 

Really, one does not need to have full RGB lighting for this function. Rather, what is needed is three different colour temperatures of white: one of 2000k - 2200k, one of 5000k - 5500k and one of 6500k - 7000k. These could then be combined in different intensities to model all of the various colour phases of daylight more accurately than using white plus colours.

 

How to control this from model railway control software so as to synchronise with the layout time, however, is another matter entirely, and not something to which I yet know the solution.

Link to post
Share on other sites

I have done this using JMRI on a laptop controlling MERG circuit boards. See the August/September/October 2017 Railway Modeller. Two photos are shown here. The other photo is our HO American layout lit purely with LED’s.

I haven't found any RGB LED’s capable of illuminating a Layout in Daylight mode at a reasonable price. White LED’s, yes. However this is a technology constantly changing. Beware of the current draw, at 12 volts this can be substantial.

More photos on out website   www.a19modelrailwayclub.org

DSC_7374mod.jpg

DSC_7383mod.jpg

DSC_9837.JPG

  • Like 2
Link to post
Share on other sites

29 minutes ago, Yardman said:

I have done this using JMRI on a laptop controlling MERG circuit boards. See the August/September/October 2017 Railway Modeller. Two photos are shown here. The other photo is our HO American layout lit purely with LED’s.

I haven't found any RGB LED’s capable of illuminating a Layout in Daylight mode at a reasonable price. White LED’s, yes. However this is a technology constantly changing. Beware of the current draw, at 12 volts this can be substantial.

More photos on out website   www.a19modelrailwayclub.org

DSC_7374mod.jpg

DSC_7383mod.jpg

DSC_9837.JPG

 

That does look good. How did you interface with the MERG cards so as to be able to control the lighting using these; and how (if at all) were you able to get a smooth transition between different modes?

Link to post
Share on other sites

Arduino DCC LED strip control (and hence also via Traincontroller, as shown in the video):

 

https://rudysmodelrailway.wordpress.com/2016/01/24/rgb-led-strip-control-with-arduino-and-dcc/

https://rudysmodelrailway.wordpress.com/2016/02/23/rgb-led-strip-control-via-dcc/

 

You could also have a look at www.arcomora.com and download free Arduino DCC decoder software. In the user manual it's shown how to connect the FET modules.

 

Build your own FET switches or get these very cheap ones:

https://www.aliexpress.com/wholesale?catId=0&SearchText=arduino+fet+module

Edited by RudyB
  • Like 1
  • Informative/Useful 1
Link to post
Share on other sites

1 hour ago, jamespetts said:

 

That does look good. How did you interface with the MERG cards so as to be able to control the lighting using these; and how (if at all) were you able to get a smooth transition between different modes?

I used Logix and JMRI's fast clock to set the time for transition and my own relay boards driven from MERG CanACC8 boards (these boards may not be current now as MERG has 2nd Gen Can system). The transition depends how many channels you are prepared to commit to the change. Mine has four, which is ok, but could be better. I fitted an electronic slug circuit to each LED output to even it out. On Alwinton I used dimming fluorescents for the daylight as at the time I couldn’t find any high intensity LED’s. This has changed now and the layout I’m currently building will use all LED’s. My RGB LED’s only do the night operation. My lighting transition starts by dimming the fluorescents while changing the RGB strips from white to red to give a sunset, then to blue for night operation. There is just enough illumination at night for crews to see what they are doing. Building, station, yard lamps, vehicle lamps and sound effects are also controlled by the same fast clock

At dawn, the sequence is reversed. This is the control panel with the fast clock.

DSC_9052-56FoStmod.jpg

Screenshot 2017-02-03 12.34.27.jpg

Link to post
Share on other sites

Interesting - using relays presumably means that there are distinct steps in the transition? Ideally, one would have some sort of variable output PWM that can create a smooth transition, but I am not sure how one would achieve this other than using the Digikeijs unit.

Link to post
Share on other sites

I've built an Arduino controlled lighting rig for Burntisland 1883 - the lighting rig had two shows (Sept 2019, Jan 2020). 

 

It uses addressable LED strips, plus some PWM controlled white LEDs (warm and cool, separately controlled).   I have a number of preset values saved in the Arduino (eg. early morning, midday, cloudy, evening), which consist of the RGB values along the strip, plus the PWM level for each of the white strips.    

To transition between different lighting levels, some simple maths in the Arduino starts from the starting RGB+PWM values, the final target values, and the number of steps (60).  The steps are done on a 1 second timed loop.   At each step, calculate the new value ((step/60 * (finalValue - startingValue) ) + startingValue) for each of the RGB+PWM values, and update the lighting output.  Go round the loop again...    At the end of the loops, copy the final state to the starting state values, and sit waiting for the next command to change.   Our system is currently push buttons into the Arduino to control what happens, plus a little LCD display to show what its up to.    

 

Net result is 60 seconds to transition from one lighting setup to another, and doesn't matter which starting state, it just moves smoothly to the final state over the minute.  Clearly could extend the transition time if wanted.  

 

Translating that to an accessory decoder (or similar) device, the inputs from the DCC system (or computer control software) is to just activate one accessory output (corresponding to a target lighting value), and the change starts happening.  

 

 

On the "to do" changes for the lighting rig are things that simulate a cloud moving over the layout.  That's rather more work as individual pixels on the strip will need changing to move the "dull" light of the could shadow along the layout.   To do it, I need access to the layout to test things, so its on hold.   Again, those could be a single effect triggered from an input. 

 

 

 

- Nigel

 

 

 

  • Like 1
Link to post
Share on other sites

1 minute ago, Nigelcliffe said:

I've built an Arduino controlled lighting rig for Burntisland 1883 - the lighting rig had two shows (Sept 2019, Jan 2020). 

 

It uses addressable LED strips, plus some PWM controlled white LEDs (warm and cool, separately controlled).   I have a number of preset values saved in the Arduino (eg. early morning, midday, cloudy, evening), which consist of the RGB values along the strip, plus the PWM level for each of the white strips.    

To transition between different lighting levels, some simple maths in the Arduino starts from the starting RGB+PWM values, the final target values, and the number of steps (60).  The steps are done on a 1 second timed loop.   At each step, calculate the new value ((step/60 * (finalValue - startingValue) ) + startingValue) for each of the RGB+PWM values, and update the lighting output.  Go round the loop again...    At the end of the loops, copy the final state to the starting state values, and sit waiting for the next command to change.   Our system is currently push buttons into the Arduino to control what happens, plus a little LCD display to show what its up to.    

 

Net result is 60 seconds to transition from one lighting setup to another, and doesn't matter which starting state, it just moves smoothly to the final state over the minute.  Clearly could extend the transition time if wanted.  

 

Translating that to an accessory decoder (or similar) device, the inputs from the DCC system (or computer control software) is to just activate one accessory output (corresponding to a target lighting value), and the change starts happening.  

 

 

On the "to do" changes for the lighting rig are things that simulate a cloud moving over the layout.  That's rather more work as individual pixels on the strip will need changing to move the "dull" light of the could shadow along the layout.   To do it, I need access to the layout to test things, so its on hold.   Again, those could be a single effect triggered from an input. 

 

 

 

- Nigel

 

 

 

 

Very interesting! I love the idea of simulating a small cloud moving accross the layout: that is very sophisticated.

 

I should be happy with basic non-addressable LEDs giving an overall brightness and white balance for the whole layout.

 

I wonder whether the Arduino could have an input configured to pause and resume a transition between two presets? This could then be activated by the layout control software whenever the layout time be paused or on quitting the software so as to preserve transitions and keep them to the correct time.

Link to post
Share on other sites

Some very interesting ideas. I shall have to wait until my wired broadband is working again to watch Rudy's videos (I am currently using a 5g mobile hotspot following an internet outage), but the use of MOSFETs to switch the LEDs using PWM is particularly interesting. I wonder whether MOSFETs would be sufficient to switch ~7m worth of strip?

 

I have been trying to think of the optimum way of achieving realistic layout lighting using an Arduino and LED strips on a TrainController controlled model railway. It may be some time before I am in a position to implement this for my railway, but it is useful to think of these things in the interim all the same.

 

As I indicated above, I strongly suspect that strips of different colour temperatures of white (something like 2000k, 5500k and 7000k), all with a high CRI value (>90) will produce a much better light than RGB LEDs, as this is much closer to how daylight actually works. Adding a pure red, green or blue to a single colour temperature of white will produce a chrominance histogram with a large spike near the value(s) of the single colour LEDs, rather than the smoother histogram that one is likely to get by combining different colour temperatures of white. What one then needs to do is simply modify their intensities so as to produce a realistic mix for different times of day and degrees of overcastness.

 

Ideally, one would want to have TrainController communicate to the Arduino the current layout time in real time so that it can update the lighting accordingly. However, a difficulty is that there is no easy way of communicating numerical data from TrainController to the Arduino. A possible way around this is to use multiple digital inputs on the Arduino, driven by outputs from a LocoIO device or similar, to make various numbers using binary. One could then write a script in TrainController that would run once a minute and set the various outputs from the LocoIO to the right pattern of states to represent the hours and minutes of the current time. One needs to be able to represent a total of 24 hours, so one would need a total of 5 bits for the hours channel (max. value: 31), and one would need a further 6 bits (max. value: 63) to represent the minutes channel, requiring 11 inputs in total. A further two bits (max. value: 3) could allow for an "overcastness" setting of between 0 and 3, 0 representing a cloudless sky and 3 representing thunderstorm conditions (and an overcastness setting of 3 in night time may well correspond to all LEDs being fully off). That would thus take a total of 13 inputs to represent the time of day and the degree of overcastness.

 

I omit a further 9 bit channel (max. value: 511) to represent the day of the year, which would be used to determine sunrise and sunset time, because my own layout, as with many, will be set at a particular time of year, but for a layout not set at a particular time of year, this may be a worthwhile addition. One would then want to program the Arduino to give accurate sunset/sunrise times for the particular latitude and longitude in question.

 

The Arduino could then be programmed to give a realistic level and balance of light for a number of points in the day for each degree of overcastness, and interpolate between those for each given minute of the day.

 

A TrainController script, independent from the timing script, would set the weather, which could be randomised according to vaguely realistic patterns, which is probably what I will do, or based on actual weather records for particular days for anyone wishing to set a layout based in a real place at a specific date in history.

 

Edit: What I am not sure of yet is whether any of the Arduinos have enough channels to allow for this sort of bit-bashing.

Edited by jamespetts
Link to post
Share on other sites

My approach - I'd make the Arduino "listen" to the commands.  Be they over LocoNet, or DCC instructions from an accessory bus.   There are lots of sketches and designs for interfacing the Arduino to either. 

 

Then the instructions can either be LocoNet messages (in principle, make up your own within the LocoNet specification, so long as you stay out of the reserved ones, or pick something that won't interfere with your real equipment), or DCC messages. 

As well as "on/off", there is a specification in DCC for advanced signals which take a numeric value:  I don't know if your hardware can generate those (some systems can, some can't).   With those, a compatible accessory decoder can receive a single value containing data: its used for operating a complex colour light signal (etc.), rather than having to send a whole pile of separate on/off messages for each aspect in the signal.    

Or for either LocoNet or DCC device, it could mimic a loco address (for a loco which doesn't really exist, except as the "lighting system"), and respond to throttle values if that's all you can generate from your computer.  That gives you around 240 values (speed and direction bits) before you add in function on/off values.   The loco mimic device would be my least favoured, but its an option. 

 

With either of the above approaches to hardware, you're not trying to convert complex data for brightness or time of day into a sequence of binary tap-tap-tap on multiple IO pins on the Arduino. 

 

 

Yes, the transistors (Mosfet in your text) can handle 7m.   Burntisland has vastly more than that (the layout is about 13m long, and there are, if I remember correctly, an average of eight strips running the length of it.  Half of them are on PWM output, half colour addressable).  

 

Work out these key things on your strips:

a)  the maximum recommended length of strip between 12v power feeds, and b) the current draw of that length of strip.  From that you have the max power going through the transistor for PWM switching.   Your transistor may need a heat sink (fit one, saves worrying!).  

And, you can parallel transistors on the same PWM output, so if one transistor is marginal; fit two, and split the strip into two, each with its own PWM.    

You can also stack parallel power supplies if those are inadequate for the lighting load, just be careful on connecting the 0v together (avoid power supplies with 3-pin mains connectors, as the earths can be linked to the 0v as well, which can get really messy, 2-pin is so much simpler).  The Burntisland Arduino boxes each have two 5A 12v power supplies for the LEDS on that box. 

 

 

 

Edited by Nigelcliffe
  • Like 1
Link to post
Share on other sites

Further thoughts on how to divide time to "each minute" plus degree of over-cast, etc.. into something which can be signalled by any DCC system....

 

Encoding and sending complex data: 

Assume you can find 256 spare DCC accessory addresses, and for this explanation, I'll assume they go from 1025 as the first of the block of addresses......

Split that group into two sets of 128 addresses.   

Two addresses from that group can be sent in sequence (eg. 1057(thrown) and 1232(thrown)).   On receipt by a decoder, they can be combined to give a 14 bit number  (high 7 bits = 1057-1024 = 33,  low 7 bits = 1232-1024 = 208,  total number 4432(decimal) ).    14 bits will cover all you're likely to really need.   

 

Looking at things another way: 

The PWM ranges for each strip are likely to be no more than 256.   So, for each individual strip you need to transmit an 8 bit (256 values) number.    If there are eight strips around your layout, you need 3 bits to identify the strip, and 8 bits for the level.  Total 11 bits.    But in practise, I'd expect far fewer real levels for the PWM value:  64 or 32 will cover the levels required, so only have a total of 8 or 9 bits to encode levels over eight LED strips.      Which in turn means either 256 (8 bit) or 512 (9 bit) accessory addresses for a single command, or 32 addresses (4bit plus 4bit) or 48 addresses (4 bit plus 5 bit) for combination commands split over two addresses.   

 

 

The problem will be decoding complex data in an Arduino.  There isn't a huge amount of memory in an Arduino (some models have more, such as the Mega, but its still small).   So, you can't have massive data structures.  

So, the coding of complex messages (above) could contain the lighting levels, and not require complex data manipulations at the Arduino end.    Which puts the complex stuff in a PC, where it can work out the date, time, weather conditions, etc., and come up with a lighting level. 

Directly sending the lighting level in a bit-encoding (for example, via the DCC accessory address) reduces calculations in the Arduino - the "new target lighting level" is the decoded DCC address (if outside the monitored range of addresses, it is ignored), and there just need to be a simple smoothing loop to change the PWM value from the current value to the target in small steps  (so if the PWM coding level is 64 levels, but the PWM control is 256 resolution, the software steps slowly over the intermediate values, giving a smooth transition in level).    

 

 

I think all the above could be done with tinkering around the DCC accessory decoder code that exists for Arduino.  Its essentially a DCC command monitor which responds to certain addresses, and changes the PWM output level when a particular address is seen. 

 

 

- Nigel

 

 

  • Like 1
Link to post
Share on other sites

36 minutes ago, Nigelcliffe said:

Further thoughts on how to divide time to "each minute" plus degree of over-cast, etc.. into something which can be signalled by any DCC system....

 

Encoding and sending complex data: 

Assume you can find 256 spare DCC accessory addresses, and for this explanation, I'll assume they go from 1025 as the first of the block of addresses......

Split that group into two sets of 128 addresses.   

Two addresses from that group can be sent in sequence (eg. 1057(thrown) and 1232(thrown)).   On receipt by a decoder, they can be combined to give a 14 bit number  (high 7 bits = 1057-1024 = 33,  low 7 bits = 1232-1024 = 208,  total number 4432(decimal) ).    14 bits will cover all you're likely to really need.   

 

Looking at things another way: 

The PWM ranges for each strip are likely to be no more than 256.   So, for each individual strip you need to transmit an 8 bit (256 values) number.    If there are eight strips around your layout, you need 3 bits to identify the strip, and 8 bits for the level.  Total 11 bits.    But in practise, I'd expect far fewer real levels for the PWM value:  64 or 32 will cover the levels required, so only have a total of 8 or 9 bits to encode levels over eight LED strips.      Which in turn means either 256 (8 bit) or 512 (9 bit) accessory addresses for a single command, or 32 addresses (4bit plus 4bit) or 48 addresses (4 bit plus 5 bit) for combination commands split over two addresses.   

 

 

The problem will be decoding complex data in an Arduino.  There isn't a huge amount of memory in an Arduino (some models have more, such as the Mega, but its still small).   So, you can't have massive data structures.  

So, the coding of complex messages (above) could contain the lighting levels, and not require complex data manipulations at the Arduino end.    Which puts the complex stuff in a PC, where it can work out the date, time, weather conditions, etc., and come up with a lighting level. 

Directly sending the lighting level in a bit-encoding (for example, via the DCC accessory address) reduces calculations in the Arduino - the "new target lighting level" is the decoded DCC address (if outside the monitored range of addresses, it is ignored), and there just need to be a simple smoothing loop to change the PWM value from the current value to the target in small steps  (so if the PWM coding level is 64 levels, but the PWM control is 256 resolution, the software steps slowly over the intermediate values, giving a smooth transition in level).    

 

 

I think all the above could be done with tinkering around the DCC accessory decoder code that exists for Arduino.  Its essentially a DCC command monitor which responds to certain addresses, and changes the PWM output level when a particular address is seen. 

 

 

- Nigel

 

 

 

Those are some very interesting and useful thoughts, especially as to the limitations of an Arduino and the actual number of steps available in the lighting strips, as well as the idea of doing all the calculations on the computer side.

 

I wonder whether a similar thing could be done by way of a LocoNet interface?

Link to post
Share on other sites

Yes, LocoNet is an option.   There are Arduino libraries for LocoNet devices, and a few people offering "shields" either as a kit of parts, or a design to implement (handful of components).   The libraries will give you a LocoIO, plus there are numerous other things published on various websites.   

 

You'll still need your own code to drive the PWM.   
Plus a data format to move  commands around.  The OPC_PEER_XFER part of the LocoNet Personal Edition specification may be one place to start, 8 bytes of data (64 bits) would seem to be more data in one message than you need.   

 

 

On the PWM Arduino stuff:  256 steps is the usual resolution of PWM outputs.  But, I doubt you'll really perceive all 256 steps.  Hence suggesting using fewer (for data transfer) and then sliding between them.   
That said, if you can get OPC_PEER_XFER working, you can put a 256 step resolution in one byte.  With seven bytes left for other information.   

 

 

 

- Nigel

  

 

  • Like 1
Link to post
Share on other sites

The Arduino sketch that can be downloaded from the links posted here before already has all that's needed. There are 6 PWM outputs, so it's possible to mix say 3 different colors of white to resemble day light, sunny, overcast, what ever, and then maybe an RGB strip to add just that little red or blue to better resemble mornings (add some red) or evenings/nights (add some blue).

 

The code uses presets which when selected send out any preconfigured combination of the 6 PWM outputs, ranging from 0-255. The fade time between presets is configurable. And then there also is a sequencer that steps through the presets with a wait time and a fade time per preset.

 

The presets and the sequencer can be switched in 3 ways:

- connecting a range of Arduino inputs to GND, to accommodate the use of hardware switches

- via the Arduino serial interface, sending PC keyboard commands

- Via DCC (a Command Station, maybe controlled via a program like Traincontroller) Every preset has a DCC address, the sequencer had one too, and the 6 individual PWM channels each have two DCC addresses, such that they can even be individually controlled, up or down, using 12 DCC momentary switches.

Edited by RudyB
  • Like 1
Link to post
Share on other sites

Thank you both. One thing that I wonder, however, is whether TrainController is capable of sending arbitrary LocoNet commands such as OPC_PEER_TRANSFER: I suspect that it is not. JMRI, I believe, can do this, but I think that TrainController is quite limited in its LocoNet implementation.

 

I am not sure whether there is a sensible way around this.

Link to post
Share on other sites

Sorry, can't help with TrainController.    
(Yes, JMRI can send (or receive and interpret) any LocoNet message - just need to know what bits/bytes you want in the message). 

 

The other method to send data discussed earlier, of encoding through a batch of turnout addresses, would still work, be it transmitted over LocoNet or a DCC bus.  The turnout commands would appear as LocoNet messages.  

 

- Nigel

  • Like 1
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...