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

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
 
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.
 
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?
 
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.
 
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. :)
 
I have my first honest attempt at an expansion board in a draft stage. It has a single driver on it for moonlight LEDs that is I2C controllable (via digital pot, since that is easier to get ahold of than any reasonable I2C pwm IC). It also has a 4 channel ADC for temperature sensors, pH, etc. The idea is to keep this LED focused so for instance you could put the temp probes in the waser and/or on the heatsink and turn the LEDs off if things got too hot.

The board is 5cm square so it is the same size as the CAT4101 drivers and will be cheap to get from common board houses. There is technically some spare room on the board. Can anyone think of other hardware I might fill that space with?

Oh, and it is all surface mount, but easy packages, with the idea that this is a good first smt project. I would rate it as a similar difficulty as the 4101 drivers.
 
Hey DWZM

I want to thank you and everyone else who has contributed to this thread. I've been a lurking around here for a while now and have followed this thread from the beginning. I've learned a lot from you guys and I'd like to show you what I've managed to create with the knowledge that I gained from here. I built my own led lighting system using the Cat4101's so when the "Typhon" came along I modified it a bit by dropping the 10 volt circuits and using mostly SMD components. It runs the typhon firmware for now and functions beautifully. Take a look- (main board with the LCD unmounted)
IMG_1366.jpg
 
Hi!
I registered recently to RC and had been reading a lot about the Typhon and Hydra boards in the last days. I think you have done an excellent job with both projects.
Something that seems easy to link with the Typhon is the relay controller board from the Hydra. It is based on the MCP23008, use I2C comm. and will require no modification to the current pcb. This would open many possibilities for the Typhon, controlling fans, T5/MH lamps, pumps, etc. A simple sketch integrating this to the Typhon timer functions would be great as a start.
 
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 must be true. I remember an RC thread I read some 2 years ago (maybe a TOTM entry or thread, not sure) where the reefer controlled the lamps on/off time and moonlight on/off to mimic nature, and, he experienced coral spawning on the exact night when it happened in nature. Can't find that thread now. Does someone remember it?

I personally decided to tackle the problem of a "non-trapezoidal" light intensity curve, with clouds as an overlay, because that was (to me) the most interesting challenge. Next on the list is moonlight.

Moonlight should be the same as sunlight in terms of color and directionality and simulating phases should be easy for the controller.

That is true, and I have experimental proof. Some 15 years ago when I was vacationing at the Grand Canyon I decided to take a night picture. The sky was clear and had a beautiful full moon. I set my camera (Canon Rebel X SLR with Kodak Royal Gold ISO 100 film) on a fence, measured light using aperture priority mode with aperture around 1:16, set the camera on countdown and let it go. I don't remember the exposure time the camera chose, but it was long.

A few weeks later when I finally developed the roll (so different from our "instant see the picture" reality nowadays uh?) I was sad that the picture wasn't there... I thought it had come out pitch black and the lab technician had skipped it. Then, looking at the negatives I noticed no frame was skipped, which puzzled me. I looked at the printed pictures again, maybe I missed it or it was glued to another picture's back. Nope, nothing missing or glued.

Guess what... by remembering the shooting sequence of the pictures I noticed that one of the "daytime" pictures was in reality my nighttime shot. Impossible to notice by looking at the colors or luminosity.

So, yes, moonlight must reflect the sun's light spectrum very closely.

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.

Humm... I must respectfully disagree here. In a dimmable LED setup, where you can dim your LEDs to very low percentages (i.e. 1% or (1/255)%) I can't agree the best approach is having extra LEDs for moonlight and all the associated hardware.

If you have a driver and controller that can dim your LEDs down to 1% the best approach must be to use your regular LEDs as moonlight.

The "light intensity curve" of the sun must be added to the "light intensity curve" of the moon and the resulting curve for the day is what you need to make your existing LEDs follow. The only 0% moments of the day will be when there is no sun nor moon in the sky.

What is moonlight in a real day? An extra light source. We don't notice it when the moon is up during the day because it is so weak compared to the sun. But if the sun sets while there is a full moon up, you'll notice the moon's light a little after the sun disappears under the horizon.

So, no need for extra moonlight LEDs or channels, I2C, etc IMHO.

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

You know, I don't believe that, I believe it is the changing of the light. The variation in gravity is tiny, too tiny for a simple organism like a coral to notice or detect. An animal of higher order like a dolphin, or a pigeon, ok, I could accept that, they might have sensors that can pick the variation but not a coral.

Isn't he gravity pull the same independent of the moon's phase in the cycle? The light changes because of the relative position of the moon's orbit compared to the sun and earth, but, the moon's distance to the earth of a crescent is the same as of a full moon, isn't it? (this is a question, I have no precise idea, just guessing)

