PB, check out this interesting battery consumption

As I mentioned in another thread, current deviation 10's battery consumption is confirmed to be too high after comprehensive test, due to the scanning frequency in the main event loop .

By using a multimeter series connecting to a devo10 and its battery, I got the following test data

tx power	current deviation(Backlight 1)	factory firmware(Backlight off)
150mw	195mA	n/a
100mw(20db)	181mA	143mA
30mw(15db)	166mA	131mA
10mw(10db)	160mA	117mA
3mw(5db)	157mA	109mA
1mw(0db)	156mA	108mA
300uw(-5db)	154mA	106mA
100uw	155mA	n/a

So our current deviation10 consumes 30% - 50% more than Walkera's factory firmware, which cause the TX reach battery alarm very soon

Since entering the most complicated page, e.g. the Complex template page,shows the TX consumes the same power as in the main page. So I believe the main event loop relates to the battery performance. By tweaking codes in the EventLoop() for many times, I found that commenting out any 1 of the statement inside the block of "if (CLOCK_getms() > next_redraw) { " will reduce the power consumption a lot, even lower than Walkera's FW. (no timer on, no binding dialog/safety warning dialog showing, so these statement are just some if-else checking)
I finally figured out that we can't finish all these checking within the period of 200ms --SCREEN_UPDATE_MSEC.

As I don't believe we need to check timer, battery alarm and Telemetry alram so frequent, I change these 3 scanning method to frequency of 1 seconds, codes are as follows:
if (CLOCK_getms() > next_scan) {
MIXER_CalcChannels();
BUTTON_Handler();
TOUCH_Handler();
PAGE_Event();
next_scan = CLOCK_getms() + CHAN_UPDATE_MSEC; //5ms
}

if (CLOCK_getms() > next_redraw) {
GUI_RefreshScreen();
TIMER_Update();
next_redraw = CLOCK_getms() + SCREEN_UPDATE_MSEC; // 200ms
}

if (CLOCK_getms() > next_lowprijobs) {
PROTOCOL_CheckDialogs();
TELEMETRY_Alarm();
BATTERY_Check();
next_lowprijobs = CLOCK_getms() + LOW_PRI_UPDATE_MSEC; // 1 second
}

Now the test result is just satisfied

tx power	codes with new scanning frequency(Backlight 1)	factory firmware(Backlight off)
150mw	152mA	n/a
100mw(20db)	138mA	143mA
30mw(15db)	124mA	131mA
10mw(10db)	116mA	117mA
3mw(5db)	113mA	109mA
1mw(0db)	111.7mA	108mA
300uw(-5db)	111.0mA	106mA
100uw	111.8mA	n/a

The current power consumption is about 10mA lower than Walkera's - Walkera's data is measured when backlight is off while Deviation's data is measure by setting backlight 0, If I turn of the backlight in deviation's ,will minus 8-10mA consumption.

Another issue is there is no TX power changing on the fly. the TX power setting takes effect only after rebooting or rebinding. So I add the following codes to provide TX power changing on the fly.

There is some minor side-effect: if changing the TX power too quick, the TX might reboot from time to time. The work-around is to add a save button to slow down the TX changing. However, I would like PB to help figure out if calling "CYRF_WriteRegister(CYRF_03_TX_CFG, 0x08 | Model.tx_power)" is not the bets way

static const char *powerselect_cb(guiObject_t *obj, int dir, void *data)
{
(void)data;
(void)obj;
u8 changed;
Model.tx_power = GUI_TextSelectHelper(Model.tx_power, TXPOWER_100uW, TXPOWER_LAST-1, dir, 1, 1, &changed);
if (changed) {
switch(Model.protocol) { // if changed to quick ,the TX will reboot, need to add some codes to slow down changing actions
case PROTOCOL_DEVO:
CYRF_WriteRegister(CYRF_03_TX_CFG, 0x08 | Model.tx_power);
break;
case PROTOCOL_WK2801:
case PROTOCOL_WK2601:
case PROTOCOL_WK2401:
CYRF_WriteRegister(CYRF_03_TX_CFG, 0x28 | Model.tx_power);
break;
case PROTOCOL_DSM2:
CYRF_WriteRegister(CYRF_03_TX_CFG, 0x08 | Model.tx_power);
CYRF_WriteRegister(CYRF_03_TX_CFG, 0x28 | Model.tx_power);
break;
case PROTOCOL_J6PRO:
CYRF_SetPower(Model.tx_power);
break;
default:
break;
}
}
return RADIO_TX_POWER_VAL[Model.tx_power];
}

Another minor issue is that the power consumption will rise and won't get back down after binding, so it is better to warn user to reboot the TX after binding, even though the TX can change protocol on-the-fly.

tx power	before binding	after binding
10mw	116mA	124
100mw(20db)	138mA	180mA

After figuring out and solving above battery issue, we are more closer to Beta version now

I believe the current binding need to improve as using DEVO protocol without fixed ID consumes more battery, which is not good. We need to figure out why current doesn't drop back after binding is finishedl

I don't agree with you. The more frequent tasks(even just some if-else checking) run, the more battery consumes. The only way to reduce power consumption is to reduce task-running frequency for low priority jobs.
Above codes didn't change channel updating frequency(still once per 5ms ) and GUI refresh rate(once per 200ms). They just do less scanning of protocol dialog, battery and telemetry scanning, which are just low-priority and unnecessary Think about that, even if I remove these scanning of alarms,it won't affect flying of helis or planes.
And the current scanning ration of battery and telemetry is 1ms, which is even too fast to for battery and telemetry alarm.

In terms of Protocol dialog checking , I don't really understand why we need to check it all the time. In my previous , I would rater check the binding only during power-on(no fixed id) or when the binding button is pressed.

Anyway, this is a high-pri bug, as the TX can't run for half an hour if the TX power is set to above 30mw, very bad user-experience. I will test these codes for more flights

And furthermore, I would suggest removing safety checking from the main loop. This checking should be event-driven instead of polling all the time. We just need to check safety setting in 3 senario: power-on,binding and loading new model.

I have a 2500mah LiPo in my Devo10, and after running for 2 hours at 10mw yesterday doing sim and Mini Cp, voltage dropped from 11.73 to 11.50 volts.

Today I flew both Mcpx and Minicp using the codes with modified main loop, everything is fine and the battery consumes much less than yesterday.

What I am working on is about binding: I got 2 different results for a DEVO model without fixed-id:
1) Power on, let the autobinding finished, current: 116mA(10mw) - normal result
2) Power on, stop the autobinding before it is finished， current: 158mA(10mw) - abnormal result
if pressing binding in the model page, I got the same result as #2， regardless the binding is finished or stopped.

So there should be a bug inside the binding logic