pre 2.4 version r1729

[henfri]

Hello Alex,

I' exited to see the progress. Thanks, I appreciate your work on MultiWii!
There is some code for FrSky Telemetry. Is there a chance that it can find its way into 2.4?

Here's the code for 2.3:
viewtopic.php?f=7&t=1929&start=150#p43296

Here's the documentation on Baseflight:
https://github.com/multiwii/baseflight/wiki/Telemetry

Let me know if I can support.

Greetings,
Hendrik

[ldonnay]

Any News on auto tune or PID tuning with a POT?

[ldonnay]

Any news on auto tune or PID tuning through POT?

[Leo]

I always calibrate Gyros before takeoff.
This also reset Baro Altitude.

Code: Select all

       if (rcSticks == THR_LO + YAW_LO + PIT_LO + ROL_CE) {    // GYRO calibration
          calibratingG=512;
          #if GPS 
            GPS_reset_home_position();
          #endif
          #if BARO
            calibratingB=10;  // calibrate baro to new ground level (10 * 25 ms = ~250 ms non blocking)
          #endif
        }

Just do the stick commands for Gyro calib...
THR_LO + YAW_LO + PITCH_LO + ROLL_CENTER

And it's been in the code for ages..

Yes, this is exactly what i was going to respond.
I've just added a small note in the wiki: http://www.multiwii.com/wiki/index.php? ... figuration

Thank you. I was unaware of that.

However, I have to say IMHO it is far from optimal. When I calibrate my Gyros I make sure the Quad is absolutely level. I use a water gauge for this procedure. This is always done in the house, never on the field. To reset the altitude I would have to go through that procedure every time. IMO calibrating ACC and setting baro alt to zero are two different categories.

I think the baro reset should always be done when the multicopter is powered up and one should have the option of resetting baro alt at any time when the multicopter is disarmed e.g. through alt hold switch. I have a little bit of experience with baro chips especially the MS5611. Here is an example of my project that requires reliability and precision: http://www.altduino.de/
My problem is that MultiWii is very complex but I will try to help if I can.

Leo

[Hamburger]

For the release notes:
which version of arduino and processing are used for the baseline?

[carlonb]

I always calibrate Gyros before takeoff.
This also reset Baro Altitude.
....
Just do the stick commands for Gyro calib...
THR_LO + YAW_LO + PITCH_LO + ROLL_CENTER

And it's been in the code for ages..

Yes, this is exactly what i was going to respond.
I've just added a small note in the wiki: http://www.multiwii.com/wiki/index.php? ... figuration

Thank you. I was unaware of that.

However, I have to say IMHO it is far from optimal. When I calibrate my Gyros I make sure the Quad is absolutely level. I use a water gauge for this procedure. This is always done in the house, never on the field. To reset the altitude I would have to go through that procedure every time. IMO calibrating ACC and setting baro alt to zero are two different categories.

I think the baro reset should always be done when the multicopter is powered up and one should have the option of resetting baro alt at any time when the multicopter is disarmed e.g. through alt hold switch. I have a little bit of experience with baro chips especially the MS5611. Here is an example of my project that requires reliability and precision: http://www.altduino.de/
My problem is that MultiWii is very complex but I will try to help if I can.
Leo

Happy New Year to all and MWii developers, I wish you the best new feature in 2015.

@ Leo,
There aren't issues calibrating the gyro (and the baro) in field as no need for a very leveled surface, this is mandatory for Acc.

@ Alex, Thanks for the explanation and I agree with you, about the Gyro (and baro) calibration I forgot it
Anyway I'm agree with Leo, I think that a "simple" #define ALTITUDE_RESET_ON_ARM is the best and "transparent" way to reset it for user where do not need to keep the take-off field altitude.
Carlo

[Leo]

@ Leo,
There aren't issues calibrating the gyro (and the baro) in field as no need for a very leveled surface, this is mandatory for Acc.

Carlo,

you are of course correct. I am going to blame my error on the excitement I'm having playing around with MultiWii and my Quadcopter

Leo

[Alexinparis]

Hello Alex,

I' exited to see the progress. Thanks, I appreciate your work on MultiWii!
There is some code for FrSky Telemetry. Is there a chance that it can find its way into 2.4?

