uvos has quit [Ping timeout: 260 seconds]
uvos__ has quit [Ping timeout: 260 seconds]
xmn has quit [Ping timeout: 252 seconds]
xmn has joined #maemo-leste
xmn has quit [Ping timeout: 260 seconds]
joerg has quit [Ping timeout: 246 seconds]
joerg has joined #maemo-leste
mardy has joined #maemo-leste
xmn has joined #maemo-leste
xmn has quit [Ping timeout: 248 seconds]
<freemangordon> uvos: I don't know how did you measure android idle current, but here I see ~90 mA min
<freemangordon> it jumps to 10 for a split second, but then again jumps to at least 100
<freemangordon> this is without sim card and not connected to wifi
Twig has joined #maemo-leste
alex1216 has joined #maemo-leste
uvos__ has joined #maemo-leste
Twig has quit [Remote host closed the connection]
elastic_dog has quit [Ping timeout: 246 seconds]
uvos has joined #maemo-leste
elastic_dog has joined #maemo-leste
<uvos> freemangordon: thats los
<uvos> its spends little time in off mode
<uvos> becuase its very busy for some reason
<uvos> you need to mesure motorola android
pere has quit [Ping timeout: 260 seconds]
<uvos> btw leste encounters a bug where the modem power consuption is 40mA or so higher when no sim is insertet
<uvos> idk if android suffers from the same bug
<uvos> but i mesured with sim in flightmode
<uvos> for 15-20mA
pere has joined #maemo-leste
<freemangordon> this is motorolla droid, iiuc
<freemangordon> 4.somthing
<freemangordon> but ok, will measure again with sim
<freemangordon> oh, there was sim card in that device
<freemangordon> Wizzup: ^^^
<freemangordon> is that yours?
<freemangordon> verizon :)
<Wizzup> freemangordon: yeah that happened sometimes, but not mine
<freemangordon> I will keep it for some tests
<Wizzup> sure
mardy has quit [Read error: Connection reset by peer]
<Wizzup> btw, is bringing up status applet also relatively slow for some? sometimes it's fast, sometimes it's a bit slow
mardy has joined #maemo-leste
<freemangordon> leste idles @ 30mA
<Wizzup> it can be less, usually between 16-32 on my psu at home
<Wizzup> but this was probably without modem online
<freemangordon> uvos: with the fix, current draw after power-off is the same as after android power-off
<Wizzup> (been a while)
<Wizzup> freemangordon: oh 30mA when off?
<freemangordon> Wizzup: this is with modem online and connected to wireless
<Wizzup> ah
<freemangordon> no, when off it is 1mA
<Wizzup> ok
<freemangordon> without shutdown fix, power usage is the same to the precision my dmm has
<freemangordon> maybe more on th 2mA side than on 1mA
<freemangordon> uvos: what kernel you did your measurements with?
<freemangordon> Wizzup: uvos: http://46.249.74.23/leste/d4/power_usage/
<freemangordon> seems the patch is needed to strip some .5mA further down
<freemangordon> but we are already ok even without it
<Wizzup> til firefox loads bmp
<Wizzup> leste-fix is empty for me
<freemangordon> hmm?
<freemangordon> oh, I don;t know why
<freemangordon> lemme see
<freemangordon> well, chinese dmm software broke it somehow
<freemangordon> bu, just open .csv
<freemangordon> anyway bmp precosion is not good
<freemangordon> *precision
<Wizzup> right
<freemangordon> do you want me to measure something else?
norayr has left #maemo-leste [Error from remote client]
<Wizzup> not sure, I don't think so, but I didn't give it a lot of thought
<freemangordon> Later on I will try to find some 0.1 Ohm resistor to try to improve the precision in idle
<freemangordon> like, if there is any difference in voltage android vs leste-fix vs leste-nofix
<freemangordon> umm, in off, not in idle
norayr has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
norayr has left #maemo-leste [#maemo-leste]
pere has quit [Ping timeout: 246 seconds]
<uvos__> freemangordon: i used a dmm, but one with very low burden voltage
<uvos__> if motorola android uses 100mA somthing is very wrong there
<uvos__> on your install
<uvos__> aside from mine and tmlinds mesurements
<uvos__> motorola android can also idle for over 1w expieramentally
pere has joined #maemo-leste
norayr has joined #maemo-leste
norayr has left #maemo-leste [Disconnected: closed]
norayr has joined #maemo-leste
uvos has quit [Remote host closed the connection]
norayr has left #maemo-leste [Disconnected: Replaced by new connection]
norayr has joined #maemo-leste
uvos has joined #maemo-leste
xmn has joined #maemo-leste
alex1216 has quit [Quit: WeeChat 2.3]
norayr has left #maemo-leste [Disconnected: No route to host]
norayr has joined #maemo-leste
<freemangordon> uvos__: well, I have no idea what install is that, it is waht was there on the device
<freemangordon> without SIM card and withou uSD card now it idles @ 8
<freemangordon> 8mA that is
<freemangordon> ok, after power-off from android, current draw is 1.57 mA
<freemangordon> hmm, now, with SIM card and uSD, it is 1.80 mA, but decreases
<freemangordon> weird
<freemangordon> uvos__: anyway, the shutdown fix seems to not be unneeded, bot with and without it off draw is the same, for some reason it is 2.0 mA right after power-off, but decreases with time, exponentially, to ~1.60 mA
<freemangordon> the same happens with android
<freemangordon> so, whatever was causing high off current is already fixed
<uvos> hmm thats.. wierd
<uvos> i was mesureing <1mA with android
<freemangordon> well, lemme explain my methodology, maybe I am doing something wrong
<freemangordon> I have 47 Ohm resistor connected in series with the battery, which I short-circuit during boot with DMM on 4A range
<freemangordon> I short-circuit the resistor ofc, not the battery :)
<freemangordon> after boot, I power-off
<freemangordon> after power-off is completed, I switch DMM to 200 mA range, it is still in parallel to the resistor
<freemangordon> resistor is there to keep the current while I change the terminals on DMM (I have separate holes for 10A and 200mA)
<freemangordon> anything obviously wrong?
<freemangordon> (it has separate holes)
<uvos> well the resisor is pulling some current that bypasses the dmm, but that should make the mesurement low not high
<freemangordon> during the switch, voltage drop because of the resistor is < 100mV, should not affect the state
<uvos> no i mean durring the mesurement some current flows through the dmm and some though the resistor
<freemangordon> sure, but 47Ohm should make some .01 diff
<uvos> makeing the dmm read low
<freemangordon> yes, I know
<uvos> it probubly makes more sense to mesure the voltage drop on the resistor
<uvos> but dosent explain the high mesurement
<uvos> what do you mesure before the device is ever booted
<freemangordon> well, my goal was to check leste vs android
<freemangordon> 1.57 mA
<uvos> ok and yeah any inaccuracies shouldend matter anyhow as long as android and leste are the same
<freemangordon> mhm
<uvos> so yes i gues it was fixed sometime between 5.10 and now
<freemangordon> also, keep in mind the exponential decrease of the off current
<uvos> but ill repeat the expierament when i have time
<freemangordon> please do
<uvos> 8mA sounds sane fore android idle btw
<freemangordon> but I am pretty sure my DMM is pretty much accurate
<uvos> so thats a fine mesurement now
<freemangordon> yeah, maybe verizon SIM that was there was doing some crazy things
<uvos> possibly the modem dosent sleep but keeps searching for a network or something
<uvos> but yeah
<freemangordon> so, I see no flaw in my methodology, do you?
<uvos> no
<uvos> i gues it was fixed sometime between 5.10 and now
<freemangordon> mhm
<uvos> or only affects the other cpcap mfd
<freemangordon> please measure d3 (or whatever device you said has issues as well) when you have time
<uvos> bionic
<freemangordon> yeah
<uvos> bionic is pretty insane
<uvos> its empty in 2 days usualy even when turned off full
<freemangordon> from android?
<uvos> from leste
<uvos> cant turn it off from android anymore
<freemangordon> even with latest kernel?
<uvos> since installing the bootloader breaks android on this device
<uvos> weill last time i used it
<uvos> (also a 5.18 kernel(
<uvos> but not the latest
<freemangordon> well, I meant 5.18
<uvos> right
<freemangordon> ok, maybe try the shutdown patch kernel
<uvos> yeah i know (this patch)
<uvos> oh kernel image
<freemangordon> just providing the link again, in case you've missed it
<freemangordon> yeah, this is compiled so you can just use it as is
<freemangordon> this is 5.18.y-cpcap + shutdown fix
<uvos> ok can you link the patch again
<freemangordon> with broken cpcap-battery though
<uvos> id rather compile it myself
<freemangordon> umm, lemme see if I can find it
<freemangordon> as I just did git stash drop :D
<freemangordon> uvos: https://pastebin.com/7jtJFtGR
<uvos> thanks, saved
<freemangordon> uvos: BTW, I think if we have working charger detection, we don;t need charge mode
<freemangordon> agree?
<freemangordon> esp if we do cpcap stuff build-in
<uvos> well not need from the perpective of the device beein unbootable
<uvos> but i would still like the option to charge while off
<freemangordon> oh, sure
<uvos> but yes the mapphones wont have any specific need anymore
<freemangordon> mhm
<freemangordon> do you know what driver is that cpcap-uc or whatever?
<uvos> ./drivers/mfd/cpcap-uc.c
<uvos> if you mean the bits that upload the fw and so on
<freemangordon> well, I don't know what I mean
<freemangordon> like, I am trying to find where to start from
<uvos> cpcap-uc is just a microcontoller on cp where android uploads fw
<uvos> that fw then dose several things
<uvos> theres a enum with "macros" that the kernel calls on the fw
<uvos> to have cpcap perform certain tasks
<uvos> sec if i can find it
<freemangordon> oh, so those are these MACRO_IRQ in cpcap-battery (in vendor kernel)
<uvos> right
<uvos> so cpcap-battery.c for instance mostly lets the uc do everything
<freemangordon> I see cpcap-usb-det.c
<uvos> looks like the kernel dose most of it here
<uvos> yeah dosent look like you have to use the fw, despite there being a macro that detects usb, at least going by the name
<uvos> get_sense() and detection_work() seam to do it
<freemangordon> do you know what WHISPER is?
<uvos> no
<uvos> probubly some code name of a different chip involved in charging
<uvos> (maybe the inductive charging ic?)
<freemangordon> or some docking station?
<uvos> possible
<freemangordon> does d4 support inductive charging?
<uvos> maybe something in the lapdock
<uvos> freemangordon: optinally
<Wizzup> I think the pins in the back can be used ofr it
<uvos> freemangordon: the pogo pins beneth the battery door are for this
<freemangordon> ok
<Wizzup> uvos: super unrelated but is this also a mapphone? https://www.gsmarena.com/motorola_droid_x-3473.php
<uvos> no
<uvos> sholes
<Wizzup> ok
<uvos> its the same as the d2
<Wizzup> ah, I kind of assumed the d2 was a mapphone
<Wizzup> should have checked the spreadsheet I guess :D
<uvos> d2 is just a d1 with a locked bootloader
<uvos> and more ram
<uvos> and a more plasticy case
<Wizzup> mhm
<Wizzup> well, the xt610 was also a sholes, right?
<uvos> yes
<uvos> the lte modem is also sholes xD
<uvos> at least it uses the sholes kernel
akossh has joined #maemo-leste
<Wizzup> uvos: hmm interesting
<Wizzup> uvos: the d4 lte modem?
<uvos> yes - but calling it sholes is overstateing it a bit, they used the sholes android source tree to start and it uses the same pmic but otherwise its quite different (as you might imagine - it being a modem and all)
<uvos> also they bolted on the cpcap stuff
<uvos> that sholes dosent have
<uvos> thats also pretty siginificant
<Wizzup> mhm
<freemangordon> ok, seems charger detection is some "switch" stuff
<uvos> right
<uvos> massive statemachine
<uvos> well "massive"
<freemangordon> /sys/class/switch/charge_capability/state
<uvos> oh that kind of switch
<uvos> also right
<freemangordon> lives in cpcap-usb-det.c
<uvos> looks like yes
<uvos> get_sense() and detection_work()
<uvos> and friends
<freemangordon> unfortunately charger_capacity seems to come from userspace
<freemangordon> see cpcap_accy_charger
Twig has joined #maemo-leste
<freemangordon> CPCAP_IOCTL_ACCY_CHARGER
<uvos> i think tmlind or sre? had a way io intercept the stuff userpace reads form the cpcap userspace interface
<uvos> presumably if its done in userspace userspace is using this file/interface
<freemangordon> battd I guess
<freemangordon> or no?
<uvos> i dont know
<freemangordon> ok
<uvos> so theres a file you can use on android to do almost anything with cpcap from userspace
<freemangordon> ok, but I want to know who calls CPCAP_IOCTL_ACCY_CHARGER :)
<freemangordon> because that's how charger capacity is set
<uvos> well its called with this fd
<freemangordon> sure
<uvos> so check what has it open
<freemangordon> yeah
<freemangordon> I'll check batd first
norayr has left #maemo-leste [Disconnected: closed]
elastic_dog has quit [Ping timeout: 246 seconds]
elastic_dog has joined #maemo-leste
<freemangordon> uvos: is it possible that they ramp up the charging current until limit?
<uvos> we ramp up the current to avoid lead inductance triggering, they probubly do too
<uvos> ramping to limit would be grossly negligent
<freemangordon> right
<uvos> you have to tell the usb port your a high power device, unless you get the data lines tied symbol to get more than 500uA legaly per spec
* freemangordon searches for documentation on how fast-charger should be detected
<uvos> (yes thats uA not mA)
rafael2k has joined #maemo-leste
mardy has quit [Quit: WeeChat 3.5]
norayr has joined #maemo-leste
xes_ has quit [Ping timeout: 260 seconds]
akossh has quit [Quit: Leaving.]
Twig has quit [Remote host closed the connection]
xes_ has joined #maemo-leste
* norayr trying to calibrate the battery under droid3.
<norayr> under android.
sunshavi_ has quit [Ping timeout: 252 seconds]
<norayr> for 3 days, i cannot get it to 0. it's about 80% now.
<norayr> android on droids probably has very good power management.
<sicelo> naturally. nearly all devices (including laptops) have better power management when running their 'native' OS
<Wizzup> I think it's just OFF mode here
elastic_dog has quit [Ping timeout: 248 seconds]
elastic_dog has joined #maemo-leste
rafael2k has quit [Ping timeout: 260 seconds]
uvos has quit [Ping timeout: 260 seconds]