**** BEGIN LOGGING AT Sun Jan 01 02:59:56 2023
Jan 01 13:50:55 <joerg> akossh: ++
Jan 01 13:51:38 <joerg> sicelo: I think akossh is right, it's a dynamic result that gets reset to zero as soon as it doesn't make sense anymore
Jan 01 13:54:53 <joerg> sicelo: >> The taper detection conditions must be maintained for 4 successive average current measurements<< and one measurement (or for sure 4) that does not meet conditions will result in IMIN=0
Jan 01 13:55:12 <joerg> that's my guess
Jan 01 13:57:58 * joerg wonders if N900 bq27xx chips ever been programmed to an adapted EEPROM config. IIRC for openmoko batteries they were not
Jan 01 14:02:35 <joerg> https://termbin.com/rp2s
Jan 01 14:10:15 <joerg>    0x76:        45  ILMD Initial Last Measured Discharge High Byte     914  µVh (1)  R/W
Jan 01 14:10:17 <joerg>                     *0x100 * 3.57 / 20 =  2062 mAh fabcoded cell capacity
Jan 01 14:10:30 <joerg> so forget it, it's bogus I'd say
Jan 01 14:25:47 <joerg> Pack Configuration (PKCFG) — Address 0x7C : 67d = 0b0100 0011;  QV1 & QV0 These bits set the minimum qualification voltage for charge termination  -> 1 0 = 4064
Jan 01 14:27:07 <joerg> https://i.imgur.com/32kwtjX.jpg
Jan 01 14:29:13 <sicelo> hi :-)
Jan 01 14:29:34 <sicelo> yes, that's where i got the 4064mV i mentioned earlier
Jan 01 14:30:17 <sicelo> and yes, looks like IMIN=1 from when it becomes full (from charging), and stays that way until 4064mV is reached, even momentarily. 
Jan 01 14:32:30 <sicelo> https://paste.debian.net/1265870/ - when 2nd column has "Full", that's when IMIN=1
Jan 01 14:33:10 <sicelo> i think the battery is a bit weak, and the system is drawing a lot of current, hence we drop quickly to IMIN=0
Jan 01 14:35:34 <joerg> the values of bq27k EEPROM in N900 are bogus/default, in my book
Jan 01 14:36:20 <joerg> doesn't look like Nokia went to the extent to actually program those chips to something meaningful
Jan 01 14:38:11 <joerg> and the BME proprietary closed blob that "makes your eyes bleed" when you had a chance to look at the source, didn't bother about any such states in bq27k anyway
Jan 01 14:38:20 <sicelo> i agree re:programming, but i think the values themselves are correct. i'd say they're the default values
Jan 01 14:39:10 <joerg> sure, they are TI factory defaults I'd say
Jan 01 14:39:19 <sicelo> agreed :-)
Jan 01 14:39:47 <joerg> check 0x6E:         0 EE_EN EEPROM Program Enable
Jan 01 14:40:44 <sicelo> i have been playing with bq because upower has issues with it, and i would like to find a way to make it work perfectly ootb
Jan 01 14:40:52 <joerg> >> This register is used to enable host writes to EEPROM data locations (addresses 0x76 — 0x7F). The host must write data 0xDD to this register to enable EEPROM programming. See the Programming the EEPROM section for further information on programming the EEPROM bytes. Care should be taken to insure that no value except 0xDD is written to this location.
Jan 01 14:42:46 <sicelo> in particular, upower does not like  to see capacity = 0, which can happen easily on N900, especially if you charge externally
Jan 01 14:44:07 <sicelo> maemo leste has patched upower, but i also use other OSes on the N900, e.g. postmarketOS. they have many other phones, so they're not very keen on upower hacks, since what works for one might not work for the other
Jan 01 14:47:00 <joerg> >> The bqJUNIOR has 10 bytes of EEPROM that are used for firmware control and application data (see the bqJUNIOR Register Descriptions section for more information). Programming the EEPROM should take place during pack manufacturing because a 21 V pulse is needed on the PROG pin.<< which makes moot a lot of features the bq27k *could* support, because you can't program reasonable config values to the EEPROM, particularly for stuff like taper current threshold, 
Jan 01 14:47:01 <joerg> end-of-charge cell voltage etc pp
Jan 01 14:50:19 <joerg> to put it plain and unambiguous: a chip $XY like for example bq27xx in one implementation and hw platform my act different that same chip in another circuit/implementation/hw-platform. No way to make a generic reliable full featured API for such a chip, unless you handle config options which are nothing else than hacks
Jan 01 14:50:57 <joerg> s/my act/ may act/
Jan 01 14:59:26 <joerg> I had such discussions about kernel and platform specific adaptions which can _not_ completely taken care of by device tree or whatever other generic means. That's why I think you'll always want a platform specific kernel / modules
Jan 01 15:12:19 <sicelo> i agree that the generic module leaves out other properties
Jan 01 15:19:39 <sicelo> for example, recently i added https://lore.kernel.org/linux-pm/20220420123059.1206443-1-absicsz@gmail.com/T/#m2c1d4196cd9c5be45f2671e5bebec5dd18d1535e , so i could get *some* capacity even if CI=0. previously, driver unconditionally returned ENODATA for mort of the properties, until calibrated
Jan 01 15:19:41 <joerg> >><sicelo> in particular, upower does not like  to see capacity = 0, which can happen easily on N900<< well, it's a completely correct value for "state of charge" since in N900 this is NOT meant to provide the ACTUAL state of charge of a battery that just got inserted. Though BQ27k is "BATTERY GAS GAUGE IC" it isn't exactly meant nor working that way in N900
Jan 01 15:20:23 <joerg> CI=1 you meant?
Jan 01 15:20:32 <sicelo> yes, sorry
Jan 01 15:20:54 <joerg> >>CI    Capacity Inaccurate flag. A 1 indicates no valid learning cycle.<<
Jan 01 15:21:25 <sicelo> well, it's a completely correct value for "state of charge" since in N900 << ... i completely agree. that's why i think upower needs to take other factors into account, and not just rely on CAPACITY only
Jan 01 15:21:48 <joerg> yep
Jan 01 15:22:07 <joerg> at least not on "capacity" from bq27k, only
Jan 01 15:22:33 <sicelo> it's not only bq27k that has this issue. even Droid 4's cpcap has same (or worse!)
Jan 01 15:23:06 <joerg> since bq27k in N900 is _not_ a reliable batt gas gauge, it's only used to measure currents and voltage of battery which are always reported correctly
Jan 01 15:23:25 <sicelo> https://gitlab.freedesktop.org/upower/upower/-/merge_requests/40#note_1693468
Jan 01 15:23:59 <sicelo> https://gitlab.freedesktop.org/upower/upower/-/issues/218#note_1692156
Jan 01 15:25:18 <joerg> freedesktop... ohmy
Jan 01 15:25:27 <sicelo> :-D
Jan 01 15:26:38 <joerg> poetterspecs?
Jan 01 15:27:13 <sicelo> i honestly will be happy when upower dies
Jan 01 15:27:34 <sicelo> unfortunately, it is the de facto standard atm, so yeah
Jan 01 15:39:26 <joerg> things about cats in movies you can't do anymore https://youtu.be/qOj0RdpirrI?list=PLuoTtPxIOh1P-xJ-lcjxZOE2MKrI6P0lM&t=78
**** ENDING LOGGING AT Mon Jan 02 02:59:56 2023