My DIY Netduino Controller and Multi-channel Multi-chip LED Cannons

[iced98lx]

uploadfromtaptalk1368926346694.jpg

Power strip wired.

[rott]

iced very cool build what kind of power strip is that. got a link for it?

[bigguyuk]

is it just controllable via relays or is there a manual over ride ?

[iced98lx]

Originally Posted by rott

iced very cool build what kind of power strip is that. got a link for it?

http://www.amazon.com/gp/product/B00...=r601000000-20

Originally Posted by bigguyuk

is it just controllable via relays or is there a manual over ride ?

So with the sainsmart relay's you have some options. They provide a 'normally open' and a 'normally closed' connection for each relay. So in my case two of my outlets (7 & 8) are 'normally closed' - meaning that the outlets are ACTIVE without me doing anything and the relay would turn them off. I used those for my return pump(s) so that if the controller were to have an issue the pumps would run. I also wired the relay after the toggle switch, so you can manually override the relay by flipping the toggle off. If you wired them all normally closed the power strip would function just like normal until you activated a relay to open the circuit.

I have 1->6 normally open, so the outlet is off until I activate it via the relay.

My ATO solution is working great except I sucked up some sand with my aqualifter and now it's no longer pumping. New one ordered and will clean out the ATO container better.

[bigguyuk]

Thanks dude for the reply

[iced98lx]

got some fade methods written doing sunrise, sunset, twilight right now. Not the best solution but it is working. Seems like I have a possible code twitch though where it was not listening to the ATO float switch until I connected to debugging.

Might have to be careful to restart the board after I stop debugging to make sure things happen properly. got a couple shift registers in the mail the other day, one for driving all 8 of the relays and one that I will chain on to drive 8 LED's to indicate the status of the relay's.

[BeanAnimal]

I have some existing .net code that I wrote to calculate acutal solar and lunar events, along with a complete GUI for windows. While the actual calcs will run on the micro, my goal is to leave them on the PC and use it as a programmer for the micro (wifi, ethernet, zigbee, whatever). I am just not sure if I want to release the code, or in what form....

In any case, let me know if you need any help. I don't have a NETDUINO yet, but have been messing with Mikrobasic and an Arm M3... ready to toss it in the trash and buy the NETDUINO. While Mikrobasic is not bad, it simply light years behind visual studio and nohwere near as comfortable as BASCOM-AVR (my prefered IDE for AVR micros)

[iced98lx]

Originally Posted by BeanAnimal

I have some existing .net code that I wrote to calculate acutal solar and lunar events, along with a complete GUI for windows. While the actual calcs will run on the micro, my goal is to leave them on the PC and use it as a programmer for the micro (wifi, ethernet, zigbee, whatever). I am just not sure if I want to release the code, or in what form....

In any case, let me know if you need any help. I don't have a NETDUINO yet, but have been messing with Mikrobasic and an Arm M3... ready to toss it in the trash and buy the NETDUINO. While Mikrobasic is not bad, it simply light years behind visual studio and nohwere near as comfortable as BASCOM-AVR (my prefered IDE for AVR micros)

The eventual plan here is to load the current 'weather' (light, possibly pump flow profiles) from a webserver / PC on the network. That being said, you have to have good ways of fading from one setting to any other setting, or just using the fading function in whatever is managing to play out the weather pattern. Right now I've got a very simple function that just takes where you want to go, checks where it is, and takes in how long you want to take to get there. Does the simple division and away you go. Obviously this could be light years better by having dynamic step size (does it change every 1 second, every .25 seconds, etc) to get it good smooth. Obviously there is a limitation when you try to stretch small changes over large time gaps. Level 0 to level 5 over ten minuets is... rough. my method gets there quickly, since it requires at least an increas of '1' level every second.

It's.... a quickly built solution.

I look forward to much more programming, to be honest. I do love the Netduino, the N+2 has been great fun to play with and really made this project easier than it could have been. I'll be ordering a 2nd one to do development with once the current is driving a tank full time.

[iced98lx]

