chrisfowler99
Premium Member
Built, LCD hooked up, USB-BUB attatched, programmed and booted.
Who wants a cheap, simple, Arduino-based LED controller?
- Thread starter der_wille_zur_macht
- Start date
Built, LCD hooked up, USB-BUB attatched, programmed and booted.
chrisfowler99
Premium Member
chrisfowler99
Premium Member
Hit a problem with the software this evening.
I was hitting '-' on Fade and it went negative. The '+' button isn't doing anything. Not sure if it was before it went negative.
I may take a look at the code tomorrow to see if I can tell what's going on.
mm.reefs
Member
Second case!:spin1: I already mentioned this to XSiVE about an hour ago in a PM. It's an easy fix!!!
der_wille_zur_macht
Team RC
mm.reefs, I don't see any recent revision on the google code site - if he let you in on the fix, please post it here and he or I will upload it so others can have it.
XSiVE
New member
It is an easy fix, you're right, I didn't get started working on it until this morning and then I stumbled across another couple of other issues while fixing it.
1.) if you changed the start time, it was automatically pushing or pulling the end time with it, preserving the photoperiod. I think this is not the right way to go so I modified the start time code to preserve the end time and stretch or shrink the photoperiod appropriately. Most timers on the market today preserve start and end time so I think this is the way to go for consistency's sake.
2.) this brings up another issue which was only half there before. and I need some guidance from you all. When setting the start or end time, if you bounce up against the fade duration max (photoperiod / 2) should it automatically adjust the fade duration to photoperiod / 2? Or should it leave that alone and expect you to go back and set it yourself? (edit) or should we expect everyone using it to not do this?
1.) if you changed the start time, it was automatically pushing or pulling the end time with it, preserving the photoperiod. I think this is not the right way to go so I modified the start time code to preserve the end time and stretch or shrink the photoperiod appropriately. Most timers on the market today preserve start and end time so I think this is the way to go for consistency's sake.
2.) this brings up another issue which was only half there before. and I need some guidance from you all. When setting the start or end time, if you bounce up against the fade duration max (photoperiod / 2) should it automatically adjust the fade duration to photoperiod / 2? Or should it leave that alone and expect you to go back and set it yourself? (edit) or should we expect everyone using it to not do this?
Last edited:
der_wille_zur_macht
Team RC
To clarify XSiVE's question, I implemented a feature in the original version of to prevent weird conflicts in how the fade works. Bear with me for a second so I can explain it.
To review how the fading works:
1) At your programmed start time, the LEDs turn on, effectively at 1%.
2) The LEDs "fade" up, such that after the fade duration has elapsed, they are at 100%. The time that this happens is basically start time + fade duration.
3) In the evening, the LEDs begin fading back down. They start fading back down at start time + photoperiod - fade duration.
So, think of "fade duration" as the time it takes the LEDs to ramp up at dawn, and the time it takes them to ramp back down at dusk.
The potential for conflict is this: If fade duration is greater than half the photoperiod, the ramping up for dawn won't be finished yet when the ramping down for dusk is supposed to begin! Hence you'd end up with an undesirable situation where your programmed max intensity is never actually reached.
So, in the original firmware, I implemented a feature where it would not let you create that situation. XSiVE is asking us how exactly we'd like that protection - do we want the software to:
1) Auto-correct as you adjust things
2) Prevent users from creating this situation
3) Do nothing, and let users create "weird" behavior
To review how the fading works:
1) At your programmed start time, the LEDs turn on, effectively at 1%.
2) The LEDs "fade" up, such that after the fade duration has elapsed, they are at 100%. The time that this happens is basically start time + fade duration.
3) In the evening, the LEDs begin fading back down. They start fading back down at start time + photoperiod - fade duration.
So, think of "fade duration" as the time it takes the LEDs to ramp up at dawn, and the time it takes them to ramp back down at dusk.
The potential for conflict is this: If fade duration is greater than half the photoperiod, the ramping up for dawn won't be finished yet when the ramping down for dusk is supposed to begin! Hence you'd end up with an undesirable situation where your programmed max intensity is never actually reached.
So, in the original firmware, I implemented a feature where it would not let you create that situation. XSiVE is asking us how exactly we'd like that protection - do we want the software to:
1) Auto-correct as you adjust things
2) Prevent users from creating this situation
3) Do nothing, and let users create "weird" behavior
XSiVE
New member
Thanks for the clarification DWZM...
Personally Im leaning toward the auto-correct as you adjust settings, I put it in the firmware that I am currently testing and it seems to be working thus far. I can take it back out, or change to the preventive solution as well...
The problem with the preventive solution is that if you want to adjust the start or end time drastically (possibly past one another to get through a midnight), then the code for fade duration preservation will prevent this unless it's fairly complex.
and now I just ran into yet another bug with the sliding time. *grumble*
Personally Im leaning toward the auto-correct as you adjust settings, I put it in the firmware that I am currently testing and it seems to be working thus far. I can take it back out, or change to the preventive solution as well...
The problem with the preventive solution is that if you want to adjust the start or end time drastically (possibly past one another to get through a midnight), then the code for fade duration preservation will prevent this unless it's fairly complex.
and now I just ran into yet another bug with the sliding time. *grumble*
der_wille_zur_macht
Team RC
I agree, I like the auto correct option. The thing is, we (and by "we" I mean "you" 
) will probably have to implement it in multiple spots, since you could cause the conflict by adjusting start time, photoperiod, or fade duration.
) will probably have to implement it in multiple spots, since you could cause the conflict by adjusting start time, photoperiod, or fade duration.
XSiVE
New member
I agree, I like the auto correct option. The thing is, we (and by "we" I mean "you"
exactly, and I dislike repeating implementation of code like that.. I guess for now it's not a huge issue since we're more concerned with getting the functionality correct, but long term that will have to be dealt with.
der_wille_zur_macht
Team RC
Right now, as you know, I buried the implementation in the UI. In other words, I put the functions that alter the variables that actually run things right in the menu structure. I'm thinking at some point we will want to change that - have the menu structure manipulate a "temporary" set of variables, then have a block of code at the end of the main loop that interprets those variables, implements our conflict checks, and updates the "real" variables accordingly.
XSiVE
New member
Yeah I did pretty much that same thought for the auto-correct testing.
While testing this I ran across yet another "undocumented feature"
If the fade duration was set to 0(0 photoperiod divided by 2 = 0 fade), fade up or down would not work so I am now keeping fade duration minimum to 1 min. This essentially translates to an instant on/off, but that's better than the channel not turning on at all. Thinking further, that's probably the best way to just turn a channel on if you wanted one to be used for a timer.
Im sure once I get this all straightened out another bug will pop up
While testing this I ran across yet another "undocumented feature"
If the fade duration was set to 0(0 photoperiod divided by 2 = 0 fade), fade up or down would not work so I am now keeping fade duration minimum to 1 min. This essentially translates to an instant on/off, but that's better than the channel not turning on at all. Thinking further, that's probably the best way to just turn a channel on if you wanted one to be used for a timer.Im sure once I get this all straightened out another bug will pop up
der_wille_zur_macht
Team RC
I've had the thought that we probably do need a way to keep a channel off (no need to have an unconnected, unused pin dangerously high - if it touched something that was grounded it could let the smoke out), but given the current structure there's no obvious way to do that.
mm.reefs
Member
Im sure once I get this all straightened out another bug will pop up
I promise I will get you another bug as soon I start using my Typhon!!! :lmao:
<V
</VNahh, just kidding!!! You and DWZM have done a splendid job... keep it going!!!chrisfowler99
Premium Member
Another question about the programming.
There's a setting to put them all on, off or timer.
If I put them all on, it is not changing the display that shows the power they're currently running at. In my case still showing "0 100 100 0". Are they actually all on at this point? And at what level, max or 100?
There's a setting to put them all on, off or timer.
If I put them all on, it is not changing the display that shows the power they're currently running at. In my case still showing "0 100 100 0". Are they actually all on at this point? And at what level, max or 100?
XSiVE
New member
I actually just noticed that as well, but the pins are sending out the proper signal.
I'll work on that next, I just got the other issues debugged so I'll be pushing a new version up to google code as soon as I get the source cleaned up from my debugging :lol:
XSiVE
New member
If you keep a channel's max at 0 (or in this new revision set the start and end time to the same time) it will never turn on, or are you thinking of something different here?
der_wille_zur_macht
Team RC
No, that's what I'm thinking of, I was just thinking that although there are a few ways to get that to happen, none of them are obvious. Not a huge deal, just a thought. I'm not sure it's worth coding anything specific for this.
Similar threads