Snorkeler
 
I have to disagree with the moonlights using the daylight LEDs. I know we were just saying moon should be the same spectrum etc as daylight but the reality of it is that not all drivers can dim to the extent that you're expecting they can. Even if they can dim that low, it may still be too intense if you're running all channels.

For example, in my case my mean well drivers likely won't dim lower than 10% or so, but even if they could I have optics on my LEDs, I think that it would probably still be too much par to compare to actual night time / moon light.
 
+q more for not using daytime LEDs as moonlights there is no way the average build will get enough resolution down low. Even with the 4101 drivers that dim linearly down to 1%, you have to account for resolution. If i want to simulate moon cycles i need a good 15 steps of intensity between off and full moon, which means we would have to assume 15 steps up from the driver's minimum is dim enough to simulare moonlight. Even just the 24-LED test unit i had on my big tank before taking it down was too bright for that.

The good news is, adding a single channel I2C-controlled dedicated moonlight driver is both easy and flexible. And cheap. So that is the route i will be going!
 
I have to disagree with the moonlights using the daylight LEDs. I know we were just saying moon should be the same spectrum etc as daylight but the reality of it is that not all drivers can dim to the extent that you're expecting they can. Even if they can dim that low, it may still be too intense if you're running all channels.

For example, in my case my mean well drivers likely won't dim lower than 10% or so, but even if they could I have optics on my LEDs, I think that it would probably still be too much par to compare to actual night time / moon light.

+q more for not using daytime LEDs as moonlights there is no way the average build will get enough resolution down low. Even with the 4101 drivers that dim linearly down to 1%, you have to account for resolution. If i want to simulate moon cycles i need a good 15 steps of intensity between off and full moon, which means we would have to assume 15 steps up from the driver's minimum is dim enough to simulare moonlight. Even just the 24-LED test unit i had on my big tank before taking it down was too bright for that.

You guys got me thinking and doing some math and memory digging, and I guess I must agree with you.

Even if you have a driver that can dim down to 0.4% (1/255, Arduino's minimum PWM level) that is probably too much for a full moon. Why? Well, I think that picture I took at the Canyon was exposed for something like 20 or 30 seconds. Assuming it was 20 seconds at 1:16, the equivalent exposure time at 1:16 for daylight, if full moon = 0.4% and daylight = 100%, would be 0.08s which is roughly 1/12s. No way that a daytime picture of the grand canyon at 1:16 aperture would require 1/12s exposure time.... the exposure time would be way shorter/quicker.

So, yeah, I guess much less LED power, and therefore a dedicated LED channel, is needed to properly simulate moonlight....
 
So, yeah, I guess much less LED power, and therefore a dedicated LED channel, is needed to properly simulate moonlight....
LM3409 driver dimmed by MCP4725 (cheap) type I2C DAC will give you 4096 steps. That might be enough. That is what I will be doing anyway because I agree that 255 steps are not enough.
 
Last edited:
I posted awhile back about my plans (not implemented) of moon lights with the CAT4101. The plan was to have two CAT4101 drive the same string of LEDs. One would be daylight with a base current of 500-900 ma. The moon light would use a 100k (rather than 10k) pot with the plan of adjusting it closer to 10 ma (guess). This would actually allow 255 moon light steps (probably over kill) while probably adding less than $5 in parts.
 
That is an interesting solution.

Another reason why i am using dedicated LEDs is because I want to control their position, angle, and optics independently of the main lights. More of that "shaft of light" effect I am always ranting about. :D
 
Now that more people have Typhons, does anyone has a box to house and protect the controller that you could easily use the buttons?

I think DWZM posted this before, don't know if it was here but anyone knows some kind of button extensions? That will ease boxing the controller cause the buttons will not be accessible if you drill a hole for the screen
 
Now that more people have Typhons, does anyone has a box to house and protect the controller that you could easily use the buttons?

I think DWZM posted this before, don't know if it was here but anyone knows some kind of button extensions? That will ease boxing the controller cause the buttons will not be accessible if you drill a hole for the screen
 
I have the button extensions but got them with another project and unfortunately do not have a source for them. Probably because I do not know what they are officially called. Maybe one of the resident EEs will chime in. I hope to find a source because my digital oscilloscope is currently without four of these since I stole them for the typhon. :D

As far as an enclosure, I have mine in a normal 2 gang wall box (like you would use in the wall for home wiring) with a blank faceplate cut for the screen and buttons. It works well and looks great.

In other news I ordered the pcbs for the above-described add-on module and will report back once it is tested.
 
Back
Top