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

I should say, the rtc is always tracking date info, wether we explicitly set it correctly or not. So first we need to set it correctly,bwhich can be done via the same method we set time, then, we can start using it. It is almost trivial compared to some of the things we have done to date.
 
XSiVE said:
I really think the Typhon does exactly what it needs to do. I can see the usefulness of a couple more PWM channels but Im not sure at what expense.

IMO stay away from anything surface mount, that takes the hardware build up a notch for a lot of people, but maybe enough people would want it on board that they will learn to do surface mount soldering correctly.

I think an issue with V1 is sketch size limitation. I don't have it in front of me but i thought we were at about 1/2 capacity with the current firmware (which im sure could be cleaned up and shrunken) but if we're going to continue to add more functionality without addon boards then we're going to need some more room.
Click to expand...

Good feedback. Getting another pwm channel would probably mean major changes, i.e. using a gpio chip like the mcp23008 for the lcd to free pins. I am not sure if it is worthwhile.

In terms of code size, a lot of that is boilerplate we would re use, i.e. the I2C library which is huge, but already in our code. Things I am thinking about include an adc for temp probes or pH. Or a dedicated moonlight or fan driver. Stuff like that.
 
der_wille_zur_macht said:
The rtc is already tracking date info, you just have to write code to get it and use it how you want.
Click to expand...

sorry, I mis-spoke ;) err... typed, whatever.. hehe.. but yeah I guess it is tracking that by default it's part of the RTC. What I meant was that we don't technically have a "date" per-se since we never set one, we just sort of reset from 0,0,0 or whatever every time. Adding a set date function on the end of the menu probably wouldn't be a problem and would open up a lot of "day to day" or "seasonal" type functionality.

I forgot to mention something earlier on in feedback. Any ideas on storing the user-defined variables to EEPROM? I know it was part of the initial code base but it never worked (for me anyway). Having everything but the clock reset on power loss is sort of a big issue in my opinion, especially if you're running at less than max intensity, then have a power bump and suddenly you're frying your corals! :angryfire: I know we don't want to write them too often in the code itself because we'll hit the eeprom's limit quickly.

by the way im not requesting all of this to be done, Im just putting it out there for reflection by others. I'll probably do most of the experimenting myself to see if I can get things working :)
 
der_wille_zur_macht said:
The eeprom variables code works fine for me and probably another dozen units i know of. Are you sure you are running the correct version of the firmware?
Click to expand...

Considering my name is on the google code page as the person who last modified the most current version of it I would sure hope I'm using the correct one :wavehand:

I'll check into it when I get home. I know that they work when you hard code them, there's no doubt about that. The issue comes in when you want to change them through the UI then save them off for a power reset. That can't be working with the current setup as it's hard coded to reset them to a specific value when it reboots (lines 80 thru 98). We also didn't want to be doing an eeprom write with every iteration of a variable change, whereas we can easily increment memory variables without hardware consequence.
 
Last edited:
der_wille_zur_macht said:
Another user wrote a modification to the code that inverts to pwm signal for drivers like yours. I have it in email so i just need to check it in some time when I am at a pc (most of my internet time is via phone).
Click to expand...

I would very much like the code as I'm sure others would as well.

As to the date funtion, I saw that it was in the pde and thought it would be part of the display at least.

As to other funtions that I personally would like to see added into the Typhon, It would be nice to have an output for a fan control and an auto shut-off if the temp kept rising above a set point. Dual temp controls would have to be added but from a hardware standpoint shouldn't that be doable?
 
XSiVE said:
Considering my name is on the google code page as the person who last modified the most current version of it I would sure hope I'm using the correct one :wavehand:

I'll check into it when I get home. I know that they work when you hard code them, there's no doubt about that. The issue comes in when you want to change them through the UI then save them off for a power reset. That can't be working with the current setup as it's hard coded to reset them to a specific value when it reboots (lines 80 thru 98). We also didn't want to be doing an eeprom write with every iteration of a variable change, whereas we can easily increment memory variables without hardware consequence.
Click to expand...

Im doing it wrong is all.. but now Im confused.

If we are defining & hard coding the eeprom variables in the above listed lines, why are they not being set to those values on each restart? This makes no sense to me.

Secondly, I think I will want to change to local memory variables for the menu operations, and then write them to EEPROM on menu exit. This way we're not killing the eeprom with each press of the button while changing start/stop times etc.

I don't know what the limit on the clear/writes to the chip's eeprom is but if it's on the low end (100,000) we could hit it relatively quickly just playing around testing, though real-world use would probably never see this, I'd like to avoid it if at all possible.

Do these changes seem reasonable?
 
shark boy said:
Dual temp controls would have to be added but from a hardware standpoint shouldn't that be doable?
Click to expand...

Totally doable, even with today's Typhon - I purposefully broke out headers for I2C and the onboard serial port to allow for expansion. You could even go out today and get one of the billion different generic I2C-based breakout boards on eBay or hobby electronics vendors and implement stuff without any hardware design work required. Or if you needed several more channels of PWM you could write a version of the sketch that ran as a "slave" and put a cheap Arduino clone on the I2C bus just to get access to it's 6 PWM ports. Something like a boarduino or RBBB would be great for this. This, IMHO, is the beauty of the architecture we built this on. It's dirt simple for people that just want the basics, but expandable with Lego simplicity if you want more functions.

XSiVE said:
Im doing it wrong is all.. but now Im confused.

If we are defining & hard coding the eeprom variables in the above listed lines, why are they not being set to those values on each restart? This makes no sense to me.

Secondly, I think I will want to change to local memory variables for the menu operations, and then write them to EEPROM on menu exit. This way we're not killing the eeprom with each press of the button while changing start/stop times etc.

