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

[der_wille_zur_macht]

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.

[der_wille_zur_macht]

Originally Posted by XSiVE

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.

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.

[XSiVE]

Originally Posted by der_wille_zur_macht

The rtc is already tracking date info, you just have to write code to get it and use it how you want.

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! 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]

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?

[XSiVE]

Originally Posted by der_wille_zur_macht

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?

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

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.

[shark boy]

Originally Posted by der_wille_zur_macht

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).

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]

Originally Posted by XSiVE

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

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.

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?

[der_wille_zur_macht]

Originally Posted by shark boy

Dual temp controls would have to be added but from a hardware standpoint shouldn't that be doable?

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.

Originally Posted by XSiVE

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?

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.

[XSiVE]

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. 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/Cod...MWriteAnything

or just do it manually byte by byte *shudder*

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.

[TheFishMan65]

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.

[XSiVE]

Originally Posted by TheFishMan65

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.

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 )

[terahz]

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.

[TheFishMan65]

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.

[der_wille_zur_macht]

Is anyone using the button labeled select for anything?

[XSiVE]

Originally Posted by der_wille_zur_macht

Is anyone using the button labeled select for anything?

In the current google code revision (r15?) it's used to cycle sub-menus in the manual override section.

[der_wille_zur_macht]

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.

[terahz]

Originally Posted by TheFishMan65

I am a programmer, by occupation

Makes 2 of us

Originally Posted by TheFishMan65

They have clouds and modeling of existing reefs

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?

[der_wille_zur_macht]

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.

[snorkeler]

Originally Posted by terahz

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?

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

[TheFishMan65]

I would think it would be more important than clouds to have true phases of the moon, but that is not quite as visible.

[shark boy]

Originally Posted by TheFishMan65

I would think it would be more important than clouds to have true phases of the moon, but that is not quite as visible.

That's really an interesting thought. Has anyone done any reserch as to the type of light being reflected from the sun on the moon? Or do you suppose we need a giant magnet on a motor driven bar to pass back and forth across our tanks. LOL

[der_wille_zur_macht]

Moonlight should be the same as sunlight in terms of color and directionality and simulating phases should be easy for the controller. Peerhaps we have an option to turn one channel into a moonlight channel? Or instead of loosing a channel, we make a breakout board I2C moonlight driver?

I like the second option.

[XSiVE]

I think that a breakout for controlling additional channel functionality like that would be the best option.

I use three channels currently but I could get away with using two instead. I'm lighting my tank uniformly with different dimming cycles for blues & whites. If someone with a larger tank (say, with four independent pendants) wanted to do a simulated daylight and moonlight cycle, lighting the tank from side to side they would have their current configuration crippled if we changed one of the current channels to a moon cycle. Sure they could continue to use older firmware, but why force old software on someone so they can maintain basic functionality?

[liquidarts]

Originally Posted by TheFishMan65

I would think it would be more important than clouds to have true phases of the moon, but that is not quite as visible.

I have to agree with your there on that fishman....i've downloaded lots of movies from the net cause my kids like watching and learning about coral reefs as well as dolphins and sharks.But in each of the videos that I have when the narrator talks of the spawning cycle the phase of the moon is what drives the corals to it.

[TheFishMan65]

I read that somewhere too, but it probably won't matter. I am sure that it is not the changing of the moon light, but the change in gravity that causes the spawning. So it will be very important to synchronize your moon cycle with the real moon.