DMX shield - stage lighting control

Hello, I have recently bought the TinkerKit DMX shield and have been using it with the SimpleDmx library. Making a stage light fade from Blue to Red, according to the example on the page has been easy. (

This is the code used:

#include <DmxSimple.h>

void setup(){

void loop(){
for (int brightness=0; brightness<=255; brightness++){
DmxSimple.write(1, brightness); // red on channel 1
DmxSimple.write(2, 0); // green on channel 2
DmxSimple.write(3, 255-brightness); // blue on channel 3

Let’s say I want one stage light to fade from Blue to Red within 10 seconds. I have tried changing the delay(10) value to a higher value, but it’s purpose is to make the fade smooth, so rising it’s value didn’t work. I have also tried finding documentation or a solution on the net, but only found questions like mine which remained unanswered. I have also tried to use the common millis() function, but the resoult was that the transition from B-R still lasted the default ~5 seconds, and then mantained the Red until the 10th second, when the loop started from start again.

Does anyone have an idea how I could make for example the effect of fade (from 0 (0%) blue to 255(100%) blue last for the length of x time? Like 10 seconds?

Thank you in advance

I have tried changing the delay(10) value to a higher value, but it's purpose is to make the fade smooth, so rising it's value didn't work.

That should have worked. What happened when you changed the delay time?

10 x 255 = 2550mS or about 2.5 Seconds for the full cycle. A delay of 44mS should take 10 seconds to count to 255.

The time delay doesn't make it smooth, but a shorter delay may appear more smooth to the the human eye. The smoothness depends on the number of steps (0-255) and there may be a bigger visual difference between 1 & 2 than between 254 & 255.

The delay probably serves another purpose... There is a limit to how-fast you can send serial data and if your loop runs too fast it won't work properly. (I don't know exactly-what will happen.)

Well, when I increased the delay value, it (like it can be told from the code) just made that current brightness value stay on for a longer time. This resulted in making the switch from brightness value of 255-254-253-and so on more visible to the human eye. The visual result was unsatisfying, eg. “blocky”, instead of the transition of going smoothly. Yes, the delay is used, from what I’ve read, to slow down ramping(being a beginner I do not know how to explain what ramping is). I hope I have made myself clearer now? Since English is not my main language, explaining things I have trouble explaining in my own language without waving my hands gets even more difficult, so I apologize in advance for further misleading :slight_smile:

I’ll thank you now because what you’ve said in your post gave me an idea of why delay wasn’t working how I thought it would, and what could help instead. The thing that I changed was the “brightness++” value. Instead of increasing it with the value of one(brightness++ equals to writing brightness +=1, no?), I tried replacing it with 2, 3, 0.5 etc. (making the brightness FLOAT instead of int). This resulted in the following, depending on the value used:

  • if “brightness” is incremented with a number > 1 ( brightness+=2; or brightness+=2; or brightness+=2.5; ), the fade/scene/call-it-whatever-you-like, runs faster but the smoothness of the transition stays.
  • if “brightness” is incremented with a number < 1 ( brightness+=0.9; or brightness+=0.5; … ) the fade/scene/call-it-whatever-you-like, runs slower but the smoothness of the transition stays. I guess it is logical? Although working at high speed, it takes longer for a loop to execute when it goes from 0-255 in steps of 0.1 than it does at steps of 1.

+=1 takes approx. 5 sec, +=2 takes approx. 3sec and so on… Tests made with a stopwatch (oh the shame beginners put themselves through)

This is working for me now, but I have a strong feeling it might cause problems on other scenes, so I’ll keep testing and researching. I suppose the real solution is to play with both the increment value and delay (which is better to replace with millis()). I’ll post results in case someone else runs in with the same problem.