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

Month and Day of week

Month and Day of week

Does anybody's full date work? I cannot change the program (don't know how to program) beyond very simple things.

I contacted the guys at the Boostled website. They posted the sketch they are currently using on the Typhon controller they sell. It's fancied up a little, (it has credits) but still no date. You can find it if you go to the site.
 
I would like to post a disclaimer/clarification. The typhon was released under 3.0 by-sa. It was the Hydra that had the NC clause. As a result there are no commercial restrictions on this project.

I have no involvement or relationship with any vendor related to this controller and no desire to have any such relationship - I am in this for the DIY aspect. Also, I would like to remind people that RC has a pretty strict policy regarding vendors that are not site sponsors. Let's keep discussion of commercial implementations of this project out of this thread to avoid it being moderated. Thanks all.
 
clouds/storm simulation

clouds/storm simulation

Someone has written a cloud/storm program for the adruino platform. It looks very cool. Unfortunatly I don't know enough about programming to make it work for my Typhon.

Would someone like to take a crack at this?

I might go buy a pre-made board just to see this thing in action!

The whole file is like 51k but when compilied with arduino 0022 it is 11264 bytes. It does upload to my Typhon but that's all.

You can find the thread in the sketches discussion post #388.

In summary, it is a sketch with a curved light profile, which follows Numlock10's Great Barrier Reef day duration and weather data, with clouds and thunderstorms throughout the day and occasional lightning when inside a thunderstorm.

The full code is here:
http://code.google.com/p/arduino-rtc...58fe5068bccc89
 
Anyone know of a UK/EU retailer of the Typhoon? Boostled want $45 to ship to the UK which is crazy. PM me please if public recommendation/links are not allowed. Thanks!
 
So I just discovered something odd..

The PWM scaling is inconsistent on the 10v header outputs but seems to be fine on the 5v's. Im trying to figure out if this is a software or hardware issue (Im guessing it's hardware choice since the 5v's are fine), it seems the first voltage regulator is doing its job properly and capping it at 10v, so no risk to going above 10v, but if you're running at less than 100% it may not be putting out what you think it is.

I would highly recommend checking the output of your drivers compared to the percent you expect them to be running at and adjusting accordingly. I'll see if I can diagnose exactly what is going on.

dwzm, Im not so great with the components used here, any ideas on what it could be?

edit: oh and I don't have an affiliation with that company either, other than them emailing me saying they were going to start selling it.
 
Last edited:
So I just discovered something odd..

The PWM scaling is inconsistent on the 10v header outputs but seems to be fine on the 5v's. Im trying to figure out if this is a software or hardware issue (Im guessing it's hardware choice since the 5v's are fine), it seems the first voltage regulator is doing its job properly and capping it at 10v, so no risk to going above 10v, but if you're running at less than 100% it may not be putting out what you think it is.

For example, 10% in the menus is putting out .485v in the 5v line(as expected), and 4.1v in the 10v line!

It's something to do with u3, u4, u5, u6, but again I don't have enough knowledge to know exactly what's wrong. Here's some info I pulled together.

measured to board ground the following was found at 10% duty cycle

