MiyooCFW
MiyooCFW copied to clipboard
TriForceX
Battery level charging indicator
Are we certain about these numbers?
[ gmenu2x.cpp ]:
uint16_t GMenu2X::getBatteryLevel() {
int32_t val = getBatteryStatus();
if (confStr["batteryType"] == "BL-5B") {
if ((val > 10000) || (val < 0)) return 6;
else if (val > 4000) return 5; // 100%
else if (val > 3900) return 4; // 80%
else if (val > 3800) return 3; // 60%
else if (val > 3730) return 2; // 40%
else if (val > 3600) return 1; // 20%
return 0; // 0% :(
}
Because my PowKiddy Q90 doesn't seem to ever show the AC icon while charging (instead it shows 100%, 5), and once charged and disconnected from the charger, it shows the 4th icon, 80% on full charge, not 5.
I'm wondering if it's my battery (it's a new device), or if the calculation/estimation in the code is wrong here.
Edit: That's presuming the batteryType is "BL-5B" here -- whatever that means... :confused:
2nd Edit: My battery in the PowKiddy Q90 is actually a BP-4L battery -- if this is referring to the labelling on the battery.
// return 5 - 5*(100-val)/(100);
return 5 - 5 * (max - val) / (max - min);
What on earth is this actually doing, at the end of the function? Why "5 -"? Shouldn't it be "6 -"? :eyes: And what happened to "val" being reported as less than zero on charging? This may be the source of our bug. :thinking:
This may be the source of our bug. thinking
No, the first bit that matches "BL-5B" already returned early. The battery type is simply hardcoded. FWIW the V90 actually comes with a BL-5C (it's a Nokia battery model designation).
I've never seen an AC icon and mine reads 4230 fully charged (so it displays the icon with all bars), with or without the charger plugged in. RetroArch uses a different table derived from the author's V90 libretro/RetroArch@592f69ec69f3.
Excellent! That means that for whatever reason this line is never triggered:
if ((val > 10000) || (val < 0)) return 6;
A return of 6 gives us the AC icon.
While plugged into charging, what does your device read? This is where we're running into something unexpected. The code expects the device to read over 10000 or a minus value while it's charging. I'll check mine (my PowKiddy Q90), too.
Hmm... My PowKiddy Q90 does not seem to be giving off any such indication that it is plugged in and charging. It simply reads the current charge of the battery. This is why we never saw the AC icon.
I'll wait until it charges fully, and check the value then.
4230 fully charged -- the same, you're right. And I was in error: the 100% icon does show on a full charge, it's just that my PowKiddy's battery drops to below 4000 rather quickly.
So the indication is working correctly, except that the AC icon (6) condition is never true. It seems the current implementation of hardware and system software doesn't register and/or record when the device is plugged into power, so this feature is missing and, consequently, the AC icon never shows.
Not sure to leave this open as a bug (missing feature) or close it. :thinking: I'll leave it open in case we want to re-implement the AC icon, and if there's a way to do so with the current hardware.
The kernel is reading the KEYADC Data Register, multiplying that by 90, and reporting that as voltage_now. That register is a 6-bit value so the largest value that can be reported is 63 x 90 = 5670, which is less than 10000.
It's a little odd that the battery voltage would do double-duty as a charging indicator as devices typically report them separately.
Yeah. It's strange programming with that return 6. Especially given that it's a 6-bit value that's being stored in that file. But I guess it all depends on the programming of the software that reads and reports that hardware status.
I agree that it's quite odd for it to do a double-duty, but I've seen this done in other system software before, so it wouldn't be the first time. Technically, while the device is plugged into power, the voltage reading has little significance -- so it's not unreasonable to drop it for the duration and signal with a negative value, for instance, that the device is plugged into power instead.
I poked around in the "sys" files there to see if there was any record of the device being plugged into power in any of the other files -- something we could use for triggering the AC icon -- but no, I couldn't find anything. :/
// return 5 - 5*(100-val)/(100); return 5 - 5 * (max - val) / (max - min);What on earth is this actually doing, at the end of the function? Why "5 -"? Shouldn't it be "6 -"? 👀 And what happened to "val" being reported as less than zero on charging? This may be the source of our bug. 🤔
From 0 to 5, there are 6 values. The function's return is an integer. There are 6 defaults statuses, you can see the battery icons to see that (example "...\gmenu2x\skins\OldBoy\imgs\battery"). I think the seventh status, AC status, is because the battery has been removed and is only charging. This return is practically a mapping, for integer values from 0 to 5, it is mapping the percentage (0 to 100) in these values there.
Ah, it's assigning the percentage based on the charge value provided. It only needs to calculate 6 values, as the 7th is the charge icon, for which the charge value is symbolical/nonsensical. It needs not calculate and display the 7th value in percentage. Now I understand. :+1:
I've been thinking about this, and it would make much better sense for the charge icon to be independent of the actual voltage inside the unit. There should be a driver registry/indicator whether the AC is plugged in or not. The charge icon display should be hooked up to this record/indicator, and independent of the voltage reading (percentage displayed). But I suppose this is a driver/hardware question, in whether this is technically feasible -- one of which I don't know much about. :thinking: