<tmlind>
Wizzup: ok yup that pretty much confirms that modem shuts down around 3.5v
<tmlind>
Wizzup: also seems like we have some large cumulative error with the coulomb counter capacity after several charge cycles?
<tmlind>
Wizzup: i guess the next step would be to check how fast the coulomb counter capacity gets out of line with the voltage based capacity estimate user space app
<tmlind>
Wizzup: and the modem should singnal something before shutting down the usb phy, that's a bug
<tmlind>
anyways, that might explain why we only get a few weeks of uptime
<tmlind>
Wizzup: hmm that log of yours is not for invalid register access though like earlier
norayr has left #maemo-leste [Error from remote client]
joerg has quit [Ping timeout: 268 seconds]
joerg has joined #maemo-leste
<rafael2k>
freemangordon, right, but as far as I can check, it is all good for hitting master
norayr has joined #maemo-leste
ceene has joined #maemo-leste
k1r1t0 has joined #maemo-leste
norayr has left #maemo-leste [Error from remote client]
Twig has joined #maemo-leste
mro has joined #maemo-leste
xmn has quit [Quit: ZZZzzz…]
pere has quit [Ping timeout: 248 seconds]
norayr has joined #maemo-leste
pere has joined #maemo-leste
akossh has joined #maemo-leste
<Wizzup>
tmlind: it might also be different, since this was my bionic just doing gps, the other cases were my d4 with bt
<Wizzup>
but in both cases the modem seemingly went away
uvos__ has joined #maemo-leste
arno11 has joined #maemo-leste
<Wizzup>
uvos__: fyi I will try to pick up the sphone work today
<Wizzup>
I also received the xt910
norayr has left #maemo-leste [Error from remote client]
<Wizzup>
SuperMarioSF: my impression seems to be that the phones look to be in a great state, with the box containing all the original stuff, I plugged in one of my batteries and am charging it now
freemangordon has quit [Read error: No route to host]
freemangordon1 has joined #maemo-leste
<peetah>
my current kernel is 5.18.9
<peetah>
uvos__: ^
<peetah>
Linux devuan-n900 5.18.9 #1 SMP PREEMPT Sun Sep 11 16:52:18 UTC 2022 armv7l GNU/Linux
<uvos__>
peetah: yeah thats fine too
k1r1t0 has joined #maemo-leste
<uvos__>
sicelo: right 6.1
<peetah>
Linux devuan-n900 6.1.9 #1 SMP PREEMPT Wed Feb 1 13:59:50 UTC 2023 armv7l GNU/Linux
<Wizzup>
SuperMarioSF: other one boots too :)
<peetah>
uvos__: done ^
<uvos__>
peetah: great thanks
<sicelo>
meantime, 6.2-rc7 boots fine too :-)
<sicelo>
fmg and sre really helped us figuring out that panel bug. since then we've been reliably booting into new kernels with less headache than before
k1r1t0 has quit [Ping timeout: 248 seconds]
<uvos__>
sicelo: sure this dosent free us from the agreed policy of testing every release that hits the -devel repo
<sicelo>
i wasn't referring to Leste
<peetah>
uvos__: you're welcome, that was an easy first one
<peetah>
feel free to ask whenever you need to test something on the N900
arno11 has joined #maemo-leste
pere has quit [Ping timeout: 256 seconds]
uvos__ has quit [Ping timeout: 252 seconds]
ceene has quit [Remote host closed the connection]
pere has joined #maemo-leste
pere has quit [Ping timeout: 260 seconds]
gliffy has quit [Remote host closed the connection]
<peetah>
Is there a way to follow battery discharge more closely, like bq2700.sh script was doing for maemo ? is this script safe to use with maemo-leste or did things evolve to far from mameo for this script to be still of any use ?
<bencoh>
afaik I'd say using that script should be safe on n900/leste (since it just reads registers)
<bencoh>
but droid4 relies on a different charger/fuelgauge
<bencoh>
the droid4 battery management hw is part of "cpcap"
mro has joined #maemo-leste
mro has quit [Client Quit]
<bencoh>
on droid4/leste users can rely on upower (upower -d iirc?) to monitor battery status
<bencoh>
(although that wont give you raw readings from the hw)
<peetah>
thanks bencoh
Twig has quit [Remote host closed the connection]
Twig has joined #maemo-leste
pere has joined #maemo-leste
<sicelo>
if you want to use the script in Leste, must first unload the bq27xxx_i2c module
<sicelo>
peetah: also, what do you specifically need from that script which isn't already available in /sys../power_supply? asking because I've contributed a few patches to the kernel driver for bq27200
<rafael2k>
there is screenshot of Maemo running pinphone ^
<rafael2k>
camera app on Maemo
xmn has joined #maemo-leste
<Wizzup>
timestamp? :D
<Wizzup>
19:30
rafael2k_ has joined #maemo-leste
rafael2k has quit [Ping timeout: 260 seconds]
<Wizzup>
rafael2k_: nice
<rafael2k_>
: )
rafael2k_ is now known as rafael2k
rafael2k_ has joined #maemo-leste
rafael2k has quit [Ping timeout: 255 seconds]
k1r1t0 has joined #maemo-leste
pere has quit [Ping timeout: 252 seconds]
<peetah>
sicelo: it's more about being used to have all the data available on one line in loop mode, than needing something that is not available elsewhere
<sicelo>
ok. i guess `upower -d` is one way to expose them in one place :-)
<sicelo>
but also `cat /sys/class/power_supply/bq27200-0/uevent` :-)
<peetah>
but bq27200.sh work out of the box and is hassle free :)
<sicelo>
actually even in fremantle, bq27200.sh didn't work ootb on power kernel ;-)
pere has joined #maemo-leste
SovietPony has joined #maemo-leste
panzeroceania__ has joined #maemo-leste
gliffy has joined #maemo-leste
parazyd1 has joined #maemo-leste
parazyd has quit [*.net *.split]
danielinux has quit [*.net *.split]
udder has quit [*.net *.split]
panzeroceania_ has quit [*.net *.split]
danielinux has joined #maemo-leste
arno11 has left #maemo-leste [#maemo-leste]
akossh has quit [Quit: Leaving.]
parazyd1 is now known as parazyd
Guest224 has joined #maemo-leste
<Guest224>
have anyone asked officially from Nokia, how much cost code for N900 to get voice calls code and cpu power management code?
<Guest224>
back to lurking logs ->
Guest224 has quit [Client Quit]
<Wizzup>
hi lurker ;-)
<Wizzup>
not sure what exactly the cpu power management code would do for us, I think the kernel is all open, and most of the code is there, we just need to fix some of it up
<Wizzup>
for the voice calls code, we have it mostly in the form of nemo pulseaudio modules and libcmtspeech
<Wizzup>
I spoke with Pavel at FOSDEM and he had both directions working, but ran into latency issues, which we can try to tackle, and perhaps use the pa cmtspeech module as well, and we might get pretty far
<Wizzup>
in this sense there is probably not much that nokia could give us, but there is a lot of other stuff they could open source that would help
Guest224 has joined #maemo-leste
<Guest224>
is there any "EU-money" in project left to buy to open some some sources? I don't think Nokia ask lot of money when tell that that code is over 10 years old.
<Guest224>
and latency issue...original code use DSP?
<Wizzup>
the foundation has some money but it doesn't seem realistic that they would do this
<Wizzup>
you can ask them, but I doubt anyone still even has the source there
<Wizzup>
the latency is probably something else, I don't have any details atm so it's hard to speculate
<Wizzup>
but pulseaudio by default (say parec) has a big latency
<Wizzup>
1-2 seconds
<Wizzup>
this can be tweaked
<Wizzup>
but I'd have to check with pavel about that
<Guest224>
hmm..even some people use in x86 PC realtime kernel-version to put down latency in audio use....hmm i have seen some documentations about that...searching...
<Guest224>
anyway realtime kernel patches might not be optimal solution for mobile.
<Wizzup>
yeah, this is likely a different problem
<Guest224>
anyway 1-2 seconds latency sounds very big...when my 20 years old 0.6 Ghz Mac has only 1ms at 24bit/96khz audio in/out latency (ok..i have some special PCI-card :) and not in pre-emptive multitasking OS)