Who wants a cheap, simple, Arduino-based LED controller?

Yeah, what I did was change the time to 2 hours earlier to still have the lights on after 12am

Also a manual setting could be nice. Lets say you just want to turn on the lights at a random hour

Also when entering new values it will go to the main screen interrupting what you were doing.

Still a NICE controller and makes the job very well. I love it

Yeah it's a great starting point.

I thought about the whole setting the time ahead but to me that's a hack... so what I've done in the mean time is actually hard-code my start time and photoperiod instead of storing it in the EEPROM... still a hack but at least it displays the proper time.. LOL

I'm a software guy by trade so now that I've got a working model Im going to be toying with the software aspect heavily. Im not super familiar with how the hardware interacts with software but Im learning quickly ;)

To that end, It appears that one of two things is happening in the unintended menu exiting: The menu exit occurs when the menu button increments past 19/gets set back to 1 , or when the timer on the LCD backlight goes past its inactivity limit.

to make the first happen, I think something would have to be overwriting the value for number of times menu was pushed thereby triggering the logic to reset it to 1, or something is wrong with the backlight inactivity logic.. My brain is a bit mushy to look at all those variables, functions, and what they mean right now since Im learning arduino as I go. I'm not super-concerned by the menu bug but I will attempt to fix it.

I agree with you Sammy on the manual-override on/off. I can have something coded for this tomorrow if I get some spare time. I will either add an override menu or more likely just use the select button for the moment. It's not optimal using that button but it can be moved as development continues. The functionality is pretty much necessary.
 
nice XSiVE. I'm a dumb when it comes to programing this or even understanding the codes. That's exactly why I wanted this controller, cause my previous Arduino wasn't cutting it. If you ever got to fix those I'd like to have them installed in my controller. I still don't have the cable to connect it to my USB though
 