Here's the code for 2.3:
viewtopic.php?f=7&t=1929&start=150#p43296

Here's the documentation on Baseflight:
https://github.com/multiwii/baseflight/wiki/Telemetry

Let me know if I can support.

Greetings,
Hendrik

Hi,
It won't be integrated for 2.4 , but probably after.
I expect it to be merged in Protocol.cpp by someone who use it. ie not me

[Alexinparis]

Any News on auto tune or PID tuning with a POT?

No plan for the moment to integrate both of this.
auto tune seems to be too much experimental currently.
It apparently works well for some, and not at all for others.

[Alexinparis]

For the release notes:
which version of arduino and processing are used for the baseline?

The current stable release of Arduino IDE 1.0.6 is still the reference to valid dev in multiwii.
(even if in windows version, gcc is old, I know...)

For processing, I still use 1.5.1 to generate binaries. mainly because they are smaller.

[Alexinparis]

@ Alex, Thanks for the explanation and I agree with you, about the Gyro (and baro) calibration I forgot it
Anyway I'm agree with Leo, I think that a "simple" #define ALTITUDE_RESET_ON_ARM is the best and "transparent" way to reset it for user where do not need to keep the take-off field altitude.
Carlo

I think calibratingB=10;
inserted somewhere in the go_arm() function should do the work.
I won't change this for 2.4.
but noted after

[Leo]

I have made the following changes concerning resetting baro altitude on arm:

in config.h add in section 6:

Code: Select all

/*************************************************************************************************/
/*****************                                                                 ***************/
/****************  SECTION  6 - OPTIONAL FEATURES                                          *******/
/*****************                                                                 ***************/
/*************************************************************************************************/

  /************************        Reset Baro altitude on arm         ********************/
  /* When unchecked a calibration of the baro altitude is preformed every time arming is activated */
  //#define ALTITUDE_RESET_ON_ARM

......... 

in the MultiWii.ccp code section

Code: Select all

void go_arm() {
  if(calibratingG == 0
  #if defined(ONLYARMWHENFLAT)
    && f.ACC_CALIBRATED 
  #endif
  #if defined(FAILSAFE)
    && failsafeCnt < 2
  #endif
  #if GPS && defined(ONLY_ALLOW_ARM_WITH_GPS_3DFIX)
    && (f.GPS_FIX && GPS_numSat >= 5)
  #endif
    ) {
    if(!f.ARMED && !f.BARO_MODE) { // arm now!
      f.ARMED = 1;
      #if defined(HEADFREE)
        headFreeModeHold = att.heading;
      #endif
      magHold = att.heading;
      #if defined(VBAT)
        if (analog.vbat > NO_VBAT) vbatMin = analog.vbat;
      #endif


      #ifdef ALTITUDE_RESET_ON_ARM
        #if BARO
          calibratingB = 10; // calibrate baro to new ground level (10 * 25 ms = ~250 ms non blocking)
        #endif
      #endif


      #ifdef LCD_TELEMETRY // reset some values when arming
        #if BARO
          BAROaltMax = alt.EstAlt;
        #endif
        #if GPS
          GPS_speedMax = 0;
        #endif
        #ifdef POWERMETER_HARD
          powerValueMaxMAH = 0;
        #endif
        #ifdef WATTS
          wattsMax = 0;
        #endif
      #endif
      #ifdef LOG_PERMANENT
        plog.arm++;           // #arm events
        plog.running = 1;       // toggle on arm & disarm to monitor for clean shutdown vs. powercut
        // write now.
        writePLog();
      #endif
    }
  } else if(!f.ARMED) { 
    blinkLED(2,255,1);
    SET_ALARM(ALRM_FAC_ACC, ALRM_LVL_ON);
  }
}

My tests have shown it to work correctly. Somebody please verify...

This option is important for me. I almost crashed my Quadcopter in small trees while doing my mission plan tests

[carlonb]

I have made the following changes concerning resetting baro altitude on arm:
in config.h add in section 6:

Code: Select all

.........

in the MultiWii.ccp code section

Code: Select all

..........

My tests have shown it to work correctly. Somebody please verify...
This option is important for me. I almost crashed my Quadcopter in small trees while doing my mission plan tests

Thanks Alex and Leo for the tip, I will test it ASAP and give a feedback.
Carlo