r4, r5, r6, r7: vin = .482, vout=.078
u3, u4, u5, u6:
collector: .000v,
base: .078v (expected based on r vout),
emitter: .9v (shouldnt this be 0 as we're supposed to be switching ground here?)
actual output between header pins: 4.1v
positive header pin to ground:10.05v


measured to board ground the following was found at 50% duty cycle

r4, r5, r6, r7:
vin = 2.43,
vout=.366

u3, u4, u5, u6:
collector: .000v,
base: .365v (expected based on r vout),
emitter: .245v (shouldnt this be 0 as we're supposed to be switching ground here?)
actual output between header pins: 7.84v
positive header pin to ground:10.05v


So I guess, here's where my limited knowledge comes in.. if I'm getting .245v(should be 0) on one to ground, 10.05 on the other, I guess somehow that adds up to 7.84 between the two. :headwalls: I just can't explain why this is happening.
 
Did you do those measurements with the meanwells on the circuit, or open circuit? I THINK i know what is going on but I am not sure. I would bet this is inherent to the design and not just your unit - again just a guess, but it brings up a subject that is somewhat relevant so bear with me...

The 10v lines are not simply a scaled version of the 5v signal. The positive side of the header is connected directly to 10v. The negative side is switched between gnd and floating by the transistors. So behavior may not be measurably parallel, depending on conditions (i.e. if anything is connected to the header).

This is a design decision I made based on successful tests with Meanwell drivers (the half dozen or so beta testers i had reported things worked fine) but it is perhaps unconventional. I do not consider this a flaw as the controller is clearly still functional, and I don't want to prematurely spill the beans, but there is a totally new v2.0 in the works that addresses this.
 
These measurements were taken with no load on the controller whatsoever. This was re-created on both the unit that you sent to me as well as the test bench model I put together and was using last summer when knee deep in the code.

The design was sort of what I was thinking, not necessarily a bad component or build since I saw the difference on both units... I knew when the 10v header was used, we were switching ground (dont know what floating means here) but I did not know the consequences of doing so.

I also noted the drive current of the mean-well's significantly higher than it should have been(I initially found the problem with my kill-a-watt, noticing the 72 LEDs shouldnt be drawing 300W at "50%") , yet it does dim up, dim down, etc etc.. so it appears to be functioning properly as your beta testers probably were more concerned with the cool factor than exact measurements at specific percentages... I was too. The scaling is almost like an y=x^2 graph instead of y=x as it should be ;)
 
The design was sort of what I was thinking, not necessarily a bad component or build since I saw the difference on both units... I knew when the 10v header was used, we were switching ground (dont know what floating means here) but I did not know the consequences of doing so.

In this sense, floating means "not connected to anything at all" in terms of voltage. It is an open circuit. In programmer's terms, the voltage is a null value.

I also noted the drive current of the mean-well's significantly higher than it should have been(I initially found the problem with my kill-a-watt, noticing the 72 LEDs shouldnt be drawing 300W at "50%") , yet it does dim up, dim down, etc etc.. so it appears to be functioning properly as your beta testers probably were more concerned with the cool factor than exact measurements at specific percentages... I was too. The scaling is almost like an y=x^2 graph instead of y=x as it should be ;)

It would be interesting to compare your observations with other dimming methods and other methods of observation. I wonder if the meanwell's overall poor dimming performance comes into play. Plus, with respect to the killawatt, I wonder if that is partially due to poor driver efficiency while being dimmed. There are a ton of variables out there and at the end of the day different people may have different requirements for functionalityy described by the same words. That is part of the reason for version two. Take the lessons learned here, now that the design has been out there for a while, and improve the product. So if anyone else has improvements they would like to see, let me know.
 
It would be interesting to compare your observations with other dimming methods and other methods of observation. I wonder if the meanwell's overall poor dimming performance comes into play. Plus, with respect to the killawatt, I wonder if that is partially due to poor driver efficiency while being dimmed. There are a ton of variables out there and at the end of the day different people may have different requirements for functionalityy described by the same words. That is part of the reason for version two. Take the lessons learned here, now that the design has been out there for a while, and improve the product. So if anyone else has improvements they would like to see, let me know.

I might try the 5v pwm outputs to see how the meanwell takes those instead of 10v.. perhaps even run two in series (since I only use 2 channels anyway) and see what happens (hopefully nothing goes poof)

okay so apparently my measurement labels aren't correct. I was going off the wrong data sheet so i had my collector and emitter values backward, sorry about that.

10% duty cycle:
Emitter: .000v,
base: .078v
Collecter: .9v
actual output between header pins: 4.1v
positive header pin to ground:10.05v


50% duty cycle

u3, u4, u5, u6:
Emitter: .000v,
base: .365v (expected based on r vout),
Collecter: .245v
actual output between header pins: 7.84v
positive header pin to ground:10.05v

sorry about the mixup... dont know if this changes anything or not but I want to be sure im putting the correct information out there.
 
Yeah I thought about that after I posted the crazy idea... I'm measuring with my trusty old fluke 77.
 
Can the date funtion be used with the Typhon? There is another thread for adrunio sketches that has programmed a sketch called random clouds. It sounds pretty cool and the code shouldn't be too large for the mega 328 to handle. The problem seems to be the date funtion in the code. I've asked several times about the date funtion on that thread but I must be invisable because I have not gotten any replies to my question.

The Typhon was a lot of fun to build, unfortunatilly this project seems to be dead due to the fact that there isn't any ongoing code revisions, or ideas on how to expand the funtions. Everyone knows this project has not reached it's limits, yet no one seems to be interested in its expansion.I'm hoping for a revival here.

If not, Ebay sells the mega2560 w/128x64 lcd kits for a little more than it cost me to build the Typhon.

For now that seems to be the hot processor to have. Lots of people are on that band wagon, and the chip has 14 PWM channels to play with.

I'll hate to junk my Typhon, but with no support what's a body to do?
 
What date function are you referencing? There is date info available from the rtc and the board should be able to execute any arduino code.

You seem disappointed in a "lack of support" and are talking about switching hardware. Is there something else specific besides the date function you are struggling with?
 
Shark Boy, the idea is that the community comes up with ideas on what to add, not just two people. Thank you for bringing up clouds, Id be happy to look into some cloud functionality. Do you think we should just pop that existing random clouds program into this? If so point me to where I can find the sketch and I'll take a look.

A question becomes then, how to execute it in the confines of the 4-ch output of the typhon? Different people attach their drivers to the typhon in their own way.. some may have drivers with mixed colors on a string, some may have all on one channel, some may have single color per channel, etc. Do we dim them all, do we dim different channels to different extents? Your input is valued here the idea is again that there needs to be contribution from more than just a few sources or the project stagnates :)
 
I mentioned above a version two of the hardware. I am pretty confident that the current version covers the functions originally described given the original constraints, so I am interested in hearing what people feel is missing for a version two, and what assumptions or constraints may have changed.

For instance, I did not put usb onboard because it means soldering a slightly tricky surface mount package and you can just buy a usb-ttl cable to get around that. Do people want usb onboard, at the expense of having to solder the smallish smt package?

How important is it to have more PWM channels?

How important is it to have something like a jack for a temp probe, so you could shut off the lights if the temp got too high?

Are people more interested in seeing a new version of the coore hardware, or simply expansion modules you could plug in to the I2C or serial headers on the top of the board? Or both?
 
OK, I'm not trying to throw stones here.

This has been a lot of fun to build and develop. It gets really frustrating when there's a problem with no seeming solution.

der_wille_zur_macht Here is the part of the code for the Typhon that I think has the date setup.

// Sets date and time, starts the clock
void setDate(byte second, // 0-59
byte minute, // 0-59
byte hour, // 1-23
byte dayOfWeek, // 1-7
byte dayOfMonth, // 1-31
byte month, // 1-12
byte year) // 0-99
{
Wire.beginTransmission(DS1307_I2C_ADDRESS);
Wire.send(0);
Wire.send(decToBcd(second));
Wire.send(decToBcd(minute));
Wire.send(decToBcd(hour));
Wire.send(decToBcd(dayOfWeek));
Wire.send(decToBcd(dayOfMonth));
Wire.send(decToBcd(month));
Wire.send(decToBcd(year));
Wire.endTransmission();
}
// Gets the date and time
void getDate(byte *second,
byte *minute,
byte *hour,
byte *dayOfWeek,
byte *dayOfMonth,
byte *month,
byte *year)
{

I don't have the knowledge to know if it does this or not. I'm guessing.
The Typhon doesn't seem to know what day, month, or year it is.

If the date function worked then variables could be introduced into the program allowing the light simulation to change from day to day.

XSiVE
Random clouds in the Arduino Sketches forum, post #388 kind of kicks it off.

One other problem I have is that I bought REC-24-1.00/W/X3 drivers. They are buck/boost drivers so my PWM outputs from +5v-0v instead of 0v-+5v
So I have to tell the lights to go off instead of come on to make them work.
I have tried to change the sequence and can make the lights right if I turn all the channels on at once but if I try to control them individually they do not work.

Here is the part of the code I've changed.

analogWrite(ledPin, map(val, 0, 100, 0, 255));
changed this to
analogWrite(ledPin, map(val, 0, 100, 255, 0));
and
analogWrite(channel[0].Led, map(pct,0,100,255,0));
analogWrite(channel[1].Led, map(pct,0,100,255,0));
analogWrite(channel[2].Led, map(pct,0,100,255,0));
analogWrite(channel[3].Led, map(pct,0,100,255,0));
changed this to.
analogWrite(channel[0].Led, map(pct,0,100,0,255));
analogWrite(channel[1].Led, map(pct,0,100,0,255));
analogWrite(channel[2].Led, map(pct,0,100,0,255));
analogWrite(channel[3].Led, map(pct,0,100,0,255));

I should have bought or built different drivers so this wouldn't be a problem. I like the drivers and thought I could fix this with little effort.

This is a good project for the application. I do value the hardware and software. I'm aware of the time and effort that the community puts into these builds.

Again, thanks for letting me be a part of this. The DIY projects are always great.
 
I mentioned above a version two of the hardware. I am pretty confident that the current version covers the functions originally described given the original constraints, so I am interested in hearing what people feel is missing for a version two, and what assumptions or constraints may have changed.

For instance, I did not put usb onboard because it means soldering a slightly tricky surface mount package and you can just buy a usb-ttl cable to get around that. Do people want usb onboard, at the expense of having to solder the smallish smt package?

How important is it to have more PWM channels?

How important is it to have something like a jack for a temp probe, so you could shut off the lights if the temp got too high?

Are people more interested in seeing a new version of the coore hardware, or simply expansion modules you could plug in to the I2C or serial headers on the top of the board? Or both?

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.
 
I don't have the knowledge to know if it does this or not. I'm guessing.
The Typhon doesn't seem to know what day, month, or year it is.

If the date function worked then variables could be introduced into the program allowing the light simulation to change from day to day.

You are correct, the typhon has no clue what the date is, if it did, the "over midnight" programming I did last summer would not have been so troubling. The reason it's got no clue is because we never actually allow it to be set. All we actually do(IIRC) is set a clock counter and let it start ticking. I don't have the code infront of me for the whole thing so I could be wrong, but this is what I recall.
 
The rtc is already tracking date info, you just have to write code to get it and use it how you want.

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