Nice catch - it was logical typo. Thanks, fixed that.

As for accurate values - yea, when properly calibrated, charge_now and charge_full (as reported by bq27200 module) will be accurate. By the way, implementing dr_frost_dk algorithm somewhere else (pyBattery, for example - I already talked with 412b about that), may make comparison between actual SoS and voltage-based graphs even easier. You can see how it differentiate in given point of time.

For non-measuring purposes, it's good to perform learning cycle at least once for 3 months, to keep calibration up with degrading capacity. Normally, it would be done much more often automatically - with learning step @ 3248 mV, and device turning of @ 3000 mV. Ho ever, with bme disabling device in less than half minute (most of the times), after learning curve, everyone try to charge before that happen. Hence, not allowing chip to recalibrate.

By the way, amongst tons of other data that bq27200.sh script provides, there is also info about cycles since last learning, and cycles since full reset (I got no idea when full reset occur, if not only flashing eeprom). It also notify, if there is more than 32 cycles since last calibration.

As an addition, here is my lamish script + desktop file to enable getting some data directly from bq27200 module, omitting i2cget. Of course it provide MUCH less data, than bq27200.sh by shadowjk. Still, I find it very useful for quick checking actual current etc - I even binded it to camera focus longpress, still having shortcut for it on desktop:

bq27200-0.sh
.desktop file for it

Note, that similarity in name with shadowjk's one is present *not* on purpose - I named my little script long before I discovered shadowjk's one. Also, concept of this *very* little script is mine, although I could manage to finish it only thanks to nicolai help (especially, with sending output to screen as tapable notification).