[carlonb]

Fly tested the new option "ALTITUDE_RESET_ON_ARM" as suggested by Leo few posts above, all run well.
I've done Horizon, Alt-Hold, RTH and a 4 point missions with a Auto-Landing.

Carlo

[shikra]

Thanks for testing

+1 for this feature to be added.

[Leo]

Alex, please consider putting it in rel. 2.4.
It's no risk and needs to be activated in order to take affect.

I have been using it for several days now.... I like it

[Rudi48]

Hello Alex and Leo,

I have tested today the ALTITUDE_RESET_ON_ARM modification, and it works.
Thank you very much.

I find it very useful, and would appreciate to have it in the coming MultiWii 2.4 version.

Regards, Rudolf

[Alexinparis]

ok, I've just added ALTITUDE_RESET_ON_ARM

[Hamburger]

I found two bugs

- attached (nmea) gps can induce data chars which may get interpreted via evaluateOtherData() as serial commands. Bug: this may drop user into configuration.loop or trigger other functionality. - Cannot be avoided with disabling gps in config.h. Reason: in v2.3+ even on gps port, incoming data get scanned for msp and other command data. (as a nicety for promini and prmicro users, I presume; since r1715)
Partial Fix: in evaluateOtherData() do nothing if currentport == gps.serial port.

- MultiWii.cpp: syntax errors in alarm code fragments for INFLIGHT_ACC_CALIBRATION; since r1727.

Will submit patches soon.

[Hamburger]

On my mega board with gyro, acc, baro, mag + lcd.telemetry, the loop time frequently exceeds the 2800 limit. I see value going up to 3200 every other second. The whole idea of enforced constant loop time gets ridiculed if the limit is too low.
Can others please comment on their loop times?
--
EDIT: plus attached serial GPS

[Rudi48]

To the cycle maximum topic.
Yesterday I made a flight test for stability.
I got the following EZ-GUI log data, concerning the cycle time:

Code: Select all

Hardware: mega board with gyro, acc, baro, mag, GPS
MultiWii pre2.4r1729 with ALTITUDE_RESET_ON_ARM
Flight time: 14:51:01 - 14:52:32 -> 91 seconds
# separate GPAR dataset
$ grep GPAR MultiWiiLog_2015_01_07_14_51_01.el1 >Log_14-51_GPAR.csv
# count lines
$ wc -l Log_14-51_GPAR.csv
     761 Log_14-51_GPAR.csv
# cut out cycle time
$ cut -d , -f 3 Log_14-51_GPAR.csv >Log_14-51_cycle.csv
# find cycle values >= 3000 us
$ grep ^3 Log_14-51_cycle.csv >Log_14-51_cycle3k.csv
# count number of events
$ wc -l Log_14-51_cycle3k.csv
      21 Log_14-51_cycle3k.csv
# show values
$ cat Log_14-51_cycle3k.csv
3152
3208
3232
3204
3168
3212
3252
3228
3220
3076
3048
3084
3048
3056
3072
3080
3064
3040
3080
3020
3188

The log file is attached.

Regards, Rudolf

[Hamburger]

To the cycle maximum topic.
...

thanks Rudolf. 21/761 ist about 3 percent with cycle times in the 3000 range.
Looks like increasing the constant to 3300 for this hardware might improve on predictability...

[Hamburger]

I found two bugs
...
Will submit patches soon.

in r1737 now

[FengShuiDrone]

I believe that the gyro should auto calibrate upon each FC start. Am I correct on this? Should that not also reset baro to zero? Is it really necessary to manually calibrate again right after starting the FC? I have noticed that over time while sitting waiting for a satellite fix sometimes the baro drifts + or - up to 10 feet or more according to my EZ GUI (but not always.) I can see doing the calibration then. It is easy enough to do. Am I correct that the baro should reset to zero upon power up?

[Leo]

To the cycle maximum topic.
...

thanks Rudolf. 21/761 ist about 3 percent with cycle times in the 3000 range.
Looks like increasing the constant to 3300 for this hardware might improve on predictability...

I've checked my log from the last flight and sorted the first 20 highest values:

cycleTime
5180
5180
5180
5180
5180
5180
5180
4892
4892
4892
4892
4892
3228
3228
3228
3228
3228
3196
3196