I don't know what the limit on the clear/writes to the chip's eeprom is but if it's on the low end (100,000) we could hit it relatively quickly just playing around testing, though real-world use would probably never see this, I'd like to avoid it if at all possible.

Do these changes seem reasonable?
Click to expand...

Don't worry, I am confused also. All I know is, on the Typhon I am using today to drive LEDs and a bunch I've set up for others, it correctly remembers variable values. I'm a bit embarrassed to say I have no idea which version of the sketch these units are running as most of them were put together last summer. I've switched PCs about half a dozen times since then and have no way of knowing what code I burned on the avrs. Besides this issue, I have a version of the sketch modified by the vendor mentioned earlier in this thread (they said it was to make the menus better but I haven't looked at it yet) and one modified to allow for PWM inversion settable via menu option. You and I should take this to email and work out what functions are in what versions of the code so we can get back on track as far as making sure everything is rolled into the version on the google site. We should probably do that before trying to implement anything new (dates, cloud cover, etc.) I do like the way you described the eeprom functionality though, and it may mean we can ditch the eepromvar library I dredged up in an attempt to make the eeprom management invisible to the casual end user.
 
So I did some testing and here's what I found regarding the EEPROMvar library and how we're using its functions.

First, it appears that when we're instantiating the class it's requiring a value to be assigned, however it's not actually doing anything with this value. :crazy1: Can't tell exactly why but whatever..

Secondly, the only reason that we're actually able to store and retrieve values properly is because we're creating these variables statically and in the same order each time. If the code gets updated and we add another eeprom variable using this class say, at the top of the list then every other variable down the list will be looking to an address that's shifted down by however many we added at the top.

While this works for the current version I'm not very comfortable using it going forward because who knows if we want to add more later on, or if there's even a possibility of dynamically creating a variable(or more than one) that would be stored in eeprom.

We could consider using http://www.arduino.cc/playground/Code/EEPROMWriteAnything

or just do it manually byte by byte *shudder* :hmm5:

I guess in any case, we may want to consider an index be stored so we know exactly what we're reading(or storing) and from where.
 
Last edited:
I have worked with Non Volatile RAMs in the past which are similiar to EEPROMs. Limited writes ans such. I handled it by reading the RAM at power up into a local copy (structure with every byte accounted for). This local copy could be changed as desired. There was then a user/host command to store the RAM.

So you might consider doing it similarly. Read and write all at once, maybe you can have a character on the display to flag when the local copy differs from the EEPROM so the user knows to do a save.

This shifting could cause real issue if you start make instances of EEPROM variables in different modules.
 
TheFishMan65 said:
I have worked with Non Volatile RAMs in the past which are similiar to EEPROMs. Limited writes ans such. I handled it by reading the RAM at power up into a local copy (structure with every byte accounted for). This local copy could be changed as desired. There was then a user/host command to store the RAM.

So you might consider doing it similarly. Read and write all at once, maybe you can have a character on the display to flag when the local copy differs from the EEPROM so the user knows to do a save.

This shifting could cause real issue if you start make instances of EEPROM variables in different modules.
Click to expand...

That type of shifting issue was exactly what I was thinking regarding my "dynamic" comment.

As for the limited writes, Im actually working on some code right now to deal with the issue. I've got it saving (if the values differ) as the user exits the current menu item instead of writing to eeprom at every iteration of change (as the current release does). I do however like your idea of the user being forced to save their changes through the UI and a reminder coming up to let them know it's unsaved.

The next step is to determine which method should be used for EEPROM interaction and to design an appropriate data structure (I suck at data structures :lol: )
 
If you guys feel adventurous, the Hydra code has the functionality to save to eeprom any size vars, and does it only when you hit save.
 
I am a programmer, by occupation so I can offer general comments and ideas. I intend to build both typhoon and hydra and then i will get into the code. Or at least that is the plan :)

Another thread that is getting a lot of good feed back is Another's (oops I mean katchupoy). They have clouds and modeling of existing reefs (I think). The difference is that it is a little looser (bought Arduino boards, most seem to use a graphics display) so you need to know how yours differs from others.
 
Good to know. That was the original intent. We could even have submenus for each LED channel so you didn't have to flip through 20 screens to change one thing.
 
To me there are lots of ways to have a good, successful reef. Most people concentrate on things like growing corals fast or keeping popular or rare species. Personally, i am trying to concentrate on simulating nature, even if it is superficially, i.e. it does not directly impact the health of the corals. I want to recreate the sensations I remember diving on reefs, and that includes using light purely for dramatic effects in addition to using it to grow corals.

So yeah, it's pretty much about the bragging rights is all. :D
 
terahz said:
Why is everyone so crazy about clouds? :) I can't see the point of it other than to say "my lights simulate clouds". Seriously, is there any other reason why people spend so much time on this?
Click to expand...

1. It is fun :-)

2. DWZM already said it, and I agree with him, simulating nature. It might be good for corals to have your lights dim down occasionally like in the wild too. It can't be a coincidence that some people report good results leaving their lights off for a day every 30 days.

It sure is cool :-D
 
You must log in or register to reply here.

Similar threads

R
DIY AI-coded ESP32 based aquarium controller
Replies
0
Views
958
ronnyking
R
A
Aquarium Temperature Control: How I Hacked My Air Conditioner to control my tanks temperatures
Replies
6
Views
1K
Naso180
N
A
New, but Not New to the Hobby
Replies
17
Views
1K
Guygettnby
Guygettnby
J
Heater controller
2
Replies
23
Views
2K
Dustin07
D
B
Question on Mean Well 3-1 dimming
Replies
15
Views
892
bmichaelb
B
Back
Top