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

I haven't tested it yet, but my concern with this implementation is that it would seem to introduce a 1 second delay between initial button presses, so if you aren't holding it down 1 per second is as fast as you can go. I could be wrong.

Introduce another check if the button was "just" pressed (at which point you'd reset your "when was the button first pressed?" variable) and that problem is solved. Actually I bet you could write the logic in a manner that you wouldn't need a second check. You'd just check for that condition in each iteration of the loop. If the button was JUST pressed, increment the variable and record the timestamp. If the button is down but was not JUST pressed, look at current time vs. the timestamp you recorded.
 
dwzm sent me one of the first Typhoon he made. I believe there are some error that may have been corrected related to the PWM header. So please help me understand them. Thanks

The silk screen says
PWM Pinouts
10v 5V
1234 1234
Gnd Gnd

Then to the right are 16 holes for a header. It looks like these are split into 4 as 2 set in the top row and 2 in the bottom row. I could not find labels, but I think these must be JP5-JP8.
First issue if what I said above is correct. JP6 says 10 volts and there is no 10V listed on the silkscreen. Using the lower (header at bottom) pin of U7 which I believe is the output of the regulator I used an ohm meter and determined this is the lower leftfour pins of the header.
Second Issue using the middle pin of U7 as ground these connect to the upper right 4 pins.
Finally I mapped pin 5 of the arduino to pin 1 of the lower right set of 4.

So I think the silkscreen should read.
PWM Pinouts
10PWM 5PWM
1234 .. GND
10V ... 1234
 
I got it, but I still find that description confusing. You must also remember the post where you say that for meanwell's the ground line is toggled and not the 10 volt line.

Thanks for the link
 
Chris, did you make some changes to EEPROMVar? I cant get your recent typhon revisions to compile with the current EEPROMVar version I have.

I don't want to go hacking around to try and make it work without knowing where to look first ;)

Weird. No...I considered trying to change it, but in the end I did not.

This should be standalone. It's the only thing in the project directory.

I did have a separate header file at one point too when I was trying something, but it's gone as well.
 
Weird. No...I considered trying to change it, but in the end I did not.

This should be standalone. It's the only thing in the project directory.

I did have a separate header file at one point too when I was trying something, but it's gone as well.


It may be the only thing in the project directory but it's calling libraries (probably) from your arduino IDE directory.

typhon2:111: error: no matching function for call to EEPROMVar<int>::EEPROMVar()'

tells me something here is not as it seems ;)
 
It may be the only thing in the project directory but it's calling libraries (probably) from your arduino IDE directory.

typhon2:111: error: no matching function for call to EEPROMVar<int>::EEPROMVar()'

tells me something here is not as it seems ;)
Now I see what happened. What I uploaded wasn't what I had compiled and tested. It will compile and upload to the Typhon without saving it. It was one of my attempts to put the EEPROMVar into the struct, which didn't work.

The link now has my current version.

Sorry about that. :D
 
I just put another version up. I changed out the button repeat code only for the override area (doOverride() function) to use a strategy similar to what dwzm outlined above.

Right now it will tick by one at a time for three seconds and then fly by. No screen blanking.

There's one issue that I haven't found a way around yet...because we're tracking by second and not millisecond it's possible that the initial press (uniquePress()) is held down long enough to tick over a second mark and cause the next isPressed() to register as well causing it to move two steps instead of one.

I tried adding a delay() to prevent it, but, depending on the length of the delay, either does nothing or can result in a missed click if the user is trying to do unique presses quickly. Still trying to work this one out, but I thought I'd let you guys take a look if you want as I'll soon be unable to spend much more time on it until Friday.

http://pages.suddenlink.net/chrisfowler99/typhon2.pde
 
Instead of using the currently implemented, RTC-fed time variables to manage the delay for the button presses, I'd rather see us just use the millis() function. It doesn't need to be accurate or relate to "time of day" - we just need a fine-resolution relative measure, which millis() is perfect for.
 
Instead of using the currently implemented, RTC-fed time variables to manage the delay for the button presses, I'd rather see us just use the millis() function. It doesn't need to be accurate or relate to "time of day" - we just need a fine-resolution relative measure, which millis() is perfect for.
That's what I was missing! I knew there had to be something like that and I was staring right at it.

Off to see what I can do with that.

Edit: Ok...uploaded a new version using millis(). Seems to be completely functional, but I've only done it for the override percentage. I think it can be done a little better and I want to see if I can do that before I do the other sections.

My latest version has been updated.
 
Last edited:
and with millis() we can increment it just a little slower than the fastest possible (every time it can loop).. I found that one tick per ~25ms was a pretty good for a fast rate and ~200ms per tick for slow while button held.
 
and with millis() we can increment it just a little slower than the fastest possible (every time it can loop).. I found that one tick per ~25ms was a pretty good for a fast rate and ~200ms per tick for slow while button held.
Exactly. I didn't slow that down, but it would be easy to add in there. Trying to think how ro separate that out into a function to standardize it.
 
extra typhon board

extra typhon board

Anyone order a batch of Typhon boards and have extras? I would like 2 boards if you have them. Let know with a PM, Thanks
 
Hey guys, that EEPROMVar class, is it used as a generic eeprom variable so you can store any size/type of data in eeprom?

If so, I just want to suggest something that I use in the Hydra ("the other controller") firmware:
PHP:
template <class T> uint16_t EEPROM_writeAnything(uint16_t ee, const T& value)
{
    const byte* p = (const byte*)(const void*)&value;
    uint16_t i;
    for (i = 0; i < sizeof(value); i++)
	  EEPROM.write(ee++, *p++);
    return i;
}

template <class T> uint16_t EEPROM_readAnything(uint16_t ee, T& value)
{
    byte* p = (byte*)(void*)&value;
    uint16_t i;
    for (i = 0; i < sizeof(value); i++)
	  *p++ = EEPROM.read(ee++);
    return i;
}

Takes a location and a value, just like the regular read and write methods, but this one can handle any size var.

If EEPROMVar has a different purpose, ignore my comment :)
 
Still learning the Arduino Language and the syntax we choose to use. But I find this awkward to read:
const byte* p = (const byte*)(const void*)&value;
does the compiler not allow
const byte* p = (const byte*)&value;
Is there a reason for the double cast?
 
Please help can't upload typhon board to BatchPCB.com

Please help can't upload typhon board to BatchPCB.com

I added sparkfun eagle library, Eagle keyboard shortcuts and CAM file to Eagle directorys. I am still unable to unload the board. Can someone e-mail me the typhon file already converted to the format that BatchPCB.com uses. That way I can just unload the file and get the ball rolling on making a typhon controller. My email is mtrottie004@yahoo.com. Thanks for the help Marshall
 
so i got a package of stuff and two of the parts say "Attention observe precations for handling electrostatic sensitive devices" any thing i should know about that or do i just take it out and soulder it in place.
 
Back
Top