Is there any danger with these high values?

[Hamburger]

No danger. With original nunchuk sensor it was above 6000 always.
But if cycle time varies very much then it will have influence of flight characteristics because pid algorithm is not time invariant. In effect you tune for one value of cycletime. For a completely different values those pids will have a different effect.
So long as these runoffs happen rarely you will not notice.

[Leo]

Thanks. That's comforting to know.

I have set mine to #define LOOP_TIME 3300 now.

[Alexinparis]

I believe that the gyro should auto calibrate upon each FC start. Am I correct on this? Should that not also reset baro to zero? Is it really necessary to manually calibrate again right after starting the FC? I have noticed that over time while sitting waiting for a satellite fix sometimes the baro drifts + or - up to 10 feet or more according to my EZ GUI (but not always.) I can see doing the calibration then. It is easy enough to do. Am I correct that the baro should reset to zero upon power up?

At each FC start, there is a gyro cal + baro cal.
> I have noticed that over time while sitting waiting for a satellite fix sometimes the baro drifts + or - up to 10 feet
It's normal, because atmospheric pressure is not constant over time.
A baro can't do nothing with this... if used to evaluate an altitude.
It's fairly accurate to measure an altitude difference over short time, but not to report an absolute altitude.
That's why it's possible to reset it after (via a gyro cal stick, or via the new ALTITUDE_RESET_ON_ARM option)

[Alexinparis]

On my mega board with gyro, acc, baro, mag + lcd.telemetry, the loop time frequently exceeds the 2800 limit. I see value going up to 3200 every other second. The whole idea of enforced constant loop time gets ridiculed if the limit is too low.
Can others please comment on their loop times?
--
EDIT: plus attached serial GPS

I think it's due to GPS computation when a new frame is available.
It only occurs some % of loop and could probably be still optimized.
For other tasks (mag alt, comp, baro, gps frame decoding), I think 2800 is a good default candidate with recent task optimizations.
So let's say 5% of >2800 among 95% of 2800 should not be noticeable.

[Plüschi]

Sorry guys but this is stupid:

Code: Select all

 while(1) {
    currentTime = micros();
    cycleTime = currentTime - previousTime;
    #if defined(LOOP_TIME)
      if (cycleTime >= LOOP_TIME) break;
    #else
      break;  
    #endif
  }
  previousTime = currentTime;

I use this instead:

Code: Select all

 if (cycleTime >= LOOP_TIME) computeIMU();
 else "do the rest" like baro gps etc

Which works pretty well, and if you dont do this:
previousTime = currentTime;
but this:
previousTime += looptime;
the timing may jitter but not lag. I.e. you get a stable number of cycles/second -> PID not affected.

[robertha]

I believe there is a wrong factor (100000) to convert PSENSOR current value (mA) to used power (mAh) - line 444 in Multiwii.cpp.

As we have also amperage available and when we found correct PINT2mA factor to convert measure value to mA, but in this case the consumed power number is wrong beacuse of above factor.

There is:

powerValue = ( conf.psensornull > p ? conf.psensornull - p : p - conf.psensornull); // do not use abs(), it would induce implicit cast to uint and overrun analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 100; // [100mA] //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA] pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/100000; // [10 mA * msec] lastRead = currentTime;

Should be:

powerValue = ( conf.psensornull > p ? conf.psensornull - p : p - conf.psensornull); // do not use abs(), it would induce implicit cast to uint and overrun analog.amperage = ((uint32_t)powerValue * conf.pint2ma) / 100; // [100mA] //old (will overflow for 65A: powerValue * conf.pint2ma; // [1mA] pMeter[PMOTOR_SUM] += ((currentTime-lastRead) * (uint32_t)((uint32_t)powerValue*conf.pint2ma))/360000; // [10 mA * msec] lastRead = currentTime;

As we convert 10mA*ms to 10mA*hour = 1000*3600/10

[izeman]

i guess this has always been the case. mAh shown is to high by a factor 10 afair.

[Hamburger]

analog.intPowerMeterSum is where computed mAh get stored. From memory without code.
What do you use to see this value?
I use it all the time together with capacity warning on serial display and it just works as expected.
Dunno for the gui though.

[shikra]

MSP value for current changed by a factor of 10 at some point during 2.4 dev.

