<Wizzup>
uvos: if I retry with this third e960 that I have, and somehow make sure I safely remove the clips, I will still need some kind of hotglue or otherwise to make this work sensibly, right? I can't just tape around it a bit.
<uvos>
the bms?
<uvos>
to hold it against the battery?
<uvos>
you want to use some well speced tape
<uvos>
kapton tape is the mehtod of choice
<uvos>
wrap the bms with kaption, then tape around the end of the battery to keep the bms in
<Wizzup>
bms is the pcb?
<uvos>
yes
<Wizzup>
ok
dos has quit [Ping timeout: 255 seconds]
<Wizzup>
I think I should just do this in a few weeks when I get back and suffer through the weakest battery for a while longer :)
<Wizzup>
at least I have a bionic with a factory extended battery
<uvos>
above the final kapton tape you can use some firber reenforced tape for some regiditiy
<uvos>
thats how the stackup is in a comertial battery
<Wizzup>
ok
pere has joined #maemo-leste
dos has joined #maemo-leste
mro__ has joined #maemo-leste
mro__ has quit [Remote host closed the connection]
<uvos>
for some reason (well different chemistry) the bionic extended batteries have survieved mutch better than eb41/hw4x
<uvos>
mine has almost rated capacity
<tmlind>
uvos: i recall bionic batteries eeprom limits max charge voltage to 4.2 so that explains
mro_ has joined #maemo-leste
<tmlind>
narrowed down the tc358765 myster register bit enabling lcd output last night btw, bit 5 for VPCTRL must be set for tc358765 while tc358775 only supports video event mode and bit 5 is reserved
mro_ has quit [Remote host closed the connection]
<uvos>
thats true but not the reason really, the bionic extended battery is a standard li-nmc afair, while the eb41/hw4x is a hvlipo. The cathode alloying materials to increase the galvanic potential generally have mutch poorer lifespan, regarless of how you charge them
<uvos>
this is why also the new old stock eb41 battiers that have never been charged are so degraded
<tmlind>
uvos: ok, maybe also check the android cpcap charger voltage reg values between hw4x and extended battery just in case :) we know for sure that eb41 with android always connected to a charger will only last some months
<uvos>
its reduced
<uvos>
the charge enpoint voltage for bw8x (bionic extended) is 4.2 you can check with a dmm
<uvos>
so the cpcap regs are clearly also set correctly by android here
<tmlind>
ok
<tmlind>
android charged eb41 at 4.35 or whatever the voltage was
<uvos>
yes
<uvos>
again this battery has a different cathod material
<uvos>
so this is "ok"
<uvos>
but they have poor lifespan in genreal
<uvos>
*general
<tmlind>
it's not ok for a usable lifespan, it will bloat after a few months if left connected :)
<tmlind>
no idea how much short higher voltages wear it down though as discussed numerous times earlier
<uvos>
not mutch, the main thing that wares it down is just calendaric ageing, something those hvlipos are terrible at
<uvos>
anyhow unfortinatly any new phone battery you buy now will also be hvlipo for the most part
<uvos>
idealy soldered and glued into the deive
<tmlind>
somebody would have to run a test on a pile of batteries before i'd switch to higher charge voltages
<uvos>
yay obsolescence :P
<tmlind>
obsolete but still usable :)
* tmlind
bbl
<uvos>
tmlind: ttyl
<uvos>
really excited about mz617 support :)
ceene has joined #maemo-leste
mro has joined #maemo-leste
mro has quit [Remote host closed the connection]
<Wizzup>
yes yes :)
<Wizzup>
uvos: iirc the eu is forcing batteries to be replacable
<maxwelld>
will mz617 be able to show youtube videos in more than 144p? (:
<Wizzup>
I am never sure if these smileys are passive aggressive or not :D
<Wizzup>
but yeah, I'm sure it'll be able to play yt-dlp'd videos at native res
<maxwelld>
oh oh oh.
<maxwelld>
thank you for saying that.
<maxwelld>
with the smile i mean don't take it critically.
<maxwelld>
i would like to have a maemo tablet, if it is able to show online videos - that would be its main function.
<Wizzup>
yeah, we all want it :D
<Wizzup>
I have a bunch of mz617's to send to people too for dev
<maxwelld>
good.
ceene has quit [Ping timeout: 258 seconds]
ceene has joined #maemo-leste
<uvos>
d4 can bearly do 480p
<uvos>
so mz617 wille be able to do that too
<uvos>
(sw decodeing, with hardware presentation)
<uvos>
we cant do hw decodeing on omap4 atm
<Wizzup>
if I know ahead of time I just convert it to the right res with ffmpeg
<uvos>
but all the code is availble for this
<uvos>
as is the required propriatary firmware
<uvos>
but its going to be a pain to use as they never supported a real api like vaapi
<uvos>
but only some propriatary ti crap that no one uses
<Wizzup>
yeah, it's not important atm imo
<uvos>
would be nice to use the fsp
<uvos>
*dsp
<uvos>
another funn thing to do, that i will probubly never come around to is to use one of the the cortex m4 procs for various tasks
<uvos>
they can access almost anything the cortex a9 can
<uvos>
so you could have one decode mp3s and send the audio to cpcap for essentaly zero power usage audio playback
<uvos>
stuff like that
Daanct12 has quit [Ping timeout: 260 seconds]
Schimon has quit [Ping timeout: 255 seconds]
ahmed_sam has quit [Read error: Connection reset by peer]
<Wizzup>
yeah
<tmlind>
heh i remember the 100 hour mp3 playback spec..
norayr has left #maemo-leste [Error from remote client]
<uvos>
as noted by the commit message, an application can choose any osso service
<uvos>
but it cant choose xdg
<freemangordon>
yes, I saw that later PR
<freemangordon>
but just don;t see what we gain if explicitly requesting xdg-open
<uvos>
so in the case that we have any number osso serivces and a xdg action the client cant choose the xdg one but can choose any of the osso services
<uvos>
freemangordon: in this specific case, abook itself registers as a osso service to handle tel://
<freemangordon>
ahaaa
<uvos>
freemangordon: we must ofc avoid abook simply calling itself here
<freemangordon>
now I see
<freemangordon>
so, this is just a workaround
<uvos>
well the use - sortof
<uvos>
the the pr itself is just compleating the api really
<uvos>
but let my justify why this is fine:
<freemangordon>
ok, so we expect maemo phone app to either register in TP on with xdg
<freemangordon>
*or with
<uvos>
in abook this is a fallback path anyhow, any osso aligned dialer is going to be using tp
<uvos>
any non osso aligned dialer is not going to use a osso serivce
<uvos>
so its either tp or xdg-open anyhow
<freemangordon>
I understand that
<freemangordon>
it is just that the implementation looks hacky to me :) . gimme some time to chew it.
<uvos>
i gues what would be even better would be the ability for abook to tell hildonmime: dont use this action to handle this request
<freemangordon>
mhm
<freemangordon>
I was thinking about that
<uvos>
atm the api only allows the oposit: use this action to hanlde this request
<uvos>
the api should allow the caller to specify it wants xgd
<freemangordon>
well, the caller should not care about the method
<uvos>
well then you might as well remove the whole HildonURIAction parameter
ceene has quit [Ping timeout: 260 seconds]
<freemangordon>
uvos: not really
<freemangordon>
also, I think osso-abook can achieve the same without requesting xdg-only opening
<freemangordon>
there is already hildon_uri_get_actions_by_uri()
<uvos>
sure and we should extend that to also return a xdg HildonURIAction when thats whats available
<uvos>
but either keep the parameter as is and merge the pr to allow the HildonURIAction parameter to url_open also specify xdg-open, or remove the callers ability to specify what it wants in url_open
<uvos>
anything else makes no sense
<uvos>
really
<freemangordon>
ok, gimme some time to see if I can come up with a better API
<freemangordon>
uvos: ok, I will merge that PR, but osso-abook should simply call libhildonmime to open the uri without requesting xdg method. I am tempted to introduce hildon_uri_open_filtered() and call it a day
<freemangordon>
also, unless I am missing something, if there is no xdg dialer, osso-abook will call itself with the current code, no?
<uvos>
yes, thats slightly jarring, but harmless, it just moves to the contact again
<uvos>
hildon_uri_open_filtered would be a fine option too
<freemangordon>
well, what I am saying is that osso-abook should somehow tell libhildonmime to not call it. thus hildon_uri_open_filtered()
<freemangordon>
mhm
<freemangordon>
uvos: hmm you should not try uri_xdg_open() twice
<uvos>
i dont,
<uvos>
where do i?
<uvos>
if xdg-open is specified fails, and osso-serivce also fails then i gues it tires it twice
<uvos>
not a big deal or?
<uvos>
doing anything else would make the code more complex i think