PW PW gasgauge-info not updating

[doug.harriman]

I have a PW1 that I've got running a simple loop to:

- Read battery charge & temperaturature with gasgauge-info (-s and -k)
- Post that info to a server
- Download an image from the server (weather, calendare and battery info)
- Display image
- Go to sleep for 15 min.

Wake time scheduled with rtcwake, then it goes to sleep:

rtcwake -d /dev/rtc1 -m no -s 90
echo "mem" /sys/power/state

The odd thing is that the gasgauge-info data does not usually update. Every once and a while it does, but it's totally inconsistent in the loop described above.

Whenever I ssh into the Kindle, gasgauge-info works perfectly.

Looking for guidance on how to get reliable gasgauge-info data in the looping situation.

[NiLuJe]

Try not using it and checking the sysfs entry directly?

Also, it's unclear if you're actually seeing stale data from gasgauge-info itself, or stale data at the end of your custom pipeline, because, if it's the latter, the fault may lie somewhere in there, too .

[doug.harriman]

NiLuJe - Thanks for the response. Good thoughts, but unfortunately, I don't think it's either of those issues.

- I've run the system querying battery info from both gasgauge-info and directly from sysfs. Both exhibit exactly the same behavior.

- I'm running the process in a tmux window on the Kindle, and echoing out the battery info. When I reconnect, I can see previous reads, and they're not changing. Battery state should be moving slowly, but I've got an external thermometer, and the temperature is not tracking. If I stop the process, then run read the temperature (either method) I get the correct value. Literally can read it one second after it ran via the script and the value will change 5 degrees. So that confirms that it's on the Kindle side.

I've attached the shell script I'm running just in case that's of interest.

Thanks for the help!

[NiLuJe]

Originally Posted by doug.harriman

I can see previous reads

Does this mean you're not seeing new reads *at all*, or that new reads report stale data?

[NiLuJe]

Sidebar: switching to powersave before entering suspend is meaningless, the CPUFreq governor is irrelevant in standby/suspend.

(In fact, for interactive use-cases, there's a strong case to be made for actually switching to *performance* before suspend, as on some SoCs, this will allow the device to actually enter suspend faster, as well as resume faster, too. That does imply setting it back to a more reasonable governor post-resume, though ).

----

As for the actual issue, if you're actually seeing stale *new* reads, I could somewhat understand PM screwing with it for a while, but it *should* eventually automatically jog itself back into shape :?

EDIT: i.e., I'd try polling after a much larger delay on wakeup (and/or a couple of tries).

[doug.harriman]

Thanks for the info on the power management, I'll make that update.

When I run the script, the first read works successfully and there's good data. After that, the data is stale. Except, every so often it will update correctly. Those updates are inconsistent and may be hours or days between data updates.

[doug.harriman]

Circling back to this. I've found that if I add some delays when the system wakes up from sleep that I can reliably get good data back. If I try to minimize wake time, I do not get updated data. Waits are on the order of 3-10 seconds to get updated data.

[NiLuJe]

Yup, welcome to the joy & mysteries of weird PM things ;o).