Code Refactoring: Buzzer/LED goes alarm

This forum is dedicated to software development related to MultiWii.
It is not the right place to submit a setup problem.
Software download
Post Reply
User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

good job, thanks.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

Thank you,

did anybody had time to test it?

I found a bug while switching to gps but could not find the mistake...
Nils

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

Not yet. Wil check around mid of this week. Promise.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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.

Tazzy
Posts: 75
Joined: Sun Jun 19, 2011 4:45 pm
Location: Sweden

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Tazzy »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

thanks for the feedback.i will take a look into that.

nils

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

also w orking with buzzer only :-/

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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 ;-)

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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?

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Tommie »

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?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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.

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?

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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.

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.

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Tommie »

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?

?

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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 ;-)

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Tommie »

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?

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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).

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Mis »

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.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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?

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Tommie »

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?

User avatar
shikra
Posts: 783
Joined: Wed Mar 30, 2011 7:58 pm

Re: Code Refactoring: Buzzer/LED goes alarm

Post by shikra »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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?

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Alexinparis »

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.

LenzGr
Posts: 166
Joined: Wed Nov 23, 2011 10:50 am
Location: Hamburg, Germany
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by LenzGr »

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?)

Tommie
Posts: 438
Joined: Sun Apr 08, 2012 9:50 am

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Tommie »

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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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.

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

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.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

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

User avatar
Hamburger
Posts: 2578
Joined: Tue Mar 01, 2011 2:14 pm
Location: air
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Hamburger »

I like it.

User avatar
jevermeister
Posts: 708
Joined: Wed Jul 20, 2011 8:56 am
Contact:

Re: Code Refactoring: Buzzer/LED goes alarm

Post by jevermeister »

cool

Mis
Posts: 203
Joined: Fri Apr 01, 2011 12:23 am

Re: Code Refactoring: Buzzer/LED goes alarm

Post by Mis »

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

Post Reply