So Ive got the manual override functionality set to go into the first menu point(#2) I'll figure a way to post the changes to the sketch tomorrow.

To get in, hit menu once, change settings using + and -
Its settings are:
"Timer" -- No overrides at all, use timer/dimmer functionality
"0%" -- All channels at 0% until changed or unit power reset
"100%" -- All channels at 100% until changed or unit power reset.

I did this by adding two globals(yuck) to store the override menu position, and whether it's enabled or not, a menu to set the position, and wrapped the dimming function calls in a conditional based on whether override is active.
 
Nice to see some progress with the code!

The menu ovveride I will concede as a bug. I had meant to implement such that it "timed out" after X amount of seconds and returned to the default menu (the screen displaying time and current power levels). But, I only checked for presses of the menu button, while I should have checked for presses of any button.

The midnight bug (where it doesn't let you keep a photoperiod that spans midnight) was just something I had never considered!

I'd also like to see the whole menu structure moved into an array instead of hard coded the way it currently is, at some point in the future.

Another direction would be to add one-wire code to read a single one-wire temp probe. Then, people could spend about $6 on a probe and some wire, and have temperature displayed on their unit - or, even program it to alter power levels for the LEDs based on temp (i.e. turn the lights off if the tank got too hot).
 
The midnight bug (where it doesn't let you keep a photoperiod that spans midnight) was just something I had never considered!
This must be the folks with the corals from the Australia. I really think some people go to too much trouble to emulate their natural environment :)
 
:lol:

I dunno. With three little kids running around, a job that leaves me drained, and the health issues we're dealing with right now, there'd be no way I'd ever have the energy to be awake at midnight to look at a fish tank!

I guess the practical "for the masses" reason to fix the bug would be so people can use the controller to run moonlights or 'fuge lights on an opposite schedule. Refugium lights don't exactly need the precise control, but it would be cool to do a moonlight that changed intensity from day to day to mimic real moon phases.
 
Nice to see some progress with the code!

The menu ovveride I will concede as a bug. I had meant to implement such that it "timed out" after X amount of seconds and returned to the default menu (the screen displaying time and current power levels). But, I only checked for presses of the menu button, while I should have checked for presses of any button.

I dont have my board with me at work, but I think thats a quick fix of adding:
Code:
bklTime = millis();
to each button press conditional area in every menu, though it seems redundant and could be done more cleanly.. im not in code-mode yet this morning. ;)

der_wille_zur_macht said:
The midnight bug (where it doesn't let you keep a photoperiod that spans midnight) was just something I had never considered!

With hard-coding the photoperiods the lighting spanning midnight works just fine, the UI just doesn't know how to interpret it on mine, should be easily fixed by modifying the display routine since mine "shuts off" at 24:30 :lol:

As for using the buttons to span time periods past midnight, the easy way out is to have the UI set a photoperiod in minutes instead of setting an "off time", but that's pretty clumsy and an end-time is realistically a more user-friendly approach. I hate dealing with time in programming because of the damn mod(24) all the time... makes my brain ache but I'll get it working... Ive got some locals that already want one of these and I think they will need a pretty friendly UI.

anyway, on to the manual override code:

In variable definition area:
Code:
//create manual override variables
boolean override = false;
byte overmenu = 0;

inside void loop(), add the "if(!override){" and "}" around the set output block.
Code:
//set outputs
  if(!override){
  oneVal = setLed(minCounter, oneLed, oneStartMins, onePhotoPeriod, oneFadeDuration, oneMax);
  twoVal = setLed(minCounter, twoLed, twoStartMins, twoPhotoPeriod, twoFadeDuration, twoMax);
  threeVal = setLed(minCounter, threeLed, threeStartMins, threePhotoPeriod, threeFadeDuration, threeMax);
  fourVal = setLed(minCounter, fourLed, fourStartMins, fourPhotoPeriod, fourFadeDuration, fourMax);
 }

you will also need to expand the menu count (yeah I see now how an array will be nice here), the old value was 19
Code:
if(menuCount < 20)

and then finally, add a new menu. I added mine at menu index #2 and then re-numbered all menus following, as i figure a manual override is used more frequently than changing your dimming timings.
Code:
if(menuCount == 2){
    //Manual Override Menu
    lcd.setCursor(0,0);
    lcd.print("Override Menu");
    lcd.setCursor(0,1);
    lcd.print("All: ");
    
    if(overmenu == 0){
      lcd.print("Timer");
      override = false;}
    if(overmenu == 1){
      lcd.print("0%   ");
      analogWrite(oneLed,0);
      analogWrite(twoLed,0);
      analogWrite(threeLed,0);
      analogWrite(fourLed,0);
      override = true;}
      if(overmenu == 2){
      lcd.print("100% ");
      analogWrite(oneLed,255);
      analogWrite(twoLed,255);
      analogWrite(threeLed,255);
      analogWrite(fourLed,255);
      override = true;}
      
    if(plus.uniquePress() && overmenu < 2){
      overmenu++;
      
    }
    if(minus.uniquePress() && overmenu > 0){
      overmenu--;
    }
  }

If you guys see any problems with this please let me know! Toying with this is a blast.
 
as for the midnight thing, it's more the fact that many people like myself run their lights a few hours behind (or completely opposite) normal daylight. My tank is in the basement so I can hang out down there well after the sun goes down...

plus electricity is more expensive in the daytime so why not shift that a little bit ;)
 
Don't bother using that code posted, I've got a much better version in the pipe with bug fixes including the midnight issue and additional timer-override functionality.

Newest revision has overrides as I listed before but the way it's executed is cleaner, also an override all-dim function where you enter the menu and just use the + and - to manually adjust the currently active dim level (not tied to the timer).

Once I get it to a point where I think it's tidy enough for release I'll get dwzm to give me permission to check out the code from google code and update it, or more likely put this version up there side-by-side with the basic software.
 
I was just going to offer access to google code so you could upload your fixes. As far as I'm concerned there's no reason to fork, we can consider your code the next version of the base firmware.
 
Good catch. Substitute would be: http://www.mouser.com/ProductDetail...=sGAEpiMZZMtsLRyDR9nM17T5O64KcyU3/lNtzYzlEag=

Better yet, no one can have enough headers. moderndevice.com has 5 packs of 40 pin breakaway headers for a good price. Make sure not to get the "extended" ones. They won't plug all the way in.

Aaaand...this one's out of stock until Jan 24th. :sad2:

I think I may just visit Fry's to find one. :idea:

The rest of my order is in stock, but they're holding it at the moment because of that. :mad2:
 
Zig Zag

Zig Zag

Maybe it is silly question but if you don't ask you never find out.If you have led driver and using Cree whites and blues with the same configuration why connect the led all whit on driver and all blue on another driver (zig-zag) is there a purpose doing it or just for the look
Im about solder mine together and wonna find out the reason for all whites on driver and all blues on different driver.I have MEAN WELL | LPC-35-700 so I check before on the forum if I can run whites and blues at the same driver.In my opinion looks better and easier to run them white and blues together on the same driver of course Im talking right know about MEAN WELL | LPC-35-700 So is the rule about connecting them or just a look
 
Maybe it is silly question but if you don't ask you never find out.If you have led driver and using Cree whites and blues with the same configuration why connect the led all whit on driver and all blue on another driver (zig-zag) is there a purpose doing it or just for the look
Im about solder mine together and wonna find out the reason for all whites on driver and all blues on different driver.I have MEAN WELL | LPC-35-700 so I check before on the forum if I can run whites and blues at the same driver.In my opinion looks better and easier to run them white and blues together on the same driver of course Im talking right know about MEAN WELL | LPC-35-700 So is the rule about connecting them or just a look

If you're not going to do any dimming and plan on running them at the same current then you can mix them up.

But the reason for running them on different strings is to allow to dim one or the other to get the color balance you want.
 
Aaaand...this one's out of stock until Jan 24th. :sad2:

I think I may just visit Fry's to find one. :idea:

The rest of my order is in stock, but they're holding it at the moment because of that. :mad2:

well give them a call and see if you can modify the order to get it sooner then order the others from modern device.
 
If you're not going to do any dimming and plan on running them at the same current then you can mix them up.

But the reason for running them on different strings is to allow to dim one or the other to get the color balance you want.

Also, if you're using plug-in appliance timers to turn the LEDs on and off, having the two colors on separate drivers allows you to run the blues longer, mimicing the standard habit in this hobby of running actinics before/after main lighting to create dawn/dusk. Of course, with LEDs that are controllable, this kind of becomes a moot point - but with non-controllable drivers, it's nice.

They've got plenty of others.

I'm going to give them a call today and switch it with 538-22-28-4250.

That part will work but it's WAY expensive compared to getting a bag of headers from modern device (or even sparkfun) and since you pretty much HAVE to get a bootloaded AVR from a place like modern device anyways, you might as well stock up on headers at the same time.
 
That part will work but it's WAY expensive compared to getting a bag of headers from modern device (or even sparkfun) and since you pretty much HAVE to get a bootloaded AVR from a place like modern device anyways, you might as well stock up on headers at the same time.

yeah...but my order from modern device is already here. :lol2:

Pretty sure I saw headers yesterday at Frys...think I'll just have them remove them from this order and pick up the headers I need there.
 
Fry's does has them in a 4 or 6 pack of 40 pin strips. Good luck finding them though. They have a fair number of useful things, but it's mixed in with tons of crap you will never use ALL OVER THE PLACE! I had to go to 3 very different sections just to some pots I needed.
 
I just put together my second board (the first was sent to me pre-built by our awesome project lead, thanks) and it worked first try.

If anyone is having second thoughts, thinking this is a big project to tackle, it really is not. The build is very straightforward, the only thing that tripped me up was the polarity of electrolytic caps or the LED themselves mainly because it had been so long since I had worked with components... but a quick google search to tell me the long leg was positive fixed that ;)
 
Back
Top