not sure if related to point above, but though would mention

[QuadBow]

I use it all the time together with capacity warning on serial display and it just works as expected.
Dunno for the gui though.

I do confirm, for me it works as expected, as well.

[Hamburger]

thanks for confirming.
I wished for people to read the wiki instructions now and then - at least when they experience problems with stuff that has been around for a long time.
Different configuration instructions for (v2.3 or newer) and (v2.2 or older)

[ram435766@gmail.com‬]

it would be great if the support for NRF24L01 , it has already been done , but if it is integrated into the new version that would make it easier and cheaper to build a custom rc

[haydent]

Hi guys, if its not too late id like to get my frsky s.port code added that takes advantage of the new MSP #130 cells variable. I remember being told not to add any new files to mw, so which area would be best for it ?

One of the newer neat features i added was 'host mode' so you dont even need a frsky rx, and can simply hook one of the frsky oled cell monitors directly to the fc via inverter and collect its cell data.

I will start preparing a patch against shared ?

[Alexinparis]

Hi guys, if its not too late id like to get my frsky s.port code added that takes advantage of the new MSP #130 cells variable. I remember being told not to add any new files to mw, so which area would be best for it ?

One of the newer neat features i added was 'host mode' so you dont even need a frsky rx, and can simply hook one of the frsky oled cell monitors directly to the fc via inverter and collect its cell data.

I will start preparing a patch against shared ?

Hi,
I'm afraid it's too late for 2.4
I think it seems currently stable enough to be released this week.
I think the best place to integrate this sort of feature is in Protocol.cpp, like other telemetry stuff.

[haydent]

ok thanks for the reply, i had the feeling it would be too late, but will be just happy to get it in there.

[Solarwater]

I believe I found a bug in the Nav code. I was flying my quad, and had gps hold and baro enabled. I wanted to bring it down, so I flipped off baro mode. Problem was it was not coming down. It was descending slowly as if baro was still enabled. Turning off gps hold allowed me to control throttle again as normal.

To test, I made another flight with ez-gui. In fact, the baro mode was not disabling when I switched baro off. It would only turn off if I also turned off all gps modes.

I took a look at the code, and found the f.GPS_BARO_MODE is being set true when using mission, land, or rth. The only time the baro takeover is disabled is when gps mode is fully off or when disarmed. I had inadvertently crossed through RTH mode due to my switch layout, but it looks like this would occur anytime you use mission/land/rth, and then go back to gps hold with baro mode off.

All I did was add the line "f.GPS_BARO_MODE = false;" to the gps hold section to correct the issue.

Code: Select all

else if (rcOptions[BOXGPSHOLD]) {                             //Position hold has priority over mission execution  //But has less priority than RTH
              if (f.GPS_mode == GPS_MODE_NAV)
                NAV_paused_at = mission_step.number;
              f.GPS_mode = GPS_MODE_HOLD;
             f.GPS_BARO_MODE = false;
              GPS_set_next_wp(&GPS_coord[LAT], &GPS_coord[LON],&GPS_coord[LAT], & GPS_coord[LON]); //hold at the current position
              set_new_altitude(alt.EstAlt);                                //and current altitude
              NAV_state = NAV_STATE_HOLD_INFINIT;
            }

I have been flying with this change for a while now, and everything seems OK. Is there anything I missed, that might be affected by this change?

[Leo]

Do you think it is a good idea to have GPS hold active when landing the quadcopter?

Case in point: Your quad is just about to touch the ground and GPS PH makes a correction and the landing skids get caught. Worse case is the quad could flip over

[Solarwater]

Do you think it is a good idea to have GPS hold active when landing the quadcopter?

Case in point: Your quad is just about to touch the ground and GPS PH makes a correction and the landing skids get caught. Worse case is the quad could flip over

