Reef Angel Forum

Posted: **Tue Jan 10, 2012 11:21 am**

Hi All-
SO I am playing with dimming on my PWM expansion module using the RAGen created PWM menu which allows you to select a PWM output for all channels.

A number of people have in the past asked about flickering on PWM outputs of around 10-20 or less. This is typically due to the LED powersupply (if your using MeanWells) dropping current to the point that the voltage required drops below the design limits and the LEDs flicker. This can be fixed by knowing BEFORE hand in your build and MAXING out the number of LED's /string such that you need to adjust the voltage pot on the controller to MAX in order to drive them at the limiting current you desire, which can be at least estimated.

For instance, I have two strings of 12 XP-E LEDs running at 900 mA which requires about 52 V at that current draw which 1 ELN-60-48P power supply can just barely manage. These dim to less than 10% PWM very nicely because I have PLENTY of room on the lower end of the voltage scale as I have MAXED out the upper end. Conversly, I also have 2 strings of 8 XP-G running at 1.4 A each which draw around 25 V but then when I dim them they drop to flicker at somewhere around 25%, in this case its bad because I screwed up and at 100% PWM I am barely above the minimum rated Voltage ouput for the controller and when it dims it drops below what the power supply can manage and the lights flicker. I am fixing this...

BUT... in PWMSLOPE (or what I assume is happening) your basically calculating a slope from the start and end PWM settings over the desired time and then just ramping at a calculated increment every X time.
Since NO PWM string can really run to ZERO, and everyones build will have a different cut off PWM dim for flicker (dependent upon factors I discussed and others) it makes more sense to use a function that takes into acount the Y intercept at the partical Zero setting for PWM dimming.

I.E. If you simply allow users to input the lowest PWM setting that enables reliable light without flickering and then calculate the actual PWM output required by rearranging the equation for a line using the intercept value, people could choose PWM output settings that span 0-100 of their usable range and the function would (with knowledge of the intercept) automatically set each PWM string output to the USEABLE range. This is really VERY SIMPLE but does require that users figure out the lower limit of their PWM dim range for each string (which they must know anyway if they are asking about it).

Its really kinda semantics as the user is modifying every PWMSLOPE function to set the lower limits anyways but by using a line with an intercept then if you wanted to run the cloud function you would NEVER see it flicker because the ZERO set point would always be the lowest real light output setting on the driver, and never drop below that point. It also would save some thinking as you could just set each one to the exact percent brightness value that is available. Nothing would change in terms of the useable PWM output. It may reduce somewhat the confusion some have with this as well as enabling a single line of code to define the intercept value (the real PWM% value required to sustain minimal light output without flickering) and from then on every brightness setting in ANY part of the code would be 0-100% which makes more sense.

Posted: **Tue Jan 10, 2012 11:37 am**

Makes a lot of sense.

Posted: **Tue Jan 10, 2012 11:46 am**

For example.

If you obtain flicker free light at PWM output % of 15
And maximal light at 100%

Your line fit with intercept is

y=1.1767x-17.719

So for 35% usable light ouput the actual PWM% setting should be

x=(35+17.719)/1.1767
which is 44.802

and just to check it... for 100% output of useable light

x=(100+17.719)/1.1767
which is 100.04

Does this make sense....

So if you wanted to ramp from 0-100% light over 600 mins

You would just solve for 0
=17.719/1.1767=15 which is yout PWM start setting which would require output of 38.25 (0-255) to the controller
And your endpoint would be at 100% which is 255 ouput to the controller.

So the slope would just change from 255-38.25=216.75 range over 600 seconds
or 216.75/600=0.36125 change in PWM controller ouput (0-255 set) every second.

No flicker ever- smooth ramping over the entire useable output of the PWM driver + light string combo.

Posted: **Tue Jan 10, 2012 11:55 am**

If I hard code this in, which is what I plan... I would end up not being able to use PWM slope... but I assume something like this might go into the library at some point if enough people think its worth doing... so there is really no problem with me doing this in terms of compute cycles or something on the processer is there? This is where my knowledge fails me completely... it seems like PWM slope is kinda hardwired into PWM output settings for just about everything, so how much work would it be to actually implement this? It seems like I would need to recode the comm to the PWM expansion module to be based upon my calculations... which I was going to kinda do as a test (see thread on using PWM expansion processor) so once thats working, I would have the basis for doing this correct?

Just want to do this the EASY way that hopefully would not get screwed up with further updates to the library and that perhaps others would also use (oh... if anyone who KNOWS how to code does this It will be done in like 5 minutes... this will take me a good bit of time so if someone reading this is going to code it and knows what they are doing I would be happy to borrow... but it sounds like a managable and useful project I would like to take on as a good introduction to coding in this system). Any ideas to keep me from reinventing things and running into trouble?

I assume that if I had it hard coded I could modify the cloud/storm program pretty easily to use it.

Posted: **Tue Jan 10, 2012 12:50 pm**

The PWMSlope does the same thing.
One of the parameters of PWMSlope is the startPWM and another is endPWM.
You could simply choose to start at X percentage. In my case, I choose to start at 15% and end at 50%.
Here is the PWMSlope function. It's defined on ReefAngel_Globals.cpp.

Code: Select all

byte PWMSlope(byte startHour, byte startMinute, byte endHour, byte endMinute, byte startPWM, byte endPWM, byte Duration, byte oldValue)
{
	int Now = NumMins(hour(), minute());
	int Start = NumMins(startHour, startMinute);
	int StartD = Start + Duration;
	int End = NumMins(endHour, endMinute);
	int StopD = End - Duration;

	if ( Now >= Start && Now <= StartD )
		return constrain(map(Now, Start, StartD, startPWM, endPWM),startPWM, endPWM);
	else if ( Now >= StopD && Now <= End )
	{
		byte v = constrain(map(Now, StopD, End, startPWM, endPWM),startPWM, endPWM);
		return endPWM-v+startPWM;
	}
	else if ( Now > StartD && Now < StopD )
		return endPWM;

    // lastly return the existing value
    return oldValue;
}

But if you still feel it really is much better for you to use 0-100%, instead of 15% and 50%, you can always use map() function to convert 15-50 into 0-100 and display the result instead.
It think it's a much easier choice.

Code: Select all

int actualPWM = PWMSlope(10,0,22,0,15,50,60,15);
int convertedPWM = map(actualPWM,15,50,0,100);

Displaying convertedPWM would result in a number from 0-100% even though the actual PWM is 15-50%.

Posted: **Tue Jan 10, 2012 5:27 pm**

Yeah... I did not have time to post back but I was thinking about this a bit and IF I want to use the slope calc Y-intercepts I can just feed that back to the lower limit on the PWM slope function. So its no big deal.

Its totally a potato-potAto argument- just a tiny bit easier to think of in terms of 0-100% capable output. I don't need but a line or two of code to do it this way. Its just how I think.... way to analytical and this way I never have to actually think about what to set PWM to in order to get X% output, just tell it I want X% and it calcs for me- since I have 5 strings and I want perfect dimming this way I will not have to remember all 5 start vals every time I need to code it and just assign them like you suggested....

Reef Angel Forum

PWM slope

PWM slope

Re: PWM slope

Re: PWM slope

Re: PWM slope

Re: PWM slope

Re: PWM slope