| *** nox- has joined #maemo-ssu | 00:03 | |
| *** NIN101 has quit IRC | 00:08 | |
| DocScrutinizer05 | btw while N1110 (bat temp thermistor) is indeed close to battery and has even direct airflow contact (I admit the direct material contact to shield I seen been a debris), the N1130 (bq27200) is not *under* the battery but >10mm aside from it, separated by shiled, plastic, and a second tight shielding can that's virtually entirely NOT under battery, rather it's close to heat sources like e.g. camera flash LEDs and even uSD | 00:17 |
|---|---|---|
| DocScrutinizer05 | s/N1110/R1110/ | 00:18 |
| infobot | DocScrutinizer05 meant: btw while R1110 (bat temp thermistor) is indeed close to battery and has even direct airflow contact (I admit the direct material contact to shield I seen been a debris), the N1130 (bq27200) is not *under* the battery but >10mm aside from it, separated by... | 00:18 |
| DocScrutinizer05 | and a rationale about keeping "bme" operational while unloading the module that probes the thermistor needed for "bme" is about as sensible as asking for flash LEDs staying operational while unloading the cam driver | 00:20 |
| DocScrutinizer05 | actually bq24150-bme.ko should *directly* read out the thermistor to unconditionally shut down charging when over/undertemp | 00:23 |
| DocScrutinizer05 | and it should be kernel directly signalling dsme about thermal shutdown needed, to protect device from damage | 00:24 |
| DocScrutinizer05 | and when dsme doesn't react, kernel MUST shut down autonomously, when temperature is rising another 2°C | 00:25 |
| *** Pali has quit IRC | 00:42 | |
| *** xes has quit IRC | 01:20 | |
| *** DocScrutinizer51 has quit IRC | 01:20 | |
| *** DocScrutinizer51 has joined #maemo-ssu | 01:20 | |
| *** nox- has quit IRC | 01:22 | |
| *** nox- has joined #maemo-ssu | 01:22 | |
| *** kolp has quit IRC | 01:26 | |
| *** discopig has quit IRC | 01:28 | |
| *** discopig has joined #maemo-ssu | 01:41 | |
| *** discopig has joined #maemo-ssu | 01:41 | |
| *** LauRoman has quit IRC | 03:09 | |
| *** dhbiker has quit IRC | 03:21 | |
| *** arcean has quit IRC | 03:22 | |
| *** Martix has quit IRC | 03:53 | |
| *** unclouded has joined #maemo-ssu | 03:53 | |
| *** futpib has quit IRC | 04:55 | |
| *** nox- has quit IRC | 04:57 | |
| *** amiconn has quit IRC | 05:38 | |
| *** amiconn_ has joined #maemo-ssu | 05:38 | |
| *** amiconn_ is now known as amiconn | 05:38 | |
| *** DocScrutinizer05 has quit IRC | 06:04 | |
| *** DocScrutinizer06 has joined #maemo-ssu | 06:04 | |
| *** DocScrutinizer06 is now known as DocScrutinizer05 | 06:04 | |
| *** PaulFertser has quit IRC | 07:23 | |
| *** PaulFertser has joined #maemo-ssu | 07:24 | |
| *** M13 has joined #maemo-ssu | 08:28 | |
| *** Martix has joined #maemo-ssu | 09:32 | |
| *** arcean has joined #maemo-ssu | 10:16 | |
| *** LauRoman has joined #maemo-ssu | 10:52 | |
| *** kolp has joined #maemo-ssu | 11:09 | |
| *** arcean has quit IRC | 11:15 | |
| *** dhbiker has joined #maemo-ssu | 11:17 | |
| *** dhbiker has quit IRC | 11:38 | |
| *** dhbiker has joined #maemo-ssu | 12:25 | |
| *** XDS2010 has quit IRC | 12:36 | |
| *** XDS2010 has joined #maemo-ssu | 12:36 | |
| *** unclouded has quit IRC | 12:38 | |
| *** M4rtinK has joined #maemo-ssu | 12:39 | |
| *** Pali has joined #maemo-ssu | 12:42 | |
| *** LauRoman has quit IRC | 13:17 | |
| *** nightsh_ has quit IRC | 13:23 | |
| *** wmarone__ has quit IRC | 13:23 | |
| *** aap has quit IRC | 13:23 | |
| *** thedead1440 has quit IRC | 13:23 | |
| *** wmarone_ has joined #maemo-ssu | 13:23 | |
| *** nightsh has joined #maemo-ssu | 13:23 | |
| *** aap has joined #maemo-ssu | 13:24 | |
| *** futpib has joined #maemo-ssu | 13:24 | |
| *** thedead1440 has joined #maemo-ssu | 13:24 | |
| *** futpib_ has joined #maemo-ssu | 13:25 | |
| *** futpib has quit IRC | 13:25 | |
| *** Raimu-Z has quit IRC | 13:28 | |
| *** MohammadAG has quit IRC | 13:28 | |
| *** Raimu-Z has joined #maemo-ssu | 13:31 | |
| *** MohammadAG has joined #maemo-ssu | 13:31 | |
| *** lizardo has joined #maemo-ssu | 13:39 | |
| *** _rd has joined #maemo-ssu | 13:42 | |
| *** _rd has quit IRC | 14:01 | |
| *** user has joined #maemo-ssu | 14:04 | |
| user | ping Pali | 14:05 |
| *** user is now known as Estel-temp | 14:05 | |
| Estel-temp | ping Pali | 14:05 |
| Estel-temp | Pali, there is a critical problem with yournew hald-addon-bme and dsme-thermalobject | 14:05 |
| Estel-temp | on every boot, it presents message about device being overheated and shutting down, despite that, in reality, device is ~27 C | 14:06 |
| kerio | does it, in fact, shut down? | 14:06 |
| Estel-temp | I suspect it's same reason that made people get 270 C readouts instead of 27C | 14:06 |
| Estel-temp | yes | 14:06 |
| Estel-temp | change in way things report temp | 14:07 |
| Estel-temp | I'm pretty sure it think that device is 270C ;) | 14:07 |
| kerio | Estel-temp: is rx51-battery loaded at that point for you? | 14:07 |
| Estel-temp | yes | 14:07 |
| Estel-temp | or no, no idea. I think yes, it happens late during boot | 14:07 |
| Estel-temp | maemo notify popup appears instructing me to slide keyboard oiut to make cooling faster | 14:08 |
| kerio | cool, i didn't know maemo did that | 14:08 |
| Estel-temp | I have access to rootfs via backupmenu, tried commentingm out loading bq27x00_battery and rx51_battery in /etc/event.d/bme | 14:08 |
| Estel-temp | but then, device won't boot | 14:08 |
| Estel-temp | kerio, me neither, as it never overheats in real life | 14:09 |
| Pali | Estel-temp, about month ago I updated kernel-power v52 with new version of rx51_battery which fix temperature unit | 14:09 |
| Estel-temp | anyway, even putting /etc/event.d/bme out of event.d doesn't help with that overheat message | 14:09 |
| Estel-temp | Pali, without bumping kernel vwersion number, eh? You know it's fuckin bad practice? | 14:09 |
| Pali | before rx51_battery reported 271°C instead 27.1°C | 14:09 |
| Pali | kernel-power v52 was not released yet | 14:10 |
| Estel-temp | I'm pretty sure I'm using latest kp52, but I'm not absolutely certain | 14:10 |
| Estel-temp | nobody can be if shit get new things without bumping version number, for example to kp52r1 | 14:10 |
| Estel-temp | anyway | 14:10 |
| Estel-temp | Pali, have you tried rebooting device with new hald-addon-bme and rx51_battery! | 14:11 |
| Estel-temp | s/!/?/ | 14:11 |
| infobot | Estel-temp meant: Pali, have you tried rebooting device with new hald-addon-bme and rx51_battery? | 14:11 |
| Estel-temp | sorry, writing from another device without proper xchat settings | 14:11 |
| * kerio redownloads and reinstalls kp52 | 14:11 | |
| kerio | just in case :> | 14:11 |
| Estel-temp | Pali, I can fix it, but how to boot that device affected by problem? I have accessd to rootfs, what to edit? | 14:12 |
| kerio | Pali: does 0xFFFF work on-device, with the local softupd? would you consider starting a softupd instance automatically so we don't have to do the weird two-terminal game to flash something manually? | 14:12 |
| Estel-temp | I would like to boot and reinstall kp52 | 14:12 |
| kerio | Estel-temp: rescueOS | 14:13 |
| kerio | you're using uboot, right? | 14:13 |
| kerio | you just need the bootimg | 14:13 |
| kerio | and the modules | 14:13 |
| kerio | hell, even without doing the proper dpkg install | 14:13 |
| Estel-temp | kerio, I can recover from backup too, but would like to repair it manually is possible | 14:13 |
| Estel-temp | hehe, no u-boot yet | 14:13 |
| Estel-temp | I just fixed fucvked optfs filesystem | 14:13 |
| Estel-temp | u-boot is next in line | 14:13 |
| Estel-temp | Pali, two questions: 1. Have you tried booting with your new bme-repl. bits, so are you sure that it boots and my old kp52 is to be blamed 2. what to edit to skip that thermal check, and be able to boot and reinstall kp52 to newest one | 14:14 |
| kerio | why do you think you have to boot, to reinstall kp52? | 14:15 |
| Estel-temp | 3. Could you, in future, bump version numberof things when changing something, even if they're not released in repos? your practice of changing shit without buimping version number makes proper testing and debugging a PITA | 14:15 |
| Estel-temp | kerio, any better ideas? :P I'm all ears (with feet) | 14:16 |
| kerio | i told you | 14:16 |
| kerio | rescueOS | 14:16 |
| Estel-temp | no u-boot | 14:16 |
| kerio | and flasher | 14:16 |
| Estel-temp | here | 14:16 |
| Estel-temp | well, I can flash from desktop, too | 14:16 |
| kerio | so? rescueOS isn't even supposed to be loaded by uboot | 14:16 |
| kerio | it's supposed to be ramloaded via flasher | 14:16 |
| Pali | Estel-temp, yes I rebooted my device more times | 14:17 |
| Estel-temp | eh, what exactly rescueOS have that will help me, which accessing rootfs from backupmenu don't have? | 14:17 |
| kerio | fire up rescueOS, unpack the latest modules in /lib/modules, flash the latest kp52 fiasco (you can find it by unpacking the kernel-power deb) | 14:17 |
| kerio | oh, backupmenu boots? | 14:17 |
| kerio | then it's fine too | 14:17 |
| kerio | but i didn't know you could access the rootfs from backupmenu | 14:17 |
| Estel-temp | kerio, yea, said it twice at the beginning, backupmenu boots ok | 14:17 |
| Pali | Estel-temp, boot stock maemo kernel and update to last kp version | 14:17 |
| Estel-temp | 1. enter terminal 2. mountroot | 14:17 |
| kerio | >cssu-thumb | 14:17 |
| Estel-temp | 3. root is at /tmp/mnt/rootfs | 14:17 |
| kerio | Estel-temp: ah yes, the terminal | 14:17 |
| Pali | kerio, no 0xFFFF does not support Mk II protocol (for softupd) yet | 14:18 |
| kerio | it doesn't work for me, my login shells are /bin/bash | 14:18 |
| Estel-temp | Pali, can't boot stock kernel, cssu-thumb | 14:18 |
| Pali | Estel-temp, thermal check is somwehere in dsme, no idea how to turn off it | 14:18 |
| kerio | probably a rd-mode flag of some sorts | 14:19 |
| kerio | ...hell, why didn't i think of that sooner | 14:19 |
| Estel-temp | Pali, maybe i can do some trick to temporary fix temperature readout to 27.1 instead of 271, boot, and fix it for good via installing latest kp52 and revoking my temp solution? | 14:19 |
| Estel-temp | kerio, thought about r&d, can't find anything related to temp | 14:19 |
| Pali | Estel-temp, if you have access to rootfs, detete rx51_battery.ko | 14:20 |
| Pali | then dsme will fallback to bq27200 | 14:20 |
| Estel-temp | Pali, ok, but I tried commenting out loading it in /etc/event.d/bme and it didn't helped | 14:20 |
| Estel-temp | will try it anyway | 14:21 |
| Pali | rx51_battery is autoloaded | 14:21 |
| Estel-temp | OK | 14:21 |
| Pali | or did you blacklisted it? | 14:21 |
| Estel-temp | good idea | 14:21 |
| Estel-temp | trying it now | 14:21 |
| Estel-temp | I'm glad you made it that way, instead of following DocScrutinizer05 advice to shutdopwn when rx51 is unavailable :P | 14:21 |
| Estel-temp | I would be fucked, then, which is another argument to keep it fallbacking to bq27x00_battery for temperature readouts | 14:22 |
| DocScrutinizer05 | you're fucked anyway | 14:22 |
| kerio | but it's easier to unfuck | 14:23 |
| Estel-temp | I'm not sure if he meant meritocratical argument about my current situation with device | 14:23 |
| Estel-temp | :P | 14:23 |
| Estel-temp | nothing better than contributing arguments, eh | 14:24 |
| DocScrutinizer05 | I want to rmmod "processor" but wouldn't like "acpi_cpufreq" to stop | 14:25 |
| Estel-temp | not related, again ;) | 14:26 |
| Estel-temp | Pali, thanks, booted no problem | 14:27 |
| Estel-temp | redownloading and reinstalling kp | 14:27 |
| DocScrutinizer05 | I want to unload snd_pcm and snd_hwdep and snd_hda_codec, but snd_hda_codec_hdmi and PA should continue to work. And if you don't see how that's related you're honestly fucked | 14:27 |
| kerio | DocScrutinizer05: well, if there's something else that can measure the cpu clock... | 14:28 |
| Estel-temp | exactly. | 14:28 |
| DocScrutinizer05 | THERE IS NOTHING | 14:28 |
| kerio | also, don't say that out loud or lennart will make it happen! | 14:28 |
| Estel-temp | Pali, for future, pretty please, bump version numbers when changing stuff | 14:28 |
| kerio | is TEMP in bq27k fake then? | 14:28 |
| DocScrutinizer05 | yes | 14:28 |
| kerio | ...why does it exist then :S | 14:29 |
| Pali | DocScrutinizer05, please do not remind here poetteringed SW | 14:29 |
| Pali | very very bad example | 14:29 |
| kerio | like, what does it measure? | 14:29 |
| Pali | alsa working fine also when you rmmod snd_hda modules | 14:29 |
| DocScrutinizer05 | kerio: because the chip is meant for a number of different usecases | 14:29 |
| Pali | Estel-temp, now when extras-devel working I can push kp here | 14:30 |
| Pali | Estel-temp, this was problem with maemo.org package interface | 14:30 |
| DocScrutinizer05 | and Nokia is using it in a setup that's frankly not exactly what the chip is meant for at all | 14:30 |
| kerio | DocScrutinizer05: so... it measures the temperature of the chip? | 14:31 |
| DocScrutinizer05 | yes, exactly | 14:31 |
| Estel-temp | kerio, with the detail that DocScrutinizer05 failed to mention on purpose - chip temperature is ~always the same as battery diode | 14:31 |
| kerio | does the temperature change that much between different points, in a n900? :o | 14:31 |
| DocScrutinizer05 | and for N900, you as well could use temp from CPU or temp from cellmo or temp from dunnowhat, | 14:32 |
| Estel-temp | as rx51 sensor have fuckin air and shield plane and insulating layer between it and battery | 14:32 |
| kerio | average *all* the sensors! | 14:32 |
| DocScrutinizer05 | Estel-temp: stop telling utter bullshit | 14:32 |
| Estel-temp | rx51 sensor -> some air and low contact with shield -> insulating sticker on battery -> cells | 14:32 |
| DocScrutinizer05 | wtf is "battery diode"??? | 14:33 |
| Estel-temp | before sensor got info about cell temp, cell temp is already dissicipated on whole ground plane | 14:33 |
| Estel-temp | DocScrutinizer05, stop fuckin with catching me on words, you know exactly what I mean | 14:33 |
| kerio | and now for something completely different: why do we have a rtcom-messaging-ui-portrait package instead of updating rtcom-messaging-ui? | 14:33 |
| DocScrutinizer05 | stop telling shit you never tested!! | 14:33 |
| Estel-temp | btw the above is tsted empirically | 14:33 |
| Estel-temp | I have tested it, and you probably haven't | 14:33 |
| DocScrutinizer05 | bullshit! | 14:33 |
| Estel-temp | my fuckin backcover was 10 C hotter than rx51 sensor measured, due to shield pkane dissicipation | 14:34 |
| Estel-temp | told ya yesterday | 14:34 |
| DocScrutinizer05 | I don't give a shit about temperature of your fucking BACKCOVER! | 14:34 |
| Estel-temp | both sensors are pointless for measuring cell temperature | 14:34 |
| Estel-temp | my fuckin backcover was heated due to cell being hot. | 14:34 |
| DocScrutinizer05 | shut up telling shit!!! | 14:34 |
| Estel-temp | stfu yourself, you're clueless in this case, and pretent to play expert, as usual. ;) | 14:35 |
| Estel-temp | test before shouting left and right. | 14:35 |
| Estel-temp | both sensors doesn't have a slightest clue about cell temperature, tested in practice. | 14:35 |
| Estel-temp | not in some ee theory bullshit. | 14:35 |
| DocScrutinizer05 | if you continue telling that sensor is useless, you as well can get a ban here, for risking other people's hardware and health | 14:36 |
| Estel-temp | yea, sure. Go fuck yourself, with that kind of argument, as it's pathetic. From my experience in all devices i own, that sensor is useless. Your results may wary. Happy now! | 14:36 |
| Estel-temp | Pali, only kernel-power modules changed, or other kp packages too? | 14:37 |
| DocScrutinizer05 | your experience sucks, you're incapable of reading sensor data and interprete it | 14:37 |
| DocScrutinizer05 | so the sensor is useless FOR YOU | 14:37 |
| Pali | Estel-temp, from which date? | 14:37 |
| Estel-temp | fine, everyone is free to take own conclusions, and Pali is free to keep dsme fallback to bq27x00 in rx51 absence. Go and ban him for "risking other peoplems devices", we will see how long you will have chanop after that | 14:38 |
| Estel-temp | you only have balls to attack me, I would like to see you using such threats again fmg or pali. No balls for that, DocScrutinizer05 ? | 14:38 |
| DocScrutinizer05 | since YOU have not the slightest clue how to process the raw data from sensor to get meaningful results from it | 14:38 |
| kerio | Pali: changing the gconftool key makes the battery icon disappear in the status area (not menu), maybe you should force a redraw of some sorts after *_gconf_notify is called? | 14:38 |
| kerio | (battery applet) | 14:39 |
| Estel-temp | Pali, no idea, should I reinstall all kp packages? | 14:39 |
| Estel-temp | including flasher? | 14:39 |
| Pali | kerio, after (re)installing applet you need to reboot device | 14:39 |
| Pali | after that changing gconf key should work without problems | 14:39 |
| kerio | s/reboot device/killall hildon-status-menu/ | 14:39 |
| Estel-temp | Pali, I'm quite afraid, as one, when I dpkg -i kernel packages from same nominal version, I got kernel in nand fckd. up. | 14:40 |
| kerio | although yeah, it's probably the install, sorry for the noise | 14:40 |
| DocScrutinizer05 | go the fuck check chanlog from ~1 year ago where we first discussed PID algo to improve sensor reading | 14:40 |
| Pali | kerio, killall -9 (-6 is not enought) | 14:40 |
| Estel-temp | pid alghoritm isn't as bad to cause sensor have delay of reading temperature in factors of minute or so. | 14:40 |
| DocScrutinizer05 | instead of stating bullshit here, rather learn what a PID can do for the sensor | 14:41 |
| Estel-temp | I've measured it using external temp probes, and due to heat dissicipation in shield plane, cell was 10C hotter than sensor received | 14:41 |
| DocScrutinizer05 | OMG | 14:41 |
| DocScrutinizer05 | fool | 14:41 |
| Estel-temp | it's just that ground plane buffered temp., before it got heated to same level as cell. | 14:41 |
| DocScrutinizer05 | so what? | 14:42 |
| Estel-temp | this cell on PCB can't have a clue about cell temperature, as shield is between it and cell. + some insulating sticker and little air, too... | 14:42 |
| DocScrutinizer05 | cell on PCB? am I again supposed to "know what Mr E meant"? | 14:42 |
| Estel-temp | so what? so that, if cell would get 100C and explode, sensor wouldn't know it before it would be too late, anyway | 14:42 |
| Estel-temp | both sensors measure average ground plane temperature, in practice | 14:43 |
| Estel-temp | BOTH rx51 and bq27x00, thats why they always have same data | 14:43 |
| DocScrutinizer05 | bullshit | 14:43 |
| Estel-temp | as ground plane average temp. and that is what both sensors get in REAL LIFE | 14:43 |
| Estel-temp | well | 14:43 |
| DocScrutinizer05 | for me they NEVER have same data | 14:43 |
| Estel-temp | then you got special device. nd "same data" I don't meant fractions of C difference | 14:44 |
| Estel-temp | I mean anything important for real life. | 14:44 |
| kerio | user@kerio900:~$ cat /sys/class/power_supply/*/temp | 14:44 |
| kerio | 258 | 14:44 |
| kerio | 270 | 14:44 |
| DocScrutinizer05 | and your point is moot anyway, since even if they had same data for you so far, maybe (no, for sure) they won't shortly before cell explodes | 14:44 |
| Estel-temp | never ever more than 0.4 C difference in my countless tests in 4 different devices, 2 revisions | 14:44 |
| kerio | 1.2°C | 14:44 |
| Estel-temp | kerio, said that your results may wary. On hotter temps it's more evenl. | 14:45 |
| Estel-temp | try at ~50 C | 14:45 |
| Estel-temp | degrees | 14:45 |
| Estel-temp | anyway, thanks for help, Pali and kerio | 14:46 |
| *** Estel-temp has quit IRC | 14:46 | |
| DocScrutinizer05 | this guy is arguing both are useless but obviously both are same and thus it's sane to use B if we don't have A (while nobody been able to explain to me WHY we wouldn't have A - except for some idiot removing the module needed) | 14:46 |
| DocScrutinizer05 | this is even worse than Poettering rationale | 14:47 |
| kerio | DocScrutinizer05: the correct behaviour would be to not use the temperature and show a "Temperature reading not available, overheating will go unnoticed, be careful" message | 14:47 |
| kerio | as opposed to refusing to boot | 14:48 |
| DocScrutinizer05 | which is absolutely incorrect since nobody has complained about that error to Nokia yet, otherwise Nokia would've recalled all devices from market | 14:48 |
| *** Martix has quit IRC | 14:49 | |
| DocScrutinizer05 | when idiots like estel don't understand a shit about thermal management, safety, and sensor normalizing, then we for sure shouldn't assume Nokia been similarly idiotic | 14:50 |
| DocScrutinizer05 | look, depending on what else is influencing and creating error on R1110 bat-temp-sensor, the signal for shutdown might be: delta-temp > ( t(explode) - t(sensor) ) / 100 PER minute | 14:52 |
| DocScrutinizer05 | the absolute sensor reading is next to meaningless anyway, when idiots like estel take it verbatim | 14:53 |
| DocScrutinizer05 | probably the formula is even more complex, and as well might have 10 variables or 20, instead of just one which is raw value from R1110 | 14:54 |
| kerio | the formula in dsme? | 14:54 |
| DocScrutinizer05 | variables like "tx power of cmt" | 14:55 |
| DocScrutinizer05 | kerio: I dunno if Nokia placed all of that algo to normalize and weigh sensor data for shutdown inside rx51-battery or whatever the driver servicing R1110, or has split some or all of it into dsme | 14:56 |
| kerio | i thought rx51-battery was part of bme-replacement | 14:57 |
| DocScrutinizer05 | I don't give a shit about that | 14:57 |
| kerio | well now i do, because i want to know if it's doing the correct thing | 14:57 |
| DocScrutinizer05 | I know a bit about thermal management and about sensor normalization and calibration, and I know there are different thermal-object-surface profiles for dsme (iirc), for cert and for normal operation | 14:59 |
| kerio | cert? | 14:59 |
| DocScrutinizer05 | CE/whatever certification | 14:59 |
| DocScrutinizer05 | for sure Nokia knows a bit more about that sensor than Estel, and for sure Nokia wouldn't shrug off a threat that devices go up in flames because that sensor wouldn't deliver the data THEY need to shut down charging just in time | 15:01 |
| DocScrutinizer05 | anyway estel's argumentation chain is broken from starting consideration all the way til final conclusion | 15:02 |
| DocScrutinizer05 | a usual pattern for him, he's doing exactly same for e.g. OC | 15:03 |
| DocScrutinizer05 | wrong illogical conclusions based on made up facts and unrelated facts | 15:04 |
| DocScrutinizer05 | he's always doing that to get stuff his way | 15:04 |
| DocScrutinizer05 | then he starts blaming others for not having a clue | 15:05 |
| DocScrutinizer05 | kerio: even when the sensor doesn't do *any* proportional-integral-differential normalization of the temperature displayed, and dsme doesn't do as well, it is still highly likely that Nokia had data about highest temperature gradient (aka heatup per time) the LiIon might develop, and how much that's delayed by the sesnor construction properties, and then Nokia picked a shutdown temperature that takes all that into account | 15:15 |
| DocScrutinizer05 | and I *bet* that r1110 and bq27200 differ massively 30s or a minute after you inserted a 70°C heated battery (dummy) into a N900 at room temperature | 15:16 |
| freemangordon | DocScrutinizer05: funny fact: | 15:17 |
| DocScrutinizer05 | since bq27200 is way farther away from battery than R1110, and also better shielded by a semi-hermetic shielding can | 15:17 |
| freemangordon | /* Thermal algorithm for estimating surface temperature: */ | 15:17 |
| freemangordon | /* | 15:17 |
| freemangordon | * Based on measurement findings brought forth in Thermal measurement | 15:17 |
| freemangordon | * results/manager review session on 2009-05-18, the surface temperature | 15:17 |
| freemangordon | * can be estimated by subtracting 7 deg C from battery temperature: | 15:18 |
| freemangordon | */ | 15:18 |
| freemangordon | thermalobject_surface.c | 15:18 |
| freemangordon | DocScrutinizer05: not sure whether it is not the same for battery temp, something like " based on the speed of light and my hangover, battery temp is sensor temp -10 deg" | 15:19 |
| freemangordon | do not overtrust Nokia ;) | 15:19 |
| DocScrutinizer05 | Nokia can't be worse than e*_'s "rationale" | 15:20 |
| freemangordon | DocScrutinizer05: though i agree that we should not rely on bq fro battery temp, I guess the chip is heating itself | 15:20 |
| ShadowJK | There's no significant amount of self-heating, I believe | 15:22 |
| freemangordon | ShadowJK: sure, my point is that thermistor is missing even that | 15:23 |
| DocScrutinizer05 | not in chip, but next to it it seems | 15:23 |
| DocScrutinizer05 | all my bq-logs show that bq27200 temp rises significantly and rather quickly when current (in or out of battery) increases | 15:24 |
| freemangordon | DocScrutinizer05: though iiuc there IS slowdown in temp spread from battery to the thermistor | 15:25 |
| DocScrutinizer05 | I haven't differentiated out yet if it's caused by battery current or by charger and consumer chips | 15:25 |
| freemangordon | DocScrutinizer05: is bq near SoC? | 15:25 |
| DocScrutinizer05 | freemangordon: sure there is a significant delay | 15:26 |
| DocScrutinizer05 | freemangordon: on N900 basically everything is near to everything ;-) | 15:26 |
| freemangordon | :D | 15:26 |
| freemangordon | yep, right | 15:26 |
| ShadowJK | Well all that energy is dissipated into the board where bq27 and thermistor sits | 15:26 |
| freemangordon | :nod: | 15:27 |
| freemangordon | but for sure it is position dependent. is thermistor smd? | 15:27 |
| DocScrutinizer05 | yep | 15:28 |
| DocScrutinizer05 | you can *see* it thru the aperture for the testpoints under battery | 15:28 |
| freemangordon | hmm, not sure what to think then, the board is heatng/cooling bith devices | 15:28 |
| DocScrutinizer05 | it sits between the most outer battery contact and that outer aperture | 15:29 |
| freemangordon | *both | 15:29 |
| DocScrutinizer05 | you can argue that R1110 is in contact to PCB only on 2 points of one of its 6 surfaces | 15:30 |
| freemangordon | but still, aiui ,work and current measurement done by bq heats it | 15:30 |
| DocScrutinizer05 | and for sure not on pads that are designed as heatsink to a huge gndplane | 15:30 |
| DocScrutinizer05 | no, the current flowing to any of bq27x00's pins is almost immeasurable | 15:31 |
| freemangordon | DocScrutinizer05: hmm, so you think that thermal resistance thermistor->board makes it more suitable for battery temp measurement? | 15:31 |
| DocScrutinizer05 | more suitable than bq27200 for sure | 15:32 |
| freemangordon | :nod: | 15:32 |
| DocScrutinizer05 | while distance cell<->R1110 is 2mm airgap with direct sight for radiation heat, the dsitance cell<->bq27200 is 15mm with 2 layers of material isolating both airflow and radiation from it | 15:33 |
| ShadowJK | I imagine a more interesting metric would be temperature differential between bq and thermistor, a large differential would indicate heating originating from battery? | 15:36 |
| DocScrutinizer05 | so stating both components deliver same temperature reading is like saying my heating and my fridge's freezer compartment have same temperature all the time. Might be true when none is seeing anything that makes it differ in temperature from ambient temperature in my flat | 15:36 |
| DocScrutinizer05 | ShadowJK: good point | 15:36 |
| DocScrutinizer05 | I *still* miss any rationale WHY the heck somebody needs to unload that rx51-battery kernel module, so r1110 wouldn't be available for sensor | 15:39 |
| DocScrutinizer05 | I mean, what are we discussing here? | 15:39 |
| *** chainsawbike has quit IRC | 15:40 | |
| *** chainsawbike has joined #maemo-ssu | 15:42 | |
| DocScrutinizer05 | golden rule: never accept inferior alternatives for safety relevant stuff, not when replacing a broken component, and not when a rmmod'ed kernel module (for *whatever* reason somebody might want to do such nonsense) makes original safety concept defunct | 15:42 |
| ShadowJK | Well in same style, why would anyone ever want to unload bme, or unplug battery when device is on? :D | 15:45 |
| ShadowJK | Fridges are a real pain to temperature control btw :( | 15:45 |
| DocScrutinizer05 | unless bme-replacement follows this rule and implements bme safety measures in the faithful following of original spirit and design rationale, it would even qualify for removal from maemo-extras for being hazardous to user's health and hw | 15:45 |
| * ShadowJK has been hacking his fridge and added an industrial process controller :D | 15:45 | |
| *** futpib_ has quit IRC | 15:48 | |
| DocScrutinizer05 | in this sense using bq27200 is even worse than using a hardcoded value or ignoring the temperature (err, a tautology), since when ignoring it you can tell user "we ignore that, use on own peril! the dangers are: a:... b:...". When you think bq27200 is just as good as R1110, then what shall user think? He'll think his device is perfectly safe when in fact it isn't | 15:49 |
| DocScrutinizer05 | we removed BM-v1 from repos, since in some rare cases it might fuckup user devices. | 15:52 |
| Estel_ | What we're discussing here? no matter of theretical shit DocScrutinizer05 is presenting here, device shouldn't refuse to boot if rx51 temp reading isn't available, period. | 15:53 |
| DocScrutinizer05 | I don't see gambling with thermal management and OT/UT-safety ever making it to the repos either | 15:53 |
| Estel_ | accidentally, I just experienced it real life - I was able to boot thanks to bq27x00_battery temp readinf fallback, and fix rx51 | 15:53 |
| DocScrutinizer05 | idiocy | 15:53 |
| Estel_ | It's same bullshit as DocScrutinizer05 arguments again N999overclocking. Theoretically, he khave a point, but no one ever seen that in real life | 15:54 |
| DocScrutinizer05 | "device shouldn't refuse to not when kernel got nuked" BWAHAHAHA | 15:54 |
| Estel_ | I don't give a shit about what you think is right, if it works again device owner, making life harder. | 15:54 |
| Estel_ | it's not kernel, it's fuckin module that is irrelevant for anything (rx51) | 15:54 |
| DocScrutinizer05 | Estel_: stop telling shit! You can't ever prove if nobody ever seen it in real life. that's obvious and self-evident | 15:54 |
| Estel_ | I got idea -make script for yourself, that will shutdown device when no rx51 module. Place it in event.d. And leave others in peace | 15:55 |
| Estel_ | DocScrutinizer05, no known reports of anything even remotely related to OC damage in N9090 | 15:55 |
| Estel_ | your last exampleds were about broken flex cable (lol!) | 15:55 |
| DocScrutinizer05 | no, sir. I will keep this shit from happening to those with similarly poor clue but less interest than you | 15:56 |
| Estel_ | keep your theory for aademic refference, but don't rape freal life use cases by it. If Pali would follow your advices, I would have to reflash/resdtore from backup, due to NO VALID REASON just 10 minutes ago | 15:56 |
| Estel_ | so real life beats any theoretical shit, IMO | 15:56 |
| DocScrutinizer05 | forget it | 15:56 |
| Estel_ | ok ;) | 15:57 |
| DocScrutinizer05 | we won't implement a "cat estel's idiocy borkage done to system by allowing it to boot nevertheless no matter what he did" | 15:57 |
| Estel_ | there is 2345677654327875643 reasons why rx51 module can not be loaded, and 99,99% of them doesn't have anything to do with dangerous temperature conditions | 15:57 |
| DocScrutinizer05 | catch* even | 15:57 |
| Estel_ | your logic is like N900 refusing to boot due to camera failure | 15:57 |
| Estel_ | perfect idiocy making life harder. | 15:57 |
| Estel_ | becauise some random borked EE decided that camera module is oh so important, that device can't boot if it MALF, or user get raped by exploding camera lens | 15:58 |
| DocScrutinizer05 | thermal management is a tad more relevant for safety than camera | 15:58 |
| Estel_ | excvept for that sensor won't know if battery explode due to thermal problems | 15:59 |
| Estel_ | because it will be dead at that time already... | 15:59 |
| Estel_ | due to delay in therm sensing | 15:59 |
| Estel_ | anyway | 15:59 |
| DocScrutinizer05 | stop telling bullshit | 15:59 |
| Estel_ | as said rx51 nodule can be unloaded for shitload of reasons | 15:59 |
| Estel_ | and 99% of them are not related to overrheating battery | 15:59 |
| DocScrutinizer05 | you never have tested that, you're pulling it right outa your ass | 16:00 |
| Estel_ | kerio is right - no rx51 module? display message "warning, rx61 module not loaded, overheat protection is OFF, use at own risk" | 16:00 |
| Estel_ | instead of shutting down device | 16:00 |
| Estel_ | bullshit, I have tested it dozens of times | 16:00 |
| DocScrutinizer05 | now, who needs a script? | 16:00 |
| Estel_ | during my tests with 1250 mA charging | 16:00 |
| DocScrutinizer05 | to implement his own foolish concepts? | 16:01 |
| Estel_ | well, This script is to satisfy fools like you. I just don't wanna device shutdown for assrage invalid reasons | 16:01 |
| DocScrutinizer05 | ooh you have exploded a dozen N900? congrats | 16:01 |
| Estel_ | reminds me of poettering | 16:01 |
| Estel_ | asla can work without irrelevant shit, pulseaudio goes down in flames | 16:01 |
| DocScrutinizer05 | sorry, you're telling lies all the time | 16:01 |
| Estel_ | fine, so let's agree that we disagree. I'm glad that Pali doesn't follow your imagoinable wisdom, this time. | 16:02 |
| Estel_ | for me you're doing sophism (see wikipedia) all the time, which is kind of lying, anyway. | 16:02 |
| DocScrutinizer05 | I'm glad that you're not the one to decide *anything* | 16:03 |
| Estel_ | same here, as you're not deciding anything, too ;) | 16:03 |
| Estel_ | happy now? consensus. | 16:03 |
| DocScrutinizer05 | well, you're free to think that | 16:03 |
| DocScrutinizer05 | wait til Pali tries to upstream or promote his safety threat | 16:04 |
| Estel_ | well, you're free to threat me about banning due to me writing about results of myh temp measurement, due to "risk for other users". At the saame time, you're not threating Pali by ban, despite that he publish software, that fallbacks to bq27x00 for tewmp readout | 16:04 |
| DocScrutinizer05 | and you'll learn what I can do | 16:04 |
| Estel_ | because it need BALLS to stand behind your argumentation | 16:04 |
| Estel_ | you know you would los chanop by threating any active code contributor | 16:05 |
| DocScrutinizer05 | don't talk about stuff you miss and don't have a clue what it is | 16:05 |
| Estel_ | I don't care about your ban threats, and stand behind nmy argumentation nevertheless. You're lacking courage to stand behind your useless threats, when it comes to more influent people than you. | 16:05 |
| Estel_ | thats is difference between us ;) | 16:06 |
| DocScrutinizer05 | blablabla | 16:06 |
| Estel_ | sure. for me you're just coward - you would gladly do same threats and kicks/bans to Pali, but you know you would lose chanops in ~2days, then. After all, if you really belive that his implementations is threat to users safety, have balls to stand behind your argumentation. | 16:08 |
| Estel_ | otherwise, go and f yourself. I'm out. | 16:08 |
| DocScrutinizer05 | blablabla | 16:08 |
| DocScrutinizer05 | gtfo | 16:08 |
| DocScrutinizer05 | bye | 16:08 |
| DocScrutinizer05 | now read the story what little silly estel thought how IRC works and how he could provoke an experienced chanop into doing stupid things | 16:11 |
| DocScrutinizer05 | last futile desparate effort to defend own idiotic concepts, while seeing them going down the drain of crystal clear logic | 16:12 |
| DocScrutinizer05 | just for the record: [2013-03-28 13:36:01] <DocScrutinizer05> if you continue telling that sensor is useless, you as well can get a ban here, for risking other people's hardware and health | 16:15 |
| *** Martix has joined #maemo-ssu | 16:20 | |
| DocScrutinizer05 | btw when maemo doesn't boot due to some fool messed up a kernel module, then you either need to forbid messing with that module, or put up a clear warning that messing with that module might result in system not booting, or (best option) rethink your system config WHY it doesn't boot without that module and if that makes any sense. For me it doesn't make any sense to abort booting when *any* of bme-replacement fails during init | 16:26 |
| kerio | the issue is that dsme really wants a temperature | 16:26 |
| kerio | or it shuts down | 16:26 |
| DocScrutinizer05 | that's however not the fault of bme-replacement or anything else depending on a module, it's the fault of that module causing bootup to fail if that dependency is missing | 16:27 |
| DocScrutinizer05 | kerio: well, don't you think that this been a deliberate purposeful design decision then? Due to the rationale that this sensor is safety relevant and you shouldn't boot your device when it is failing? | 16:29 |
| ShadowJK | could dsme use madc directly, like in stock maemo, when module isn't loaded? | 16:30 |
| ShadowJK | I assume it does that now when i can run sans bme | 16:30 |
| DocScrutinizer05 | technically, or logically? | 16:30 |
| DocScrutinizer05 | rather, I guess it could, no matter if tech or log | 16:31 |
| kerio | ShadowJK: i'm not quite sure of how dsme-thermalobject works | 16:32 |
| kerio | but maybe it keeps the old temperature if there's no new data? | 16:32 |
| DocScrutinizer05 | but what you report isn't in line with what kerio says | 16:32 |
| kerio | stopping bme leads to the battery applet freezing, for instance | 16:32 |
| ShadowJK | hm | 16:33 |
| kerio | DocScrutinizer05: i'm not sure that dsme has a builtin protection against not having the temp sensor | 16:33 |
| DocScrutinizer05 | I guess it doesn't | 16:33 |
| kerio | i think it's just that the temperature defaults to something that's outside of the range of safe operation | 16:33 |
| DocScrutinizer05 | since bme itself is protected against segfault etc | 16:34 |
| DocScrutinizer05 | and communication between dsme and bme is via IPC | 16:34 |
| DocScrutinizer05 | and once dsme could establish a IPC connection to bme, it doesn't mind bme going down, since that's something that can't happen on accident without dsme taking care about it with bme restarts and eventual reboot when bme keeps segfaulting | 16:36 |
| DocScrutinizer05 | safety concept is complete and has no loopholes | 16:36 |
| DocScrutinizer05 | of course DSME *could* reboot as well when IPC to bme stalls, but that's probably not intended | 16:37 |
| DocScrutinizer05 | and would btw have made our life pretty fsckd when we tried to get hostmode running | 16:38 |
| DocScrutinizer05 | on startup make sure bme came up correctly and can communicate via IPC, otherwise shut down since relevant safety bits are missing. | 16:40 |
| DocScrutinizer05 | when bme IPC vanishes after that, don't care since some other mechanism takes care about bme coming back in due time. That other process will also reboot when bme can't get restarted | 16:41 |
| kerio | does that mean that h-e-n is unsafe, due to lack of temperature measurement? | 16:42 |
| DocScrutinizer05 | err, H-E-N doesn't charge | 16:42 |
| DocScrutinizer05 | and booston has an overtemp cutout based on bq24150 chip temperature | 16:43 |
| DocScrutinizer05 | 5V going down -> hostmode stops | 16:43 |
| DocScrutinizer05 | so no, I wasn't overly sloppy in considering safety concerns with H-E-N | 16:44 |
| DocScrutinizer05 | for charging-hostmode I wasn't able to access the battery temperature, though I planned and investigated how to do it. So charging-hostmode is as good as it gets, using overtemp cutout of bq24150 chip to stop charging | 16:48 |
| DocScrutinizer05 | however charging-hostmode is definitely NOT meant for end user with no clue | 16:48 |
| DocScrutinizer05 | kerio: what a question! | 16:49 |
| kerio | i suppose that bq24k.ko is a bit safer with that regard | 16:50 |
| kerio | because it still lets you access the usual temp monitor | 16:50 |
| DocScrutinizer05 | I dunno | 16:50 |
| DocScrutinizer05 | I don't think bq24k.ko does (or even should) export R1110 | 16:52 |
| DocScrutinizer05 | anyway H-E-N and the kernel patch botches we did were never meant to go upstream, though recently Pali started on that - dunno why since it's a very nasty and platform specific evil botch anyway | 16:55 |
| DocScrutinizer05 | so I don't care about augmenting H-E-N anymore, most users are just happy the way it works right now | 16:55 |
| DocScrutinizer05 | R1110 is a sensor and should get exported in sysfs as such | 16:58 |
| DocScrutinizer05 | bq27200 is another sensor, and should get... (see above) | 16:59 |
| DocScrutinizer05 | if other kernel modules need infut from those sensors, they are free to read them the usual way | 17:00 |
| DocScrutinizer05 | they shouldn't hijack them | 17:00 |
| DocScrutinizer05 | input* | 17:00 |
| DocScrutinizer05 | s/hijack/assimilate, borg style,/ | 17:01 |
| *** sunny_s has joined #maemo-ssu | 17:02 | |
| DocScrutinizer05 | R1110 is absolutely unrelated to bq24150 | 17:02 |
| DocScrutinizer05 | just like fan is unrelated to CPU | 17:03 |
| Pali | what is R1110? | 17:08 |
| DocScrutinizer05 | the thermistor labeled "battery themperature sensor" in schematics, connected to GAIA ADC | 17:09 |
| *** lizardo has quit IRC | 17:45 | |
| *** jon_y has quit IRC | 17:55 | |
| *** jon_y has joined #maemo-ssu | 17:55 | |
| *** sunny_s has quit IRC | 18:05 | |
| *** jon_y has quit IRC | 18:09 | |
| *** sunny_s has joined #maemo-ssu | 18:09 | |
| *** sunny_s has quit IRC | 18:12 | |
| *** NIN101 has joined #maemo-ssu | 18:50 | |
| *** Martix_ has joined #maemo-ssu | 18:59 | |
| *** Martix has quit IRC | 19:01 | |
| kerio | merlin1991: server unreachable? | 19:18 |
| merlin1991 | hm? | 19:18 |
| kerio | ah nvm, stupid ipv6 | 19:18 |
| kerio | oh no, it tried ipv4 too | 19:19 |
| kerio | Connecting to maemo.merlin1991.at (188.40.39.11) | 19:19 |
| *** XDS2010 has quit IRC | 19:20 | |
| kerio | your server is slow as fuck! | 19:20 |
| kerio | what happened? | 19:20 |
| merlin1991 | well I can happily ping here | 19:20 |
| merlin1991 | lets see | 19:20 |
| kerio | did you run out of internets | 19:21 |
| merlin1991 | kerio: nah looks fine here | 19:21 |
| kerio | now it does | 19:21 |
| kerio | you fixed it! | 19:21 |
| merlin1991 | not much traffic, and cpu is chillin | 19:21 |
| kerio | hm, still slow from the n900 | 19:22 |
| kerio | my connection is going fine, though | 19:23 |
| *** XDS2010 has joined #maemo-ssu | 19:51 | |
| *** M13 has quit IRC | 19:57 | |
| *** XDS2010 has quit IRC | 20:12 | |
| *** arcean has joined #maemo-ssu | 20:18 | |
| Estel_ | Pali, how your bme replacement does shutdown? | 20:23 |
| Pali | hald-addon-bme send battery empty signal to dsme | 20:23 |
| Estel_ | DocScrutinizer05 wrote few times very interesting bit about certain shutdown "levels" - sadly, while he got enough free time to write it few times on IRC on different ocassions, he is too lazy to write in on bme repl. wiki, despite being repeatedly asked to | 20:24 |
| Estel_ | hm | 20:24 |
| Estel_ | I mean, does it have this first "grace" shutdwodn, and later, ungraceful shutdown later? | 20:24 |
| Estel_ | or does it do it like stock maemo did, just triggered by different thing? | 20:24 |
| Estel_ | I mean, you re-created the way shutdown itself is done, or dsme does it the same way as before, just triggered by different hald-addon-bme? | 20:25 |
| DocScrutinizer05 | shut up and check your facts | 20:25 |
| Estel_ | ~bme-replacement | 20:25 |
| infobot | rumour has it, bme-replacement is http://atrey.karlin.mff.cuni.cz/~pali/rx51-bme-replacement http://atrey.karlin.mff.cuni.cz/~pali/projects/maemo/bme-replacement.html See also: http://wiki.maemo.org/Bme_replacement . Please, use wiki page to report bugs/problems and/or solutions to them! | 20:25 |
| DocScrutinizer05 | >>21:11, 27 March 2013 joerg_rw (Talk | contribs | block) (9,362 bytes) (→3. bq27x00_battery sysfs node reports -ENODATA when not calibrated)<< | 20:26 |
| Estel_ | DocScrutinizer05, sorry, just been through it | 20:27 |
| Estel_ | true, you've written it, so take my excuses for that :) | 20:28 |
| DocScrutinizer05 | your constant shit-spilling is becoming not only boring but actually annoying | 20:28 |
| Estel_ | well, I pestered you for 4 fckin days, and last time I checked it wasn't there ;) | 20:28 |
| Estel_ | I'm glad you decided to share your undoubtable (no irony) knowledge about subject, there | 20:28 |
| DocScrutinizer05 | I don't give a fuck about your lame excuses for your shit-spilling | 20:29 |
| Estel_ | It's expectable, after all you're the one that never excuses for lame things you do :P | 20:29 |
| Estel_ | when I do mistake, I have no problems admiring it ;) | 20:29 |
| Estel_ | Pali, what about: | 20:29 |
| Estel_ | we don't need to read registers of bq27200, what we need are proper decoded data from bq27200 available in sysfs nodes like /CI etc. This is perfectly allowable even for power-supply according to readme excerpts shadowjk digged up. | 20:30 |
| Estel_ | (from wiki) | 20:30 |
| Estel_ | sounds sane | 20:30 |
| DocScrutinizer05 | your mistake is talking to me, or talking about stuff you have no clue | 20:31 |
| Estel_ | Pali, also, good point on wiki about edv1 flag - it may *never* get set, id vdq was changed to 0, due to device shutdowns, restarts, charging/discharging etc | 20:31 |
| Estel_ | haha, could agree with first part - talking to you *may* be a mistake | 20:31 |
| DocScrutinizer05 | and nobody cares about your excuses | 20:31 |
| Estel_ | ~docscrutinizering | 20:31 |
| infobot | rumour has it, docscrutinizering is same as ~poettering, just triple as much | acting agressively, against anyone daring to keep own opinion | kicking people from IRC, when getting out of argument during civilized discussion | acting silly, chaotical, while beliving in fighting for "greater truth" | 20:31 |
| Estel_ | LOL | 20:31 |
| Estel_ | ~factinfo docscrutinizering | 20:31 |
| infobot | error: you do not have enough flags for that. (o required) | 20:31 |
| infobot | docscrutinizering -- created by scorpious <~Estel@178.180.16.158.nat.umts.dynamic.t-mobile.pl> at Fri Mar 8 01:21:33 2013 (20 days); last modified at Fri Mar 8 01:39:22 2013 by scorpious!~Estel@178.180.16.158.nat.umts.dynamic.t-mobile.pl; it has been requested 6 times, last by Estel_, 14s ago. | 20:31 |
| Estel_ | HAHAHAHHAH !! ! | 20:32 |
| DocScrutinizer05 | you're such a silly baby | 20:32 |
| Estel_ | gimme a second to caught a breath | 20:32 |
| DocScrutinizer05 | omfg, what did we all wrong to be punished with your existence | 20:32 |
| Estel_ | well, it seems that "docscrutinizering" left our little maemo world, never expected to run into such a gem in factoids | 20:33 |
| DocScrutinizer05 | anyway, go get lost somewhere else and die silently, I have other things to do than to continue this silly shit with you | 20:33 |
| Estel_ | it should be docscrutinizing, tho | 20:34 |
| Estel_ | DocScrutinizer05, get a sense of humour | 20:34 |
| DocScrutinizer05 | btw I guess scorpius wasn't happy about you hijacking his nick | 20:34 |
| Estel_ | I'm not sure that it's anyone's nick, at least, wasn't registered ;) | 20:35 |
| Estel_ | but this factoid does have it own seed of truth, admit it | 20:35 |
| Estel_ | you doesn't like people with opposite opinions to yours, very much ;) | 20:35 |
| Estel_ | the reason I LOL'ed so hard is, in fact, that I totally forget about this factoid existence | 20:36 |
| DocScrutinizer05 | and now you're pretending you "run into such a gem in factoids" by mere accident, while in fact you created that factoid with a fake nick, zhat's pathetic | 20:36 |
| Estel_ | not a fake, just random one when used webchat, and I'm not pretending anything | 20:36 |
| Estel_ | forget about it, would I risk the wraith of oh so mighty chanop? :P | 20:36 |
| Estel_ | anyway, sorry for the noise | 20:36 |
| Estel_ | Pali, going back to matter at hand: | 20:36 |
| DocScrutinizer05 | well, you just earned an ignore on infobot, to give you a reason to use fake nicks | 20:37 |
| Estel_ | is EDV1 Flag really spoiled due to vdq going 0 during discharge? | 20:37 |
| DocScrutinizer05 | and you earned another few infraction points on your personal IRC ban account, for spreading another implicit lie | 20:37 |
| Estel_ | kerio, you proposed edv1 flag as way to trigger shutdown, any comment on it being spoiled by vdq0? | 20:38 |
| DocScrutinizer05 | and a few on top for utter stupidity to not even notice that hostmask still said "~estel" | 20:38 |
| kerio | i don't think it is | 20:38 |
| Estel_ | DocScrutinizer05, don't offend my intelligence by pretending that i tried to hide something - first, I would use different IP, second, aren't you accustomed to fact that I'm talking straight into yuour face, havfing in ass useless threats about bans etc? | 20:39 |
| DocScrutinizer05 | bullshit, "run into such a gem in factoids" is crystal clear | 20:39 |
| Estel_ | you're the one cowardly enough to threat me with ban about *talking* that bq27x00 temperature readout is justified, but too afraid to do the same to Pali for *implementing it*actually | 20:39 |
| DocScrutinizer05 | a lame effort to trick people into thinking something that's not reality | 20:40 |
| Estel_ | so I guess man judges by himself, and by own balls. | 20:40 |
| Estel_ | well, see above, I don't have time for this nonsense | 20:40 |
| *** ChanServ sets mode: +o DocScrutinizer05 | 20:40 | |
| Estel_ | kerio, so edv1 flag should be set no matter what? | 20:40 |
| *** DocScrutinizer05 sets mode: +q Estel_!*@* | 20:40 | |
| *** ChanServ sets mode: -o DocScrutinizer05 | 20:40 | |
| *** Estel_ has quit IRC | 20:42 | |
| *** Estel^ has joined #maemo-ssu | 20:43 | |
| *** Estel^ has quit IRC | 20:43 | |
| *** Estel^ has joined #maemo-ssu | 20:43 | |
| Estel^ | kerio, because it is very important, if it could get spoiled, it would mean it can't be used to trigger shutdown | 20:43 |
| kerio | read the datasheet | 20:43 |
| Estel^ | DocScrutinizer05, (if I'm not wrong) added to wiki info that it can get spoiled | 20:43 |
| Estel^ | fine, just trying to maintain data on wiki correct | 20:44 |
| kerio | how hard is it to read the datasheet | 20:44 |
| Estel^ | don't ask me, you proposed it | 20:44 |
| Estel^ | from wiki: | 20:44 |
| Estel^ | NOTE: EDV1 flag might never get set, when discharge (=learning cycle) been "spoiled" by e.g. a short charging period in between. | 20:44 |
| Estel^ | could the one who wrote it reinforce that info by some hard data? | 20:44 |
| Estel^ | datasheet info or smth? | 20:44 |
| Estel^ | I think it's pretty crucial, Pali already coded shutdown depending on edv1 (from gitorious) | 20:45 |
| Estel^ | I'm out for now, real life calls | 20:45 |
| kerio | First End-of-Discharge-Voltage flag. A 1 indicates that voltage on the BAT pin is less than or equal to the EDV1 voltage programmed in EEPROM and the battery has less than or equal to 6.25% of LMD capacity remaining. LMD updates immediately if the VDQ bit is set when this bit transitions from 0 to 1. This bit is cleared to 0 on all resets. | 20:46 |
| kerio | it's pretty clear | 20:46 |
| kerio | and even you could've figured that out, by reading the datasheet | 20:46 |
| *** wumpwoast has quit IRC | 20:59 | |
| *** wumpwoast has joined #maemo-ssu | 20:59 | |
| DocScrutinizer05 | kerio: you're right, I wrote some nonsense there regarding EDV1 | 21:25 |
| DocScrutinizer05 | kerio: I confused it with CI=0 | 21:25 |
| DocScrutinizer05 | EDV1 is obviously independent of a valid learning cycle in progress | 21:26 |
| kerio | hmm, partial charge cycles won't decalibrate, right? | 21:26 |
| kerio | unless it's what brings the cycle counter over 30 or whatever | 21:26 |
| DocScrutinizer05 | partial cycles are added to the cycle count | 21:26 |
| kerio | ;) | 21:26 |
| DocScrutinizer05 | actually cycle counts is computed like total-discharge-sigma-in-mAh/LMD | 21:27 |
| DocScrutinizer05 | so if your LMD is 1000 and you discharge to 900 and then charge to 1000 again for 10 times, you completed one cycle | 21:28 |
| DocScrutinizer05 | on 32 cycles CI=1 | 21:29 |
| kerio | i should probably make a bq27k-detail script that uses the registers file | 21:29 |
| *** Martix_ has quit IRC | 21:40 | |
| *** nox- has joined #maemo-ssu | 21:41 | |
| kerio | hm, can the bq27k eeprom be programmed? | 21:42 |
| ShadowJK | Not on n900 | 21:48 |
| kerio | :( | 21:48 |
| *** sunny_s has joined #maemo-ssu | 21:49 | |
| kerio | i wonder if hald-addon-bme from the bme-replacement uses IMIN to show the green light | 21:52 |
| kerio | probably not | 21:52 |
| DocScrutinizer05 | kerio: bq27k-detail2 is supposed to use the registers/dump file, if that wasn't garbled by formatting it according to non-existing double-registers | 22:00 |
| DocScrutinizer05 | kerio: it worked on neo freerunner, and that system is supposed to be designed by guys who know their shit | 22:02 |
| DocScrutinizer05 | ask PaulFertser if the neo fr bq27k API is ok or not. | 22:02 |
| *** xes has joined #maemo-ssu | 22:07 | |
| *** _rd has joined #maemo-ssu | 22:07 | |
| DocScrutinizer05 | http://wiki.openmoko.org/wiki/GTA02_sysfs#.2Fsys.2Fdevices.2Fplatform.2Fgta02-hdq.0.2Fhdq.2Fdump | 22:07 |
| kerio | ShadowJK: why is EE_EN marked as R/W then? | 22:07 |
| kerio | DocScrutinizer05: that uses the power_supply API | 22:08 |
| DocScrutinizer05 | yes, it does | 22:08 |
| DocScrutinizer05 | http://wiki.openmoko.org/wiki/GTA02_sysfs#power_supply_battery_information | 22:08 |
| ShadowJK | Well you can reprogram it, through pins not exposed, and you need 40 volts to program it | 22:08 |
| DocScrutinizer05 | kerio: because it *is* r/w | 22:09 |
| kerio | but you still need the 40V to program the registers? i see | 22:09 |
| DocScrutinizer05 | actually I think i once investigated and found the relevant pin is accessable | 22:10 |
| ShadowJK | Would need to build some sort of programmer too, because the timing of the 40V burst was important, iir | 22:10 |
| ShadowJK | iirc* | 22:10 |
| DocScrutinizer05 | (Neo FR power_supply) it also missing a few additional sysnodes for stuff like CI etc | 22:11 |
| DocScrutinizer05 | (40V) CBA to open datasheet, since nobody will ever really do it anyway | 22:12 |
| DocScrutinizer05 | I did it once and iirc I came to the conclusion that it *could* get reprogrammed | 22:12 |
| DocScrutinizer05 | if this info was of any relevance for RL, I had sored it in a less volatile corner of my brain | 22:13 |
| DocScrutinizer05 | stored, even | 22:13 |
| ShadowJK | it's slightly less impossible than upgrading ram | 22:13 |
| DocScrutinizer05 | :nod: | 22:14 |
| DocScrutinizer05 | you even have an unused GPIO on tthat chip, also accessible | 22:14 |
| DocScrutinizer05 | the heck, what nifty things you *could* do with all that | 22:15 |
| DocScrutinizer05 | ;-D | 22:15 |
| ShadowJK | heh | 22:15 |
| ShadowJK | I just got 3 different boards in the mail this week, I've got tons of GPIOs and stuff to play with for months to come ;p | 22:16 |
| *** XDS2010 has joined #maemo-ssu | 22:16 | |
| DocScrutinizer05 | hehe | 22:16 |
| DocScrutinizer05 | I even suggested to (ab)use the LCD background LED booster voltage for programming the bq27200, and gating it with a mosfet controlled by that free GPIO ;-) | 22:17 |
| DocScrutinizer05 | I *could* come up with a rework instruction that would actually turn this into a self comprised bq27200 prommer | 22:20 |
| DocScrutinizer05 | but MEH! | 22:20 |
| DocScrutinizer05 | I'd rather come up with a DIY-instruction how to pimp your BL-5J into a smartbat with bq27000 included, and readout viia that nonsensical BSI pin | 22:23 |
| DocScrutinizer05 | N900 could do this, with *minimal* rework | 22:23 |
| DocScrutinizer05 | the battery part however gets a bit tricky | 22:23 |
| kerio | isn't the BSI pin analog? | 22:24 |
| DocScrutinizer05 | and obviously it would break backwards compatibility to stock bme and friends | 22:24 |
| ShadowJK | kerio, it's probably fast enough | 22:24 |
| DocScrutinizer05 | the N900 side of BSI is basically a GPIO | 22:25 |
| DocScrutinizer05 | at least for SoC (not so for cmt) | 22:25 |
| DocScrutinizer05 | HDQ is pretty slow | 22:26 |
| kerio | isn't it bad to have two bq27k in a row? | 22:26 |
| DocScrutinizer05 | silly one-wire protocol | 22:26 |
| DocScrutinizer05 | what would be bad in that? | 22:26 |
| DocScrutinizer05 | well, you have one "useless" 22mR shunt then | 22:27 |
| DocScrutinizer05 | other than that, I can't see negative direct side effects | 22:28 |
| DocScrutinizer05 | the indirect side effects like breaking compatibility to stock BL-5J (well, that could get handled, we did it on Neo FR), and more severe issue, the breaking of fast-shutdown I elaborated about a day ago, these are more problematic side effects of such a project | 22:30 |
| *** dhbiker has quit IRC | 22:30 | |
| kerio | is the unit of 3.57 uV for some of the bq27k registers from the datasheet? | 22:31 |
| DocScrutinizer05 | you can't use HDQ to trigger an IRQ on battery removal | 22:31 |
| DocScrutinizer05 | yes | 22:31 |
| kerio | same for the 29.2? | 22:31 |
| DocScrutinizer05 | yes | 22:31 |
| DocScrutinizer05 | so those are the only two hardcoded values you expect to see in any bq27x00.ko | 22:32 |
| *** dhbiker has joined #maemo-ssu | 22:33 | |
| DocScrutinizer05 | a third hardcoded though override'able value was 22 for thr mR of shunt | 22:33 |
| kerio | 21! | 22:33 |
| DocScrutinizer05 | *shrug* | 22:33 |
| DocScrutinizer05 | whatever makes you smile ;-) | 22:34 |
| DocScrutinizer05 | as long as it's handled as module startup parameter like `modprobe bq27k.ko rs=23` | 22:35 |
| kerio | does it actually change in a significant way between 20 and 22? | 22:35 |
| DocScrutinizer05 | well, obviously it changes all readings by 10% | 22:35 |
| DocScrutinizer05 | except voltage readings | 22:36 |
| kerio | and time | 22:36 |
| DocScrutinizer05 | yeah, and a few "integer" readings | 22:36 |
| DocScrutinizer05 | there's no time | 22:36 |
| DocScrutinizer05 | there's cycle count | 22:37 |
| DocScrutinizer05 | there's TTF/TTE | 22:37 |
| kerio | yeah | 22:37 |
| kerio | that's in minutes | 22:37 |
| DocScrutinizer05 | which I'm not completely sure if it changes with RS | 22:37 |
| kerio | bq27k-detail2 claims it's minutes | 22:37 |
| DocScrutinizer05 | probably not since error/error = 1 | 22:37 |
| DocScrutinizer05 | so LMD*error/current-now*error == LMD/current-now | 22:39 |
| DocScrutinizer05 | given your LMD been learned with same RS setting you currently use for calculating TTE | 22:40 |
| DocScrutinizer05 | kerio: you already fixed my BS on that wikipage? | 22:41 |
| kerio | yah | 22:41 |
| DocScrutinizer05 | fine :-D | 22:41 |
| DocScrutinizer05 | thanks | 22:42 |
| kerio | commit message being "fix misinformation" | 22:43 |
| xes | "fix Docsinformation" ;) | 22:43 |
| kerio | is the delta between celsius and kelvin precisely 273.15 by definition? | 22:44 |
| DocScrutinizer05 | yes | 22:45 |
| DocScrutinizer05 | ~wiki kelvin (temperature) | 22:45 |
| infobot | I couldn't find a matching article in wikipedia, look for yerselves: http://en.wikipedia.org/wiki/Special:Search?search=kelvin+(temperature)&go=Go | 22:45 |
| kerio | DocScrutinizer05: "kelvin" is for the temperature, lord kelvin has a separate page | 22:46 |
| DocScrutinizer05 | ~wiki absolute_zero | 22:46 |
| infobot | At http://en.wikipedia.org/wiki/Absolute_zero (URL), Wikipedia explains: "{{Other uses2|Absolute Zero}} 'Absolute zero' is the coldest possible temperature. More formally, it is the temperature at which entropy reaches its minimum value. The laws of thermodynamics state that absolute zero cannot be reached using only thermodynamic means. A system at absolute zero still possesses quantum mechanical zero-point energy, the energy of its ground state. The ... | 22:46 |
| kerio | yeah, yeah, 1K is 1/273.16ths of the temperature of the triple point of water | 22:46 |
| kerio | oh hysterical raisins | 22:47 |
| ShadowJK | What is the tripple point of water in celcius? | 22:48 |
| DocScrutinizer05 | >>The zero point of any thermodynamic temperature scale, such as Kelvin or Rankine scale, is set at absolute zero. By international agreement, absolute zero is defined as 0K on the Kelvin scale and as −273.15° on the Celsius scale.[1][2] This equates to −459.67° on the Fahrenheit scale[3] and 0 R on the Rankine scale.[2]<< | 22:48 |
| kerio | by definition, 0.01 | 22:48 |
| kerio | did the physicists figure out a serious way to define the kilogram yet? | 22:49 |
| ShadowJK | used to be 0 though :) | 22:49 |
| ShadowJK | kerio, nope | 22:49 |
| ShadowJK | Well, they have machines that they're trying to use to do it | 22:49 |
| ShadowJK | but everybody's machines are giving different results | 22:49 |
| kerio | ShadowJK: so very related: http://www.youtube.com/watch?v=r7SOLBuy8HI | 22:49 |
| ShadowJK | kerio, yes that's where I saw it ;) | 22:50 |
| DocScrutinizer05 | and the Pt ur-kg in Paris still is losing weight every year, and nobody knows where the mass is vanishing to ;-P | 22:50 |
| DocScrutinizer05 | http://en.wikipedia.org/wiki/File:CGKilogram.jpg | 22:52 |
| ShadowJK | Is it the weight losing mass, or earth losing mass | 22:53 |
| ShadowJK | or maybe they're just dissolving it in the ether and steam cleaning | 22:53 |
| kerio | it's a massive conspiracy so you have to pay more for food | 22:54 |
| ShadowJK | And earth is losing mass because it's radiating away more energy due to global warming! | 22:55 |
| ShadowJK | (and lack of pirates) | 22:55 |
| kerio | DocScrutinizer05: hm, maybe you're right, 20mOhm for Rs is clearly a better value | 22:55 |
| kerio | >>> 29200 / 21. | 22:56 |
| kerio | 1390.4761904761904 | 22:56 |
| ShadowJK | I sometimes use 20, sometimes 21 :) | 22:56 |
| kerio | ShadowJK: that makes no sense, it should be sometimes 20 and sometimes 22, at least | 22:56 |
| ShadowJK | Probably, considering it's made up of two resistors, and it's probably not 2 * 10.5 | 22:57 |
| kerio | :D | 22:57 |
| ShadowJK | more likely is the tolerance of those 2 resistors sometimes adding up closer to 21 | 22:57 |
| kerio | but sometimes they're 11? i don't get it | 23:00 |
| * ShadowJK shrugs | 23:00 | |
| ShadowJK | it's only 5%! | 23:00 |
| *** Martix_ has joined #maemo-ssu | 23:02 | |
| DocScrutinizer05 | >>It is also clear that the mass of the IPK lost perhaps 50 µg over the last century, and possibly significantly more, in comparison to its official copies.<< | 23:03 |
| DocScrutinizer05 | http://en.wikipedia.org/wiki/Kilogram | 23:03 |
| kerio | is that 50µg in old grams or in new grams? | 23:04 |
| DocScrutinizer05 | >>The reason for this drift has eluded physicists who have dedicated their careers to the SI unit of mass. No plausible mechanism has been proposed to explain either a steady decrease in the mass of the IPK, or an increase in that of its replicas dispersed throughout the world<< | 23:04 |
| ShadowJK | I wonder if the earth gravity gradient maps change over time | 23:05 |
| ShadowJK | they've only recently started charting it, afaik | 23:05 |
| DocScrutinizer05 | one *possible* explanation, though that would apply only when the copies also would lose mass | 23:05 |
| ShadowJK | Well, the value of g being different in different places on earth does make a difference | 23:06 |
| DocScrutinizer05 | but it's only the IPK that loses mass, constantly | 23:06 |
| ShadowJK | Do the others all agree with eachother then? | 23:06 |
| DocScrutinizer05 | and it's the best guaded kg on the world | 23:06 |
| DocScrutinizer05 | see wiki | 23:07 |
| DocScrutinizer05 | they differ, but scientists clean them and have a model to explain why and how they differ | 23:07 |
| DocScrutinizer05 | but no model applies to what happens to IPK | 23:07 |
| ShadowJK | They're probably all losing mass | 23:08 |
| ShadowJK | looking at that graph | 23:08 |
| DocScrutinizer05 | :-/ >>This relative nature of the changes amongst the world's kilogram prototypes is often misreported in the popular press, and even some notable scientific magazines, which often state that the IPK simply "lost 50 µg" and omit the very important caveat of "in comparison to its official copies".[Note 15] Moreover, there are no technical means available to determine whether or not the entire worldwide ensemble of prototypes | 23:09 |
| DocScrutinizer05 | suffers from even greater long-term trends upwards or downwards because their mass "relative to an invariant of nature is unknown at a level below 1000 µg over a period of 100 or even 50 years".<< | 23:09 |
| ShadowJK | oh, they're all returned to the same place for comparing | 23:09 |
| ShadowJK | That throws out gravity gradient thing. | 23:10 |
| kerio | hm, why don't they buy a new scale | 23:10 |
| ShadowJK | lol | 23:10 |
| ShadowJK | because scales are calibrated against those things | 23:10 |
| kerio | one of those fancy digital ones! | 23:10 |
| ShadowJK | And it's the only source of calibration available | 23:10 |
| kerio | hold on, how do you think they were comparing them, then? | 23:10 |
| DocScrutinizer05 | anyway they recently built a silicone ball IPK iirc | 23:10 |
| DocScrutinizer05 | Si | 23:11 |
| DocScrutinizer05 | counted by the atom | 23:11 |
| ShadowJK | kerio, on a see-saw, pairwise | 23:12 |
| kerio | you have to be in the same place for that | 23:12 |
| ShadowJK | Yeah it says that at one point, that they're returned to the same place for measurement | 23:13 |
| ShadowJK | Because like, I imagine they would also be used to calibrate the strength of earth's gravity in a specific location too | 23:14 |
| DocScrutinizer05 | >...not dependent on the number of times the artifacts have been cleaned or possible changes in gravity or environment.<< | 23:14 |
| DocScrutinizer05 | every 50 years, they are shipping all copies to Paris, for comparison | 23:15 |
| ShadowJK | University of Helsinki has a super accurate gravity meter btw.. It can measure the gravity influence of a person entering the room where it is kept | 23:15 |
| ShadowJK | And it also can tell whether there's snow or not on the roof, and can tell when peopel are on the roof shoveling away snow or not, because the snow has mass which results in gravity pull upwards, which slightly negates earth's gravity :-) | 23:17 |
| kerio | i guess that measuring mass with the gravitational pull has the same problem of measuring charge with the coulomb force | 23:17 |
| ShadowJK | Nah | 23:17 |
| ShadowJK | You could try measure mass with force + acceleration too | 23:17 |
| ShadowJK | But it'd give you the same results | 23:18 |
| ShadowJK | If the weights are compared in the same place, at the same time, it rules out gravitational anomalies because the two pieces being compared will be subject to the same gravity throughout | 23:18 |
| DocScrutinizer05 | http://en.wikipedia.org/wiki/File:Silicon_sphere_for_Avogadro_project.jpg# | 23:21 |
| DocScrutinizer05 | http://en.wikipedia.org/wiki/File:Silicon_sphere_for_Avogadro_project.jpg | 23:21 |
| ShadowJK | This is like when you've cursed at crappy components and resistors, tuned everything out with trimpots everywhere, then get a new multimeter and curse again that everything is off | 23:22 |
| *** dhbiker has quit IRC | 23:22 | |
| *** Pali has quit IRC | 23:23 | |
| kerio | hahaha | 23:27 |
| DocScrutinizer05 | indeed | 23:29 |
| kerio | ok, so i have registers and flags in two dicts, with converted units | 23:29 |
| DocScrutinizer05 | actually a perfect geek topic ;-P | 23:29 |
| DocScrutinizer05 | kerio: eh? | 23:30 |
| kerio | DocScrutinizer05: http://pastebin.mozilla.org/2254813 | 23:30 |
| kerio | (it doesn't parse eeprom) | 23:31 |
| kerio | (because frankly, who cares) | 23:31 |
| DocScrutinizer05 | fsck eeprom | 23:31 |
| *** _rd has quit IRC | 23:32 | |
| kerio | fsck: eeprom: device or file not found | 23:32 |
| DocScrutinizer05 | I just added it to bq27k-detail for awesomeness | 23:32 |
| DocScrutinizer05 | since it never will change, it's irrelevant dor all practical purposes | 23:32 |
| DocScrutinizer05 | for* | 23:32 |
| kerio | ooh, i just realized that you can access the registers file as user | 23:33 |
| DocScrutinizer05 | kerio: looking at your pastebin I start to hate python and feel nausea ;-) | 23:34 |
| kerio | haters gonna hate | 23:34 |
| kerio | also, i kinda golfed | 23:34 |
| kerio | but look at how pretty it is! | 23:35 |
| DocScrutinizer05 | it's just I don't get it without reading a python tutorial | 23:35 |
| DocScrutinizer05 | I don't like languages I need a tutorial to understand them | 23:35 |
| kerio | heh | 23:35 |
| DocScrutinizer05 | (except assembler) | 23:36 |
| *** _rd has joined #maemo-ssu | 23:38 | |
| kerio | DocScrutinizer05: http://pastebin.mozilla.org/2254847 | 23:39 |
| kerio | i should probably put a comment explaining that i'm relying on the fact that registers has that odd address merging thing going on | 23:40 |
| kerio | and it's not an exact dump | 23:40 |
| *** LauRoman has joined #maemo-ssu | 23:40 | |
| ShadowJK | kerio, damn you for that youtube link, now I'm stuck browsing youtube the next 20 hours | 23:40 |
| kerio | ShadowJK: QI is awesome! :D | 23:41 |
| ShadowJK | kerio, actually I got lost from that | 23:41 |
| ShadowJK | now I'm at "old airplanes that sound like the millennium falcon from starwars" | 23:41 |
| ShadowJK | kinda | 23:41 |
| kerio | report back when you reach russian dashcams | 23:42 |
| DocScrutinizer05 | lol | 23:42 |
| ShadowJK | will do | 23:42 |
| DocScrutinizer05 | kerio: is that your version for the leete coder's contest? | 23:42 |
| * DocScrutinizer05 starts to like python again | 23:43 | |
| *** Pali has joined #maemo-ssu | 23:43 | |
| kerio | the second one is in joergian python :P | 23:43 |
| DocScrutinizer05 | hehe | 23:43 |
| kerio | i guess that both zip() and enumerate() can be understood from the context | 23:43 |
| DocScrutinizer05 | if you'd see *my* python you'd start to vomit | 23:44 |
| DocScrutinizer05 | it's utterly try&error | 23:44 |
| kerio | hehe | 23:44 |
| DocScrutinizer05 | I think there's actually a small silly snippet publicly available somewhere on maemo.cloud-7.de | 23:45 |
| DocScrutinizer05 | I only patched a few lines in that one though | 23:45 |
| DocScrutinizer05 | which took me an hour | 23:45 |
| DocScrutinizer05 | since print() in python is kinda mindboggling | 23:46 |
| kerio | which python? | 23:46 |
| DocScrutinizer05 | errrr, 2.5? | 23:46 |
| kerio | because if it's not python3, and you haven't imported print_function from __future__, then it's not print() | 23:46 |
| kerio | it's print | 23:46 |
| DocScrutinizer05 | yeah | 23:46 |
| DocScrutinizer05 | whatever | 23:46 |
| DocScrutinizer05 | I wasn't able to print more than one var at a time | 23:46 |
| kerio | and yeah, print as a statement is one of the things that were clearly a mistake, but couldn't be changed for obvious reasons | 23:47 |
| kerio | until python3 came along, with the breakage of backwards compatibility :D | 23:47 |
| kerio | even with print as a function, i still tend to write just one formatted string anyway | 23:47 |
| DocScrutinizer05 | I tried for 45min to figure how to do sth like pintf("a: %d, b:%d", a, b) | 23:48 |
| kerio | python tutorial, string formatting :) | 23:48 |
| DocScrutinizer05 | and I gave up | 23:48 |
| kerio | "a: %d, b: %d" % (a, b) | 23:48 |
| kerio | and then you have a string, and you print it, or whatever | 23:48 |
| DocScrutinizer05 | ooooh, a pair of braces | 23:48 |
| DocScrutinizer05 | fuuuuuck | 23:49 |
| kerio | hahaha | 23:49 |
| kerio | not braces, parentheses | 23:49 |
| * DocScrutinizer05 starts hating python again | 23:49 | |
| kerio | :( | 23:49 |
| kerio | string formatting is done *on the string* | 23:49 |
| kerio | why should it be a printing thing? | 23:49 |
| DocScrutinizer05 | sure | 23:50 |
| DocScrutinizer05 | makes sense, once you come to think of it that way | 23:50 |
| kerio | anyway, you understood how it worked immediately, once read | 23:50 |
| DocScrutinizer05 | a string is an object with methods like everything else | 23:50 |
| DocScrutinizer05 | http://maemo.cloud-7.de/maemo5/usr/local/bin/smscb.py | 23:52 |
| kerio | OH GOD WHY | 23:52 |
| kerio | i'm surprised it even parses correctly | 23:52 |
| kerio | at first i thought you were using tabs | 23:54 |
| kerio | this is possibly even worse | 23:54 |
| DocScrutinizer05 | print '%s New cell broadcast message received from channel' % time.asctime(), fromchannel | 23:54 |
| DocScrutinizer05 | print 'Message: %s' % msg | 23:54 |
| DocScrutinizer05 | those two lines drove me nuts | 23:54 |
| kerio | hahaha | 23:54 |
| DocScrutinizer05 | since I intended to make them one print statement | 23:54 |
| DocScrutinizer05 | and since I didn't know about the parentheses... | 23:56 |
| DocScrutinizer05 | ...I started headdesking after ~40min | 23:56 |
| DocScrutinizer05 | NB >90% of the code are "stolen" from phonecontrol | 23:58 |
| DocScrutinizer05 | so don't blame me for poor style | 23:58 |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!