For your amusement, here is the code that does it currently. Helps to note that the controller it's controlling using 'setPWM' can control 16 channels but my lights are built in pendants with 5 channels in each pendant. Because of this I group them and let you set 5 channels at a time, and specify offset (you'd put 5 to control pendant #2, 10 to control pendant #3 etc). I started by creating a new light object for each 5 channels but that is messy. Eventually I'll add ability to specify and change one color on all 3 pendants, etc etc.

Plus a better fade method... Originally it actually took time * 4 and looped every 250ms vs 1000.

   public void fadeTo(int ch1, int ch2, int ch3, int ch4, int ch5, int seconds, int offset=0)
        {
            int step1 = (int)Math.Ceiling((double)(Math.Abs(this.off[0 + offset] - ch1)) / (double)(seconds));
            int step2 = (int)Math.Ceiling((double)(Math.Abs(this.off[1 + offset] - ch2)) / (double)(seconds));
            int step3 = (int)Math.Ceiling((double)(Math.Abs(this.off[2 + offset] - ch3)) / (double)(seconds));
            int step4 = (int)Math.Ceiling((double)(Math.Abs(this.off[3 + offset] - ch4)) / (double)(seconds));
            int step5 = (int)Math.Ceiling((double)(Math.Abs(this.off[4 + offset] - ch5)) / (double)(seconds));
            while (seconds > 1)
            {
                    if (this.off[0 + offset] > ch1)
                    {
                        this.setPWM((byte) (0 + offset), 0, (ushort)(this.off[0+offset] - step1));
                    }
                    else
                    {
                        setPWM((byte)(0 + offset), 0, (ushort)(this.off[0 + offset] + step1));
                    }
                    //ch2
                    if (this.off[1 + offset] > ch2)
                    {
                        this.setPWM((byte)(1 + offset), 0, (ushort)(this.off[1 + offset] - step2));
                    }
                    else
                    {
                        this.setPWM((byte)(1 + offset), 0, (ushort)(this.off[1 + offset] + step2));
                    }
                    //ch3    
                    if (this.off[2 + offset] > ch3)
                    {
                        this.setPWM((byte)(2 + offset), 0, (ushort)(this.off[2 + offset] - step3));
                    }
                    else
                    {
                        this.setPWM((byte)(2 + offset), 0, (ushort)(this.off[2 + offset] + step3));
                    }
                    //ch4
                    if (this.off[3 + offset] > ch4)
                    {
                        this.setPWM((byte)(3 + offset), 0, (ushort)(this.off[3 + offset] - step4));
                    }
                    else
                    {
                        this.setPWM((byte)(3 + offset), 0, (ushort)(this.off[3 + offset] + step4));
                    }
                    //ch5
                    if (this.off[4 + offset] > ch5)
                    {
                        this.setPWM((byte)(4 + offset), 0, (ushort)(this.off[4 + offset] - step5));
                    }
                    else
                    {
                        this.setPWM((byte)(4 + offset), 0, (ushort)(this.off[4 + offset] + step5));
                    }
                    Thread.Sleep(1000);
                    //Debug.Print(this.off[0 + offset] + " - " + this.off[1 + offset] + " - " + this.off[2 + offset]);
                seconds--;
            }
            setPWM((byte)(0 + offset), 0, (ushort)(ch1));
            setPWM((byte)(1 + offset), 0, (ushort)(ch2));
            setPWM((byte)(2 + offset), 0, (ushort)(ch3));
            setPWM((byte)(3 + offset), 0, (ushort)(ch4));
            setPWM((byte)(4 + offset), 0, (ushort)(ch5));
        }

when it gets to a value early with this method it just waffles back and forth very slightly for the duration of the fade, not the worst.

[BeanAnimal]

So consider this....

We calculate (for a given spot on the globe)
astronomical, nautical and civil twilights, sun rise and set, and mid day.

We choose to leave those events as calculated, or offset those that we wish. We then assign an output power level to each event. If we graph these points, we end up with a curve for each channel, time along the x axis and power along they y axis.

From there we can derive the equation that connects any 2 sets of points (using curve fitting if we wish). Those finite equations define the instantaneous power level at any given time... In other words we use time and solve for power. So via a timed event (lets say once per second per channel) the output power for the channel is calculated based on the equation for that portion of the curve and the output level is set accordingly. That is, we are not calculating a ramp, and instead we are calculating the proper output at any given point in time.

Does that help?