I don't typically land with GPS hold enabled, and that wasn't what I was doing when I discovered this bug (I know I wasn't clear).

When I found the issue, I flew the quad over a patch of land with no trees, enabled position hold, and then ascended to a height (100m for example), then engaged baro hold. I do some filming of the area at that height, then I want to come down. I flip off baro, leaving gps hold on to maintain 2d position, and it is coming down so slowly, that I cant even see it changing height, to the point I don't think it is responding at all. If I toggle gpshold off and then back on, baro mode "unlocks".

When I turn off baro (or any mode really), I want it off.

[Leon11t]

Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

[TheBum]

Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

You have to get an understanding of Arduino programming to really understand how the routines in MultiWii get run. Once you understand that, then the code is much more straightforward.

The two main items are the setup() and loop() functions. setup() is called by the Arduino runtime at initialization time. loop() is called periodically by the Arduino runtime after initialization.

[Leo]

I don't typically land with GPS hold enabled, and that wasn't what I was doing when I discovered this bug (I know I wasn't clear).

When I found the issue, I flew the quad over a patch of land with no trees, enabled position hold, and then ascended to a height (100m for example), then engaged baro hold. I do some filming of the area at that height, then I want to come down. I flip off baro, leaving gps hold on to maintain 2d position, and it is coming down so slowly, that I cant even see it changing height, to the point I don't think it is responding at all. If I toggle gpshold off and then back on, baro mode "unlocks".

When I turn off baro (or any mode really), I want it off.

That is a valid situation. I also agree that is how it should happen. I'm sure Alex will take a look at it and make the necessary changes in the latest build.

[Leon11t]

Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

You have to get an understanding of Arduino programming to really understand how the routines in MultiWii get run. Once you understand that, then the code is much more straightforward.

The two main items are the setup() and loop() functions. setup() is called by the Arduino runtime at initialization time. loop() is called periodically by the Arduino runtime after initialization.

For example, I need write variable to EEPROM - where do I need to create this variable?
After plugging a power, I need to reed this variable (this variable its something like a flag)
How can I do this?

[TheBum]

Can anyone tell me where I can read about code structure of Multiwii. I want to make small changes to the code, but I do not understand structure of the code.
Can someone help me with that?

You have to get an understanding of Arduino programming to really understand how the routines in MultiWii get run. Once you understand that, then the code is much more straightforward.

The two main items are the setup() and loop() functions. setup() is called by the Arduino runtime at initialization time. loop() is called periodically by the Arduino runtime after initialization.

For example, I need write variable to EEPROM - where do I need to create this variable?
After plugging a power, I need to reed this variable (this variable its something like a flag)
How can I do this?

If you want it to be able to have a different value for each configuration profile, you'd add it to the conf_t struct. If you want the same value across all configuration profiles, you'd add it to the global_conf_t struct. You can probably take it from there to figure out what code needs to be added.

[Hamburger]

wrong - old - thread ; moved to r1739 thread viewtopic.php?f=8&t=6061&p=62034#p62034
- - - -
I think we got a problem with VBAT code.
analogRead() maps the range of [0 ; 5] Volts input to values of [0 ; 1023].
But with our current code (simplified) :

Code: Select all

      uint16_t v = analogRead(V_BATPIN);
        analog.vbat = (v*16) / conf.vbatscale; // result is Vbatt in 0.1V steps

the scaling divisor conf.vbatscale is an uint8_t, so in the range of [0 ; 255].

In effect, for a single cell we want to measure up to 4.2V, which becomes v=860 with analogRead() - at least in theory for a perfect 5V driven board.
We want analog.vbat to be 42 ( <=> 4.2Volts), so which value of conf.vbatscale could do that?
Simple math yields conf.vbatscale = v*16/analog.vbat or in our case conf.vbatscale = 860 * 16 / 42 = 327.
But 327 is beyond what uint8_t can represent!

This has not shown up in the past because single cell systems are not widespread and for batteries with more cells the divisors were chosen to reach the working range. To make it worse, in my tests with various boards driven from ESC-BECs I have seen variations of the theoretical 5V supply which result in another distortion of the analogRead() range which in some cases makes things even worse.

I see the following options:
a) lower the multiplier from 16 to 8 - this will force everyone to retune conf.vbatscale to about half of original value - also loose one bit of precision for tuning
b) make the multiplier a tunable define with preset 16 - no change for most users; the unlucky users can alter the preset to 8 and be happy
c) rewrite the VBAT code, possibly turn vbatscale into a linear factor instead of a divisor (this has irritated some users in the past);
d) make vbatscale 16 bit [0 ; 64k]

With being so close to release I vote for option b)
Opinions, comments?

[Hamburger]

please consider this thrread closed - do not post here