Arduino pros needed for 'simple' project!

logan74k

Well-Known Member
RPF PREMIUM MEMBER
I've recently acquired this neato hibernation pod from the love-it-or-hate-it film Passengers, and working to get the electronics back up and running.

20170324_172525.jpg

20170326_132436.jpg

All the wiring was unceremoniously cut and left without power supplies or documentation. Luckily they're pretty straightforward LED strings and a set of fans. There are 4 independent lights which I've figured out the voltages for, 5 if you count the fans. What I'd like to do is get a system set up which will turn on/off the circuits in sequence, preferably with some dimming effects, maybe add a sound if we're feeling fancy.

I imagine an Arduino is the tool for this job, what I need is some good advice and help from somebody who knows what they're talking about! I've done lots of simple LED wiring jobs but nothing with a controller. Please pop in for any clarifications or PM me if you're interested in helping out.
 

Attachments

  • 20170324_172525.jpg
    20170324_172525.jpg
    1.2 MB · Views: 111
  • 20170324_172525.jpg
    20170324_172525.jpg
    3 MB · Views: 109
Good news: that's pretty trivial.

Unless you want to get into the unnecessary (here) complexities of multiplexing, you just need to hang the lights off of 4 Arduino PWM pins, everything else can be done in code. You'll need to use some cheap MOSFETs off of the outputs, so that your weeny little Arduino signal can power a full LED string at high frequency, but other than that, it's super straightforward.

A dimming cycle could be set up as its own function, so you'd have

void dimCycle() {
int x = -1;
for (int i=255, i>=0 || i<=255 , i+x) {
analogWrite(i, 6);
if (i==0) x = 1;
delay(20);
}
}

The 6 is the pin number, just an example here. Basically it just loops down, bringing i to zero, and then the if condition brings it back up when it hits zero. The OR function kicks it back out of the loop once it hits 255, instead of increasing forever and getting stuck. The delay stops the clock for a split second between increments so that it's not all over so quick it doesn't even register. There may be a better way of doing it, I just made this up, but it's an example of the kinds of things that are possible. You don't have to turn it all the way off, either; you could bottom out at half brightness, or whatever, just by changing the condition values.

But yeah, instead of setting up a dimming cycle at specific times, you can now call the dimCycle() function off the back of say, a random number generator and timer, or something, and also have it mapped to physical external buttons, and anything else you want.

It would get more complex if you wanted multiple lights to be on a dimming cycle at the same time, because for this dimming function we'd jump out of the global counting frame into this for loop until it was done; you'd need to add all four outputs, plus globally-declared boolean flags, possibly plus interrupts, to this same function- even the same for loop, since you'd need to run it as a multiplexed 1x4 matrix- if you wanted simultaneous and/or especially asynchronous dimming. It would slow down too, of course, since you're limited by chip clock, but it probably wouldn't be too noticable on a 16MHz chip.

Simple random timer and random string selector to trigger the simple dim or a quick off-on on any one of the four at arbitrary times, though? Pretty easy.
 
Last edited:
Awesome input sir and much appreciated! The wheels are turning.

How many orders of magnitude more complex is it if we did dim more than one output at once? Is it like, an hour of work vs a day?

Is this a job well suited to a plain vanilla Arduino with MOSFETs or is there any specialized version or extra hardware that would make it more robust?

Would controlling the sequence start be much more complex if the switch were, say, a motion sensor? What if two circuits were always on at say 20% brightness, and the switch activation brought them up to 100% and turned on the other two circuits? I apologize for the nebulous goal here, I'm deciding what to shoot for based on whether or not it will be a nightmare for a coder to write up!
 
That depends. Dimming more than one light simultaneously, even in randomised groupings, isn't more difficult at all, just a little more work adding extra lines in. Dimming more than one output simultaneously AND asynchronously (that is, the actual dimming sequences start at different times for different lights, and those dimming sequences overlap) is at least a couple orders of magnitude more complex. Instead of calling a function to do a thing at a certain time from a simple main timing thread, you're mashing everything together into one big timing-logging-randomising-refreshing routine, almost like a teeny tiny operating system. So yeah, you're talking a day or two, vs an hour or two, even with clean modular code.

I'd just go with the 16MHz UNO and MOSFETs. I can't think of anything else that would improve or simplify that setup, so just go with what's easily acquired and assembled.

Any kind of switch or potentiometer or whatever can be added in just fine, as long as it's easily readable by the board. The only difference what you add to the system is going to make is whether you can use continuous polling (your main routine just says "hey [input[n]], have you changed state/detected anything yet?" over and over into infinity, before triggering something else) which your above example would be fine with, or if you have to use interrupts, where your main thread can be doing something, then maybe trigger something else, and then SOMETHING HAPPENS and you trip the interrupt pin and it bounces the code into some other subroutine (ie. the Interrupt Service Routine) regardless of what was going on.

Polling is quicker and simpler, but it requires a very small set of possible states (on/off of 1-3 switches, a pot, something like that) that change state for a period of time (like, at least in the tens of miliseconds) to feel responsive. Interrupts require less care up front, but you have to think more about what'll happen when normal operation resumes.

So, realistically, you can do just about anything as long as it's reasonably constrained and moderately linear- you're talking about a microcontroller, not a microprocessor. The only question is how much you're willing to pay/owe favours for. :p The scenario you describe there is just about perfect in scope for a single microcontroller to handle
 
This thread is more than 6 years old.

Your message may be considered spam for the following reasons:

  1. This thread hasn't been active in some time. A new post in this thread might not contribute constructively to this discussion after so long.
If you wish to reply despite these issues, check the box below before replying.
Be aware that malicious compliance may result in more severe penalties.
Back
Top