[iced98lx]

Originally Posted by BeanAnimal

So consider this....

We calculate (for a given spot on the globe)
astronomical, nautical and civil twilights, sun rise and set, and mid day.

We choose to leave those events as calculated, or offset those that we wish. We then assign an output power level to each event. If we graph these points, we end up with a curve for each channel, time along the x axis and power along they y axis.

From there we can derive the equation that connects any 2 sets of points (using curve fitting if we wish). Those finite equations define the instantaneous power level at any given time... In other words we use time and solve for power. So via a timed event (lets say once per second per channel) the output power for the channel is calculated based on the equation for that portion of the curve and the output level is set accordingly. That is, we are not calculating a ramp, and instead we are calculating the proper output at any given point in time.

Does that help?

Yea, it makes sense, have a few equations of various 'curves' you want, find the point you'd be at after you set your end point based on total time. I do wonder how processor intensive the math would be for the N+2.

[iced98lx]

Obviously the most basic curve could just be a strait line.

[Gorgok]

Originally Posted by iced98lx

Obviously the most basic curve could just be a strait line.

This, and the above stuff, is what i do on my control. I use 11 points or something like that to make a pseudo curve, where the lines between points are in fact just lines. I set those (though not based on anything as fancy as BeanAnimal, just what worked for me), but when the program runs it calculates the current times power from the line (finding the previous and next points in time, thus the slope of the line). This way it also resumes the correct light level no matter what time it is in case of a shutdown or me messing with the lights for other purposes.

The code itself i think is a mess, and each time i go to clean it up i get annoyed and give up since it works =C. But basically it cycles through the channels (0-10) then for each channel through time (points) until it finds a point after the current time and saves those values. Then it saves the previous point values and uses those in the slope calculation.

for (unsigned int channelIndex = 0u; channelIndex < lightPWM.size(); ++channelIndex){
	Json::Value channel = lightPWM[channelIndex];
	int ii = 0u, stepTime[2];
	double stepPWM[2];
	Json::Value step = channel[ii];
        //Find next point
	while (true){
		stepTime[1] = (step[0u].asInt() / 1000 - getOff());
		stepPWM[1] = step[1].asDouble();
		if (stepTime[1] > timeNow)
			break;
		step = channel[++ii];
	}
        //Assign previous point
	if (ii == 0)
		step = channel[lightPWM.size()];
	else
		step = channel[ii-1];
	stepTime[0] = (step[0u].asInt() / 1000 - getOff());
	stepPWM[0] = step[1u].asDouble();
        //Calculate current intensity
	double pwmNow = ((timeNow-stepTime[0]) * ((stepPWM[1] - stepPWM[0]) / (stepTime[1] - stepTime[0])) + stepPWM[0]);
        //Modify intensity to 12-bit and gross dimming
	uint16_t off = pwmNow * 40.95 * (tempDim / 100.0);
	i2cPWM->setPWM(DEVICE_ADDR, channelAssignment[channelIndex], off);
}

[BeanAnimal]

Try it a different way:

You already have fixed points so a logic statement can be used to determine the current line segment and thus the power at that time. Each line segment has a fixed slope (y1-y2)/(x1-x2) that can be calculated based on the preset points, as can the Y intercept (b). Likewise the equation can be calculated beforehand due to the preset points. So instantaneous power level is simply a matter of finding what line segment you are in. That is also easy because time (X) is already given and we know the fixed X points.
PSEUDO CODE:

'currentTime = x
'outputPower = y
'timeA, timeB = x points
' 
IF currentTime BETWEEN 0 and timeA then
     outputPower=segment1Slope*currentTime+b1 
Else if currentTime BETWEEN timeB and pointB then
     outputPower=segment2Slope*currentTime+b2
Else if
     etc.
END IF

[iced98lx]

Keep the dimming discussion going, guys but I wanted to note that I allowed my ATO to function un-assisted for the first time this morning (when my new pump arrived). I know this isn't much of a big deal for most, but watching it go for the first time was very satisfying. I had to set it to wait for 2 seconds vs 1 while filling due to how slowly the aqualifter pumps, but overall it worked great.

[Gorgok]

