Code Refactoring: Buzzer/LED goes alarm
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Code Refactoring: Buzzer/LED goes alarm
Hi,
I took the time and refactored some scattered code.
I took all LED and Buzzer codes (BlinkLED, LED-Flasher, LED-Ring, Buzzer,vbat,...) and moved it into "alarms.ino"
This file now holds every alarm and notification handlings.
I removed buzzer beeps from blinkLED() and replaced it with beep_toggle or beep_confirmation to get rid of conflicts in buzzer handling.
Pleas use these variables for buzzer sounds. BlinkLED can now be used exclusive for blionking the onboard LED
I also added the pilotlamp code and made some new chain-defines in def.h to ensure that buzzer is always defined if you use pilotlamp or vbat etc.
This way we get rid of some ansty compiler errors.
It took quite some time to get this mess straight, so please may some of you test the alarm handling?
I took a lot of tests the alst two days and cleamned up all the mistakes I found. I want to merge this into the shared trunk ASAP.
You can find the code here:
https://multiwii.googlecode.com/svn/branches/jevermeister/MWC%202.1%20PilotLamp%20Beta
For a Documentation please visit our official wiki.
It is based on 2.1 release, with my modifications.
If everything is Ok I will merge it to the trunk carefully.
I could not test the LCD beeping, so someone might test if everything is ok.
Thank you for your help.
Nils
I took the time and refactored some scattered code.
I took all LED and Buzzer codes (BlinkLED, LED-Flasher, LED-Ring, Buzzer,vbat,...) and moved it into "alarms.ino"
This file now holds every alarm and notification handlings.
I removed buzzer beeps from blinkLED() and replaced it with beep_toggle or beep_confirmation to get rid of conflicts in buzzer handling.
Pleas use these variables for buzzer sounds. BlinkLED can now be used exclusive for blionking the onboard LED
I also added the pilotlamp code and made some new chain-defines in def.h to ensure that buzzer is always defined if you use pilotlamp or vbat etc.
This way we get rid of some ansty compiler errors.
It took quite some time to get this mess straight, so please may some of you test the alarm handling?
I took a lot of tests the alst two days and cleamned up all the mistakes I found. I want to merge this into the shared trunk ASAP.
You can find the code here:
https://multiwii.googlecode.com/svn/branches/jevermeister/MWC%202.1%20PilotLamp%20Beta
For a Documentation please visit our official wiki.
It is based on 2.1 release, with my modifications.
If everything is Ok I will merge it to the trunk carefully.
I could not test the LCD beeping, so someone might test if everything is ok.
Thank you for your help.
Nils
Re: Code Refactoring: Buzzer/LED goes alarm
good job, thanks.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Thank you,
did anybody had time to test it?
I found a bug while switching to gps but could not find the mistake...
Nils
did anybody had time to test it?
I found a bug while switching to gps but could not find the mistake...
Nils
Re: Code Refactoring: Buzzer/LED goes alarm
Not yet. Wil check around mid of this week. Promise.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Thanks,
I noticed a problem when using GPS,
if the cycle time increases, the patterns go amd, I think I have to overthink mr rc cams routines regarding the delays...
Nils
btw.: I jsut uplaoded new stuff into branch, I included a blinkpattern if the I²C errors rise beyond 100, it will stay on until you unplug the lipo.
I noticed a problem when using GPS,
if the cycle time increases, the patterns go amd, I think I have to overthink mr rc cams routines regarding the delays...
Nils
btw.: I jsut uplaoded new stuff into branch, I included a blinkpattern if the I²C errors rise beyond 100, it will stay on until you unplug the lipo.
Re: Code Refactoring: Buzzer/LED goes alarm
Good work and Thanks Nils for including pilotlamp i will test it as soon im back from holiday
im using the old test code from mr rc cams with some minor changes in blink pattern.
// Tazzy
im using the old test code from mr rc cams with some minor changes in blink pattern.
// Tazzy
Re: Code Refactoring: Buzzer/LED goes alarm
for a system with buzzer and status LED only:
works, but
the status LED goes to constant ON when armed, former blinking of status LED for tilt > 25 degrees is gone.
works, but
the status LED goes to constant ON when armed, former blinking of status LED for tilt > 25 degrees is gone.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
thanks for the feedback.i will take a look into that.
nils
nils
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Hi,
I tested it and my status LED is off while level and starts du blin 1/2 Hz if I tilt the copter >25°.
I have Pilot light enabled.
Will try it with pilot light disabled.
Nils
I tested it and my status LED is off while level and starts du blin 1/2 Hz if I tilt the copter >25°.
I have Pilot light enabled.
Will try it with pilot light disabled.
Nils
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
also w orking with buzzer only :-/
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
taking back everything, I overread "armed" i also have this behavior.
I doublechecked with stock 2.1 and it also shows this behavior, must be a feauture though
I doublechecked with stock 2.1 and it also shows this behavior, must be a feauture though
Re: Code Refactoring: Buzzer/LED goes alarm
the status LED is connected to d13 (on promini ?), so I think we might use it for some more signaling as well.
I have an now retired jussi shield v1.2 and it even has an external LED connected for status signaling.
In effect we could do the same set of stuff via that status LED as we currently do with the buzzer output. I would use one (status led) for illumination with informative feedback (tilt -> blink) and the other (buzzer led ) for warnings. Would be cool if it could be handled by the same code without duplication.
What do you think?
I have an now retired jussi shield v1.2 and it even has an external LED connected for status signaling.
In effect we could do the same set of stuff via that status LED as we currently do with the buzzer output. I would use one (status led) for illumination with informative feedback (tilt -> blink) and the other (buzzer led ) for warnings. Would be cool if it could be handled by the same code without duplication.
What do you think?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Hi,
sounds great,
the blinkLED() routine is pretty scattered throughout the code, so I have to take a deep look into it, and make sure not to collide with the other notifications for tilt>25° init, GPS etc.
A centralised handling via flags, like buzzer, would be great, but it is hard work due to the fragmentation.
I will try my best, but give me some time, as I want to finish PL code first. And I will need serious beta testing, Alex was very unhappy with the butg I commited a day before 2.1 release.
Nils
sounds great,
the blinkLED() routine is pretty scattered throughout the code, so I have to take a deep look into it, and make sure not to collide with the other notifications for tilt>25° init, GPS etc.
A centralised handling via flags, like buzzer, would be great, but it is hard work due to the fragmentation.
I will try my best, but give me some time, as I want to finish PL code first. And I will need serious beta testing, Alex was very unhappy with the butg I commited a day before 2.1 release.
Nils
Re: Code Refactoring: Buzzer/LED goes alarm
your work, so you got to set the timeframe
maybe you can keep the blinkLED() for backwards compatibility. Should save you some work. And it is currently used as informational messaging like 'done', 'step' etc. . So it would still fit
maybe you can keep the blinkLED() for backwards compatibility. Should save you some work. And it is currently used as informational messaging like 'done', 'step' etc. . So it would still fit
Re: Code Refactoring: Buzzer/LED goes alarm
What does this change do?
So the flasher pattern is inverted if the buzzer is on?
Code: Select all
void auto_switch_led_flasher() {
uint8_t seg = (currentTime/1000/125)%8;
if (led_flasher_sequence & 1<<seg) {
switch_led_flasher(!isBuzzerON());
} else {
switch_led_flasher(isBuzzerON());
}
}
So the flasher pattern is inverted if the buzzer is on?
Re: Code Refactoring: Buzzer/LED goes alarm
three issues:
when using LED strips connected to the buzzer output, I found some patterns to be not easily to recognize. Here's my current patterns:
Changing the patterns does change the binary size. I do not see why.
with the LEDpin:
upon powerup it is off,
when arming, it turns on; gives short blinks when tilt angle > 25 deg.
disarm: but LEDpin stays _on_. Is it not supposed to turn off then?
when using LED strips connected to the buzzer output, I found some patterns to be not easily to recognize. Here's my current patterns:
Code: Select all
else if (warn_vbat == 4) beep_code('M','S','M','L'); // beep_code('S','S','L','D'); // <----- battery is at lowest, crash is imminent
else if (warn_vbat == 2) beep_code('M','N','M','D'); // beep_code('S','L','N','D');
else if (warn_vbat == 1) beep_code('M','N','N','D'); // beep_code('L','N','N','D');
Changing the patterns does change the binary size. I do not see why.
with the LEDpin:
upon powerup it is off,
when arming, it turns on; gives short blinks when tilt angle > 25 deg.
disarm: but LEDpin stays _on_. Is it not supposed to turn off then?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Hamburger wrote:three issues:
when using LED strips connected to the buzzer output, I found some patterns to be not easily to recognize. Here's my current patterns:Code: Select all
else if (warn_vbat == 4) beep_code('M','S','M','L'); // beep_code('S','S','L','D'); // <----- battery is at lowest, crash is imminent
else if (warn_vbat == 2) beep_code('M','N','M','D'); // beep_code('S','L','N','D');
else if (warn_vbat == 1) beep_code('M','N','N','D'); // beep_code('L','N','N','D');
Changing the patterns does change the binary size. I do not see why.
It changes the way the subroutines are called. this changes bianry size to. Normal in my opinion.
with the LEDpin:
upon powerup it is off,
when arming, it turns on; gives short blinks when tilt angle > 25 deg.
disarm: but LEDpin stays _on_. Is it not supposed to turn off then?
is the ledpin the same that is onboard the arduino?
I only put the code in a different place, did not change it. :-/
I will check it after my vacation
Nils
Re: Code Refactoring: Buzzer/LED goes alarm
small update:
I uploaded new LED-suitable buzzer patterns for vbat_warnX to _shared. Can you test how these sound like?
About the binary size change: looking at the code I still do not understand the reason but I accept the fact that it does. no problem.
yes, I suppose so. The crius board with promini has an onboard led, but no d13 pin; so I remapped the LEDPIN stuff to A2 with attached transistor&LEDstrips. Should not behave any different from standard led&d13 on an original promini.
don't they all say that
I have no real memory of how older versions treated the onboard led. This is the first time I use the LEDPIN stuff and run external LED strips attached to it. What I described may well be how it always was.
Side note: With intermittent use of LCDconfig menu, I now saw the LEDPIN led turn off when unarming! Strange.
So long as the LEDPIN output is ON while armed (=flying) I am not worried.
With this copter, I use LEDPIN output with LED strips for flight illumination/orientation (red/green/white),
and the BUZZERPIN output with LED strips for signaling (mostly battery related) warnings.
Enjoy your vacation.
I uploaded new LED-suitable buzzer patterns for vbat_warnX to _shared. Can you test how these sound like?
About the binary size change: looking at the code I still do not understand the reason but I accept the fact that it does. no problem.
is the ledpin the same that is onboard the arduino?
yes, I suppose so. The crius board with promini has an onboard led, but no d13 pin; so I remapped the LEDPIN stuff to A2 with attached transistor&LEDstrips. Should not behave any different from standard led&d13 on an original promini.
I only put the code in a different place, did not change it. :-/
don't they all say that
I have no real memory of how older versions treated the onboard led. This is the first time I use the LEDPIN stuff and run external LED strips attached to it. What I described may well be how it always was.
Side note: With intermittent use of LCDconfig menu, I now saw the LEDPIN led turn off when unarming! Strange.
So long as the LEDPIN output is ON while armed (=flying) I am not worried.
With this copter, I use LEDPIN output with LED strips for flight illumination/orientation (red/green/white),
and the BUZZERPIN output with LED strips for signaling (mostly battery related) warnings.
Enjoy your vacation.
Re: Code Refactoring: Buzzer/LED goes alarm
Tommie wrote:What does this change do?Code: Select all
void auto_switch_led_flasher() {
uint8_t seg = (currentTime/1000/125)%8;
if (led_flasher_sequence & 1<<seg) {
switch_led_flasher(!isBuzzerON());
} else {
switch_led_flasher(isBuzzerON());
}
}
So the flasher pattern is inverted if the buzzer is on?
?
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
dunno.
it is a chanhe introduced by hamburger before the refactoring.
I only moved the code.did not alter it. otherwise we could not folloe the chanhes
it is a chanhe introduced by hamburger before the refactoring.
I only moved the code.did not alter it. otherwise we could not folloe the chanhes
Re: Code Refactoring: Buzzer/LED goes alarm
https://github.com/wertarbyte/multiwii- ... a6eb44aa8c
This is the commit.
a) what is the LEDFLasher change supposed to do?
b) can we please stuff even more completely unrelated changes into single commit?
This is the commit.
a) what is the LEDFLasher change supposed to do?
b) can we please stuff even more completely unrelated changes into single commit?
Re: Code Refactoring: Buzzer/LED goes alarm
added another alarm;
If in armed state the minimal voltage ever seen is below VBATLEVEL3_3S (lowest of the three voltage alarms), then battery alarm 4 (the same as used for VBATLEVEL3_3S) gets triggered. This alarm only gets cleared when the Vmin value gets reset.
The Vmin values gets reset to actual voltage value when unarming the copter.
Please comment:
Is this alarm too agressive for your flying habbits? If so, we might need to add another voltage alarm threshold (something I tried to avoid).
If in armed state the minimal voltage ever seen is below VBATLEVEL3_3S (lowest of the three voltage alarms), then battery alarm 4 (the same as used for VBATLEVEL3_3S) gets triggered. This alarm only gets cleared when the Vmin value gets reset.
The Vmin values gets reset to actual voltage value when unarming the copter.
Please comment:
Is this alarm too agressive for your flying habbits? If so, we might need to add another voltage alarm threshold (something I tried to avoid).
Re: Code Refactoring: Buzzer/LED goes alarm
Tommie wrote:Tommie wrote:What does this change do?Code: Select all
void auto_switch_led_flasher() {
uint8_t seg = (currentTime/1000/125)%8;
if (led_flasher_sequence & 1<<seg) {
switch_led_flasher(!isBuzzerON());
} else {
switch_led_flasher(isBuzzerON());
}
}
So the flasher pattern is inverted if the buzzer is on?
?
If anyone use ledflasher output for control led strips, with this we have visual feedback of any alarm indicated by buzzer, but if buzzer is silent, the ledflasher work normally.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Hi hamburger,
imho this is too aggressive. would it be ok to do a define like armed time warning or introduce a dismiss for alarms via an aux channel
imho this is too aggressive. would it be ok to do a define like armed time warning or introduce a dismiss for alarms via an aux channel
Re: Code Refactoring: Buzzer/LED goes alarm
jevermeister wrote:imho this is too aggressive. would it be ok to do a define like armed time warning or introduce a dismiss for alarms via an aux channel
I think lipo battery cells should never be stressed below certain values, not even for short times under load. Tomorrow I will introduce a 4th vbatlevel for Vmin triggering the alarm, ok?
Re: Code Refactoring: Buzzer/LED goes alarm
Mis wrote:Tommie wrote:Tommie wrote:What does this change do?Code: Select all
void auto_switch_led_flasher() {
uint8_t seg = (currentTime/1000/125)%8;
if (led_flasher_sequence & 1<<seg) {
switch_led_flasher(!isBuzzerON());
} else {
switch_led_flasher(isBuzzerON());
}
}
So the flasher pattern is inverted if the buzzer is on?
?
If anyone use ledflasher output for control led strips, with this we have visual feedback of any alarm indicated by buzzer, but if buzzer is silent, the ledflasher work normally.
So it basically XORs the LED_FLASHER pattern with the one of the buzzer?
Re: Code Refactoring: Buzzer/LED goes alarm
Hamburger wrote:jevermeister wrote:imho this is too aggressive. would it be ok to do a define like armed time warning or introduce a dismiss for alarms via an aux channel
I think lipo battery cells should never be stressed below certain values, not even for short times under load. Tomorrow I will introduce a 4th vbatlevel for Vmin triggering the alarm, ok?
Hey Hamburger do we really need 4 levels? Seems a lot. One warning is enough for me.
I can understand 2 levels -
1st to warn its getting low - don't fly too high/far
2nd land asap
Re: Code Refactoring: Buzzer/LED goes alarm
shikra wrote:Hey Hamburger do we really need 4 levels? Seems a lot. One warning is enough for me.
I can understand 2 levels -
1st to warn its getting low - don't fly too high/far
2nd land asap
Hey shikra,
good question, really. I agree having 4 levels seem to be alot - or too much.
But I like to approach this issue differrently:
we always had 3 levels for the actual voltage - Alex (?) implemented it this way a long time ago and users have become familiar with this.
The new socalled fourth value really has a different meaning. It is to keep track not of the actual voltage but of the alltime low voltage.
I myself would prefer to reduce the 3 warninglevels for the actual voltage to 2 levels, plus the new alltime low voltage. That would keep the number of params equal to what we always had. But users would have to relearn the battery warning scheme then and maybe that is asking too much?
-
- Posts: 1630
- Joined: Wed Jan 19, 2011 9:07 pm
Re: Code Refactoring: Buzzer/LED goes alarm
Hamburger wrote:shikra wrote:Hey Hamburger do we really need 4 levels? Seems a lot. One warning is enough for me.
I can understand 2 levels -
1st to warn its getting low - don't fly too high/far
2nd land asap
Hey shikra,
good question, really. I agree having 4 levels seem to be alot - or too much.
But I like to approach this issue differrently:
we always had 3 levels for the actual voltage - Alex (?) implemented it this way a long time ago and users have become familiar with this.
The new socalled fourth value really has a different meaning. It is to keep track not of the actual voltage but of the alltime low voltage.
I myself would prefer to reduce the 3 warninglevels for the actual voltage to 2 levels, plus the new alltime low voltage. That would keep the number of params equal to what we always had. But users would have to relearn the battery warning scheme then and maybe that is asking too much?
agree with shikra
I think It should be up to the user to decide what to do knowing the vbat warning level.
Implementing a permanent alarm in case of too low vbat seems complicated.
I've never seen such a functionality in a lipo saver device.
Re: Code Refactoring: Buzzer/LED goes alarm
FWIW, I too would prefer just two warning levels, mimicing what my LiPo buzzer currently provides:
1. a warning that the battery voltage has dropped below a certain level (short beeps/blinks)
2. battery voltage is critically low, land immediately (permanent beep/faster blink frequency?)
1. a warning that the battery voltage has dropped below a certain level (short beeps/blinks)
2. battery voltage is critically low, land immediately (permanent beep/faster blink frequency?)
Re: Code Refactoring: Buzzer/LED goes alarm
Mis wrote:If anyone use ledflasher output for control led strips, with this we have visual feedback of any alarm indicated by buzzer, but if buzzer is silent, the ledflasher work normally.
And it breaks compilation if no buzzer is attached.
Re: Code Refactoring: Buzzer/LED goes alarm
LenzGr wrote:1. a warning that the battery voltage has dropped below a certain level (short beeps/blinks)
2. battery voltage is critically low, land immediately (permanent beep/faster blink frequency?)
that seems to sum up the majority of voices for actual voltage warning.
Re: Code Refactoring: Buzzer/LED goes alarm
Alexinparis wrote:I think It should be up to the user to decide what to do knowing the vbat warning level.
Implementing a permanent alarm in case of too low vbat seems complicated.
I've never seen such a functionality in a lipo saver device.
No lipo should ever be stressed to go below 3.0V per cell (actual value may depend on cell type LiFe, LiPo, decade of purchase ...). It will cause permanent damage just like complete discharging.
If such voltage drop ever happens even for short times (sudden full throttle burst), then the flying system has a problem and I want to know. The existing vvbat monitoring does not really catch that, because any alarm will go silent again once the voltage has recovered. To inform the user of this critical voltage drop, the alarm must be permanent.
I have tested it with two copters and both never get close to that 3.0V per cell with sane batteries in any flight manouvers. Now with an old partially broken battery it is totally different...
Why is it complicated to implement? I already did a first working version?
This minimal voltage information is not kept by the cheap 3$ lipo alarms, true. Imho, any good flight logger would provide this information and so should MultiWii. If you want to live without for a plain MultiWii, then I could turn Vmin alarm into a feature define - and rename it to something more appropriate.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Hi,
I use the current system as follows:
1. level: Warning 1 land soon
2. level: Warning land now!
3. level: Danger Will Robinson.
I think it would be best to hold the last level until system is disarmed. like my armedtimewarning. easy to implemt and make it use a define like #criticalbatlevelalert or something.
what do u think?
so everything stays the same for those guys who do not want to use that.
nils
I use the current system as follows:
1. level: Warning 1 land soon
2. level: Warning land now!
3. level: Danger Will Robinson.
I think it would be best to hold the last level until system is disarmed. like my armedtimewarning. easy to implemt and make it use a define like #criticalbatlevelalert or something.
what do u think?
so everything stays the same for those guys who do not want to use that.
nils
Re: Code Refactoring: Buzzer/LED goes alarm
I like it.
- jevermeister
- Posts: 708
- Joined: Wed Jul 20, 2011 8:56 am
- Contact:
Re: Code Refactoring: Buzzer/LED goes alarm
Tommie wrote:Mis wrote:If anyone use ledflasher output for control led strips, with this we have visual feedback of any alarm indicated by buzzer, but if buzzer is silent, the ledflasher work normally.
And it breaks compilation if no buzzer is attached.
No. This change was introduced in r1056, and no bug until r1068.
Someone miss "#define isBuzzerON() 0" during moving buzzer code to Alarms.ino