Buzzer oddity since 0.9.8
Buzzer oddity since 0.9.8
Hey all,
I don't recall library version 0.9.6 doing this, but 0.9.8, and 0.9.9 do:
I have my buzzer connected. Anytime I manually turn on ports 2, 3, or 4.. my buzzer sounds (low, but it's noticable) The odd thing is, if the ports are on and in auto mode.. all is fine. it's only when I manually turn them on.
my code:
https://github.com/palmerit/reefangel/b ... effs90.ino
I've not been able to track this down, and would love some feedback.
I don't recall library version 0.9.6 doing this, but 0.9.8, and 0.9.9 do:
I have my buzzer connected. Anytime I manually turn on ports 2, 3, or 4.. my buzzer sounds (low, but it's noticable) The odd thing is, if the ports are on and in auto mode.. all is fine. it's only when I manually turn them on.
my code:
https://github.com/palmerit/reefangel/b ... effs90.ino
I've not been able to track this down, and would love some feedback.
Re: Buzzer oddity since 0.9.8
That's the PWM override I put in.
https://github.com/curtbinder/ReefAngel ... 8d9e328829
Basically it scans all ports to see if you are overriding a light port.
This is to set a value other than 0 to the PWM ports for led lights when you override a light port.
You could set ReefAngel.LightsOnPorts=0 and it won't buzz anymore.
https://github.com/curtbinder/ReefAngel ... 8d9e328829
Basically it scans all ports to see if you are overriding a light port.
This is to set a value other than 0 to the PWM ports for led lights when you override a light port.
You could set ReefAngel.LightsOnPorts=0 and it won't buzz anymore.
Roberto.
Re: Buzzer oddity since 0.9.8
Thanks Roberto.
I must be tired. Looking at the git commit logs (and possibly diffs) should have been my first course of action. Thanks a ton.
I must be tired. Looking at the git commit logs (and possibly diffs) should have been my first course of action. Thanks a ton.
Re: Buzzer oddity since 0.9.8
That change worked perfectly.
I'm not quite sure I understand the context or purpose behind that code change though. What exactly is the use-case you envision, where that commit would be handy/useful?
I'm not quite sure I understand the context or purpose behind that code change though. What exactly is the use-case you envision, where that commit would be handy/useful?
Re: Buzzer oddity since 0.9.8
For those that use LED lights, turning the relay on by using any app or portal doesn't actually turn the lights on.
It only energizes the driver. There is a need to change the PWM port to something other than 0.
That feature is intended to change the value of the PWM ports to the internal memory setting when the a relay that is set on LightsOnPorts is masked on.
This is for cases like visitors come by during your lights off period and you just want to showcase the tank by turning the lights on momentarily.
It only energizes the driver. There is a need to change the PWM port to something other than 0.
That feature is intended to change the value of the PWM ports to the internal memory setting when the a relay that is set on LightsOnPorts is masked on.
This is for cases like visitors come by during your lights off period and you just want to showcase the tank by turning the lights on momentarily.
Roberto.
Re: Buzzer oddity since 0.9.8
Ahh, ok. That makes sense.
I'll be playing with that pretty soon. I'm planning a DIY LED build.
Speaking of LED's.. can a single channel on the PWM expansion module signal multiple drivers? Lets say I have 2 or 3 drivers all for th same color.. can I send the PWM signal from one channel to all three driver? or is there a resistance/impedance component to consider? (one driver per channel)
I'll be playing with that pretty soon. I'm planning a DIY LED build.
Speaking of LED's.. can a single channel on the PWM expansion module signal multiple drivers? Lets say I have 2 or 3 drivers all for th same color.. can I send the PWM signal from one channel to all three driver? or is there a resistance/impedance component to consider? (one driver per channel)
Re: Buzzer oddity since 0.9.8
Each channel can handle 40mA max.
Depending on which driver you pick, you will have to consider how much they draw.
If I'm not mistaken, Meanwell drivers pull about 3.5mA at 100%PWM. So you could easily put 3 drivers into a single channel.
Depending on which driver you pick, you will have to consider how much they draw.
If I'm not mistaken, Meanwell drivers pull about 3.5mA at 100%PWM. So you could easily put 3 drivers into a single channel.
Roberto.
Re: Buzzer oddity since 0.9.8
Although, that does make me wonder one additional thing..
If the port being energized doesn't actually turn the lights on, and it's the signal from the PWM channel.. Why wouldn't people simply have those drivers plugged into an 'always on' outlet, and turn the PWM channel from 0% to, whatever they want to showcase the tank with. Seems like a waste of a controlled power port in that case.
Of course, having no experience with it.. I may be missing something simple or obvious.
If the port being energized doesn't actually turn the lights on, and it's the signal from the PWM channel.. Why wouldn't people simply have those drivers plugged into an 'always on' outlet, and turn the PWM channel from 0% to, whatever they want to showcase the tank with. Seems like a waste of a controlled power port in that case.
Of course, having no experience with it.. I may be missing something simple or obvious.
Re: Buzzer oddity since 0.9.8
You could do that.
A little bit trickier to do though.
Some of the new drivers enter hibernation state when PWM is 0%.
The reason I like to place them into a controlled port is that even on hibernation or minimum draw, it is still drawing some power. Some may say it is negligible compared to when they are on, but still...
You can't easily change the PWM value when you are using PWMSlope or PWMParabola functions.
You would need to come up with a logic to tell the controller that you want to override the PWM function.
By using the app, you are limited to how you can interact with the controller.
The logic I created was to override the functions when a relay was masked on.
Can you think of another logic that would also work?
I'm more than happy to try to implement it
A little bit trickier to do though.
Some of the new drivers enter hibernation state when PWM is 0%.
The reason I like to place them into a controlled port is that even on hibernation or minimum draw, it is still drawing some power. Some may say it is negligible compared to when they are on, but still...
You can't easily change the PWM value when you are using PWMSlope or PWMParabola functions.
You would need to come up with a logic to tell the controller that you want to override the PWM function.
By using the app, you are limited to how you can interact with the controller.
The logic I created was to override the functions when a relay was masked on.
Can you think of another logic that would also work?
I'm more than happy to try to implement it
Roberto.
Re: Buzzer oddity since 0.9.8
No sir, no suggestions or alternative ideas. I'm just trying to wrap my head around it before I spend $400 in parts to do my LED kit.
Any suggestions I come up with now would be purely hypothetical. I'll wait till I have the LED kit, and see what ideas I come up with!
Thanks for all of the help and insanely fast replies!
Any suggestions I come up with now would be purely hypothetical. I'll wait till I have the LED kit, and see what ideas I come up with!
Thanks for all of the help and insanely fast replies!
-
- Posts: 289
- Joined: Wed May 16, 2012 9:52 pm
Re: Buzzer oddity since 0.9.8
This seems exactly what I would like to do. I dont have my LED drivers using a relay box port those are at a premium in my plans already. It only took me until the second day of having my light schedule running that I realized that I need to be able to over ride any/all pwm/analog ports for max flexibility. The PWM settings and that this does not seem to be an easy task. I have not peeked at any of the coding so there may be a reason what I am about to type is utter BS and impossible but couldn't a variable just be set for each analog/pwm channel and when any function (lighting/whatever it shouldnt matter) is running that code just modifies the variable and then that variable value is what is actually used by the hardware? Check if an override flag has been flipped if the flag is flipped then exit the current lighting function and go into the Override function, maybe even get some input from the user (pwm value up/down arrows) as long as the override flag is set stay in the override function but when it is flipped back off go back to the regular lighting function? I envision this like the overrides for the relay boxes but with an up/down arrow to allow manual feedback on what you want until the override is turned off.rimai wrote:You could do that.
A little bit trickier to do though.
Some of the new drivers enter hibernation state when PWM is 0%.
The reason I like to place them into a controlled port is that even on hibernation or minimum draw, it is still drawing some power. Some may say it is negligible compared to when they are on, but still...
You can't easily change the PWM value when you are using PWMSlope or PWMParabola functions.
You would need to come up with a logic to tell the controller that you want to override the PWM function.
By using the app, you are limited to how you can interact with the controller.
The logic I created was to override the functions when a relay was masked on.
Can you think of another logic that would also work?
I'm more than happy to try to implement it
Nick
180G FOWLR
20GH QT#1
29G QT#2
20GH QT#1
29G QT#2
Re: Buzzer oddity since 0.9.8
Hi Nick,
The latest libraries already do that for the standard channels only though.
If you override a port that was assigned to lights, it will override the PWM to whatever is on the internal memory LEDPWMActinic and LEDPWMDaylight.
You could then use any app to change the memory settings to whatever you want. This would give you exactly what you are asking for.
You can even use the Client app sliders to change the setting. Those sliders do exactly that. They change that memory location. Or you can use the Java Status app or even your browser.
If you want to do the same thing for your dimming expansion channels, you will need to a code like this:
The latest libraries already do that for the standard channels only though.
If you override a port that was assigned to lights, it will override the PWM to whatever is on the internal memory LEDPWMActinic and LEDPWMDaylight.
You could then use any app to change the memory settings to whatever you want. This would give you exactly what you are asking for.
You can even use the Client app sliders to change the setting. Those sliders do exactly that. They change that memory location. Or you can use the Java Status app or even your browser.
If you want to do the same thing for your dimming expansion channels, you will need to a code like this:
Code: Select all
if ((ReefAngel.Relay.RelayMaskOn & (1<<(Port5-1))) == (1<<(Port5-1))) // If MaskOn, we override PWM to internal memory value
{
ReefAngel.PWM.SetChannel(0,InternalMemory.LEDPWMDaylight_read());
ReefAngel.PWM.SetChannel(1,InternalMemory.LEDPWMDaylight_read());
}
else
{
ReefAngel.PWM.Channel0PWMSlope(0);
ReefAngel.PWM.Channel1PWMSlope(0);
}
Roberto.
-
- Posts: 289
- Joined: Wed May 16, 2012 9:52 pm
Re: Buzzer oddity since 0.9.8
does this require masking a "phantom" relay on the relay box? Any way to just manipulate the PWM ports directly?
180G FOWLR
20GH QT#1
29G QT#2
20GH QT#1
29G QT#2
Re: Buzzer oddity since 0.9.8
Yes, that example was for masking port5, but we can make it so you could use a relay box you don't have.
You could do this:
That will use Port5 on Expansion Box 2
You could do this:
Code: Select all
if ((ReefAngel.Relay.RelayMaskOnE[1] & (1<<(Port5-1))) == (1<<(Port5-1)))
Roberto.