Not sure if you meant that for iced98lx or me, BeanAnimal. But, for how my stuff is setup that would make it more complicated (i'd have to have yet another file read with these values), as my light PWM setting thing is its own little program that runs through once and dies, over and over... But, i am also running a BeagleBone (though not the fancy new one) with over 4 times the processor clock speed of the N2 and code is in C/C++ instead of C#.

I did get curious though, about speed... i know from experience my program is 'fast enough', even though it reads 3 files, finds and sets the intensity for 10 channels, and records those intensities into another file (for display), but i didn't really know how fast. I would have said ~1 second start to stop. I ran it with the time command in linux and got this:
real 0m0.134s
user 0m0.040s
sys 0m0.060s
Basically... i don't really think it matters if it were faster to not do the calculations each time =D. Even then, it may not be as i would probably have to store them in another file, parse that, etc.... Maybe i could store them in the same file i already use though, and calculate them when i change them. I might just have to look into that.

[BeanAnimal]

Gorgok:

At startup the schedule parameters are loaded into memory. That is, the slope, B component and X points for each channel would be loaded into global variables (an array even). Your PWM loop simply solves for Y for each channel, as many times a minute as you wish based on your timer, an int, or you main game loop....whatever

If the instantaneous Y component is stored as well, then that global variable can be used for display or in the logging output stream.

I am not trying to get you to change your code, just offering thoughts. Beaglebone = cool hardware. However, I am not a C or Java fan... at all. Moving from AVRs to ARMs... is like moving from a single engine cesna to an FA-18 fighter. You may have an F-22, but we are in the same airspace

[iced98lx]

What I think I'm taking away here Bean is that I will likely change up the way I'm programming light profiles.

Instead of saying "at time X be here, time Y be here and time Z be here, now use this fade method in between"

I'm going to create a full 15 hour curve for each channel, call that a day, and use the equation of the curve and current time to figure out exactly where each channel should be every time i loop over the light set function.

I'll probably create multiple days (bright#1, bright#2, cloudy#1, cloudy#2 etc) and randomly choose a day when the time comes to start turning on the lights.

This should work well as long as my curves are smooth enough and I check power often enough to avoid bigger jumps in power. (gotta have everything be smooth and pretty )

Now to open my brain, plot some curves and work on those equations. It's been a while since I've done any of that math!

[DrewPalmer04]

Some very nice work going on in this thread. I'm just finishing up my home automation system with the arduino mega 2560 and Sainsmart 16 relay. I noticed your relays at the top of this page. Any thoughts of modes for automated/manual relay overrides? I'm about to embark on this part of my coding

I plan to do:
Auto == 0
Manual ==1
Sort of thing for overrides. Then some form of logic for manual to jump back to auto mode once I turn off the overrides. Fun, head banging, times to be had :P

[iced98lx]

Originally Posted by DrewPalmer04

Some very nice work going on in this thread. I'm just finishing up my home automation system with the arduino mega 2560 and Sainsmart 16 relay. I noticed your relays at the top of this page. Any thoughts of modes for automated/manual relay overrides? I'm about to embark on this part of my coding

I plan to do:
Auto == 0
Manual ==1
Sort of thing for overrides. Then some form of logic for manual to jump back to auto mode once I turn off the overrides. Fun, head banging, times to be had :P

I've got the relay's mostly set up as 'default off' with a couple 'default on' as if the system is having a problem (or i'm working on it) I want those systems on. I do have it so that any relay can be overridden by the switch on the power strip, so I get a final manual line of control.

With the way the .net framework and C# operate I get a static object I can manipulate from any of my routines. I will have a set of 'modes' that do have some sweeping control ('feed' mode might override several outlets controlling pumps to off, or even PWM outputs if I have fancy pumps) and part of that is either looking at the status of that mode, or set up a custom object for my relays that lets me arbitrarily set those from any code, but the actual set method will handle looking at all the things that might 'override' the possiblity of switching it on.

Example:
During feed mode (quiet pump) a weather event may happen that would make a pump turn on, during feed mode that will not happen until after feedmode is off.

Does that help/clarify? These complex areas are where the .netMF pays off, as I get to leverage a lot of bits Arduino doesn't.

[BeanAnimal]

Drew... way off scope here, but I have built an HOA box (Hand Off Automatic) for manual control. While I like the idea of automation, I also like having FULL manual control that has NOTHING to do with automation.










So each device can be controlled by digital logic (Auto) or Manul (ON) or Off. The original design (much simpler) fed logic voltage to the HOA switches and they turned the relays ON or OFF or passed through the logic from the controller. While this would work, I did not like the idea of the relay being the point of failure (mechanical or SSR). Much of the idea of (ON) was to be able to turn on a device if the relay or logic failed....

I.E.: I am out of town and the tank sitter calls and says the skimmer is not running. I can't diagnose a code issue or electronic failure over the phone with a tank sitter... so "Flip the switch labled SKIMMER FEED PUMP" to ON... "

That means that each HOA switch is wired to the 120V receptacle it controls. ON bypasses the RELAY and AUTO puts the relay (mechanical or SSR) in-line. Off cuts power to the receptacle.

Note the GFCIs in the box are not used for devices, but rather the GFCIs that feed each of the 6 "groups" of devices.

PROS and CONS should be ovvious... but the all digital HOA box would have cost maybe $200-$300 to build. I have 4-5 times that in the line level box... I throw up in my mouth every time I think about it.

Sorry for the Hijack here Iced.

[iced98lx]

Originally Posted by BeanAnimal

Sorry for the Hijack here Iced.

No apologies needed this all has to do with the original intent of the thread.

"I'm crazy and want to spend way more money and 10x as long setting up a controller vs using one off the shelf"



That's a saweet box. I'd Love to have an auto/on/off setting for each relay though I don't think my solution would be as elegant as yours. I am working on a 'control center' that has my LCD integrated, with LED's for each outlet and some other indicators.

[BeanAnimal]

I could never settle on a "controller" topology and am glad I didn't design the system around it now. I am still bouncing back and forth between a PC, ARM or multiple independent controllers for each function.

In the case of individual modules they could communicate at a high or low level (as complex as RS485, I2c or somehting, or as simple as specific logic pins used to signa feeding modes, or whatever). That part keeps changing. In fact, I was set to go away from Atmegas, backto central PC control when I stumbled upon ARM via Mikrobasic or VB.NET Micro Framework.

In 10 years of working on "this" project. I have spent enough to buy 50 off the shelf controllers... .and I have yet to really automte anything! In fact, the longer I fiddle with this stuff, the less likely I am to automate anything but the lights and simply data log stuff. I have no idea why I would want any of my pumps automated, but I built the system to do it

[iced98lx]

was a little concerned that the ATO was running for a few seconds every hour it seemed during the day:

Pump Running 05/23/2013 08:05:30
Pump Turns Off 05/23/2013 08:05:42
Pump Running0 5/23/2013 08:58:49
Pump Turns Off 05/23/2013 08:58:59
Pump Running 05/23/2013 09:24:50
Pump Turns Off 05/23/2013 09:25:04
Pump Running 05/23/2013 09:51:28
Pump Turns Off 05/23/2013 09:51:40
Pump Running 05/23/2013 10:20:56
Pump Turns Off 05/23/2013 10:21:08
Pump Running 05/23/2013 10:50:20
Pump Turns Off 05/23/2013 10:50:44

so I checked my salinity quick this morning, 1.026, just where I set it. VERY happy with how this is going. Have used about 1/2 gallon of water in about a 24 hour period.

[iced98lx]

Originally Posted by BeanAnimal

I could never settle on a "controller" topology ...

I bought a reef angel originally, sold it after I realized I didn't want to learn that language. Looked at phidgets and PC based, but couldn't' get over the reliability problems of a PC based system when running windows. It probably would be more stable than I needed, but I convinced myself otherwise.

The netduino came up as I was searching for a microcontroller with more power (beagle bone, rasberry pi etc also cropped up) the idea of a managed code environment really caught me. Control a few things and log lots of things? GREAT! Then the slipperly slope started: "I'll buy 8 relays because they're cheap but I wont' use them all..." .... "I'll buy a shift register and use all 8 but only because it's pretty cheap.." and so on.

Still wish someone made an SPI shift register board with an ethernet connector as the out put, and a relay enabled powerstrip with an ethernet connector for the triggers.

So, started with temp, added lights, relays and now I'm working on the LCD.