| 00:09.55 | FalconSpy | Well as soon as the graphical interface loads it shutsdown if not connected to power |
| 00:10.09 | FalconSpy | It just doesn't read thed actual batteries legitimate charge |
| 00:11.19 | *** join/#maemo mavhc (~mavhc@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) |
| 00:12.52 | ShadowJK | Alright, that does sound like a problem with the OS not recognizing the charge level of the battery properly. |
| 00:13.50 | FalconSpy | Im toying with the power manager but might just try a different one |
| 00:45.55 | *** join/#maemo at1as (~at1as@172.56.40.1) |
| 00:59.40 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 01:04.47 | DocScrutinizer05 | this is bullshit anyway, shutdown *allways* by voltage, not estimated available charge |
| 01:05.52 | DocScrutinizer05 | power manager?? |
| 01:12.23 | DocScrutinizer05 | oooh THAT power manager. Yes it's designed for laptops with decent accurate battery capacity gauge. For N900 you must not use the estimated available capacity for system shutdown, it's not reliable enough |
| 01:13.50 | DocScrutinizer05 | FalconSpy: ^^^ |
| 01:16.47 | FalconSpy | DocScrutinizer05 so what do I use to deal with battery management |
| 01:17.05 | FalconSpy | I was using the built in Kali xfce4-power-manager |
| 01:17.16 | FalconSpy | I'm seeing things like gapcmon (apcupsd) |
| 01:18.56 | DocScrutinizer05 | no idea |
| 01:19.09 | DocScrutinizer05 | never looked into kali linux |
| 01:19.53 | FalconSpy | doesnt have to be kali specific |
| 01:19.53 | DocScrutinizer05 | first of all try to change percentage level for shutdown from 10% or whatever to 0% |
| 01:20.35 | DocScrutinizer05 | please rephrase your question |
| 01:21.01 | *** join/#maemo LauRoman|Alt (~LauRoman@5-14-55-34.residential.rdsnet.ro) |
| 01:22.02 | DocScrutinizer05 | battery management is done by kernel (and mainly by hardware) via bq24150 module |
| 01:22.21 | DocScrutinizer05 | so you don't do anything about it |
| 01:22.43 | FalconSpy | My question I guess is how can I get the battery manager to show an accurate charge |
| 01:23.42 | DocScrutinizer05 | ~bq27k-detail |
| 01:23.42 | infobot | i heard bq27k-detail is http://maemo.cloud-7.de/maemo5/usr/local/sbin/bq27k-detail2, or ~bq27 |
| 01:24.31 | DocScrutinizer05 | ~listvalues calibrate |
| 01:24.45 | DocScrutinizer05 | ~calibratebq27200 |
| 01:24.45 | infobot | well, calibratebq27200 is http://acehack.de/~kerio/calibratebq27200 |
| 01:24.54 | DocScrutinizer05 | FUH! |
| 01:25.01 | FalconSpy | ^ dead link |
| 01:25.08 | DocScrutinizer05 | thank god |
| 01:25.29 | DocScrutinizer05 | ~listvalues calibrate |
| 01:25.38 | DocScrutinizer05 | ~calibrate |
| 01:25.44 | DocScrutinizer05 | damn! |
| 01:25.54 | DocScrutinizer05 | ~bq-calibrate |
| 01:25.54 | infobot | bq-calibrate is, like, http://maemo.cloud-7.de/maemo5/patches_n_tools/calibrate-bq27k.sh, or http://talk.maemo.org/showthread.php?p=1247595 |
| 01:26.33 | DocScrutinizer05 | ~forget calibratebq27200 |
| 01:26.33 | infobot | DocScrutinizer05: i forgot calibratebq27200 |
| 01:27.50 | DocScrutinizer05 | note that calibrate-bq27k.sh only works via I2V with bq27200.sj in same dir |
| 01:28.40 | DocScrutinizer05 | and won't work with kernel module taking care about batery management, since that needs other methods to stop charging |
| 01:30.44 | DocScrutinizer05 | you *might* get away with replacing my "stop vme" by a "modprobe -r bq24150" or whatever the name, see lsmod. And "start bme" by a "modprobe bq24150" |
| 01:31.02 | DocScrutinizer05 | s/vme/bme/ |
| 01:31.27 | FalconSpy | http://http//maemo.org/packages/view/i2c-tools/ is a dead link |
| 01:31.41 | DocScrutinizer05 | o.O |
| 01:31.43 | FalconSpy | or should this be ran inside maemo? |
| 01:32.00 | FalconSpy | cause kali can't find i2c tools or any of those tools |
| 01:32.19 | DocScrutinizer05 | no, should be an installable package from err tools or maemo.extras(-devel) |
| 01:32.39 | FalconSpy | Maemo's battery manager works fine |
| 01:32.44 | FalconSpy | Its the Kali one that's having issues |
| 01:32.50 | DocScrutinizer05 | so? |
| 01:33.08 | FalconSpy | So is what you gave me going to help resolve the Kali one? |
| 01:33.09 | DocScrutinizer05 | sorry I won't provide a calibration script for kali linux |
| 01:33.25 | FalconSpy | no worries |
| 01:33.35 | DocScrutinizer05 | you will either have to adapt it by yourself, or run calibration under maemo |
| 01:35.10 | DocScrutinizer05 | generally the whole tricj is to fully charge the battery, then discharge it until EVF voltage (some 3.24V iirc) |
| 01:35.53 | DocScrutinizer05 | redo until total capacity (LMD) doesn't change anymore |
| 01:38.41 | DocScrutinizer05 | there's also possibly still a bug in nq27xx.ko kernel module. It _never_ should report a calculated value for "design capacity", this is a constant that should be 1340mAh |
| 01:38.58 | DocScrutinizer05 | bq27xx.ko |
| 01:40.08 | DocScrutinizer05 | generally your power manager must not check available capacity from bq27xx but VOLTAGE for deciding when to shut down |
| 01:40.57 | DocScrutinizer05 | so probably best is to not run such power manager at all |
| 01:43.21 | DocScrutinizer05 | the kernel itself will do a brute force shutdown (though with trying to correctly flush and umount storage) when battery err system voltage reaches shutdown limit which iirc is 3.0V for OMAP/TWL4030 |
| 01:46.03 | DocScrutinizer05 | it *might* be possible that bq24150.ko or bq27xx.ko also take care about shutdown, I don't know for sure |
| 01:46.39 | DocScrutinizer05 | if that's the case, try modprobe -r bq27xx |
| 01:46.55 | DocScrutinizer05 | get a fixed module |
| 01:48.32 | DocScrutinizer05 | you might want to provide `modibfo bq27xx.sh` and ask Pali about details of operation of that module |
| 01:48.42 | DocScrutinizer05 | modinfo* |
| 01:49.26 | DocScrutinizer05 | it *should* not mess with system shutdown on its own, I guess |
| 01:50.35 | DocScrutinizer05 | s/EVF/EDV0/ |
| 01:52.27 | DocScrutinizer05 | nfc where from you got that garbled link, this works: http://maemo.org/packages/view/i2c-tools/ |
| 01:53.48 | DocScrutinizer05 | hint: should also run under arbitrary other linux systems on N900 |
| 01:54.43 | DocScrutinizer05 | get http://repository.maemo.org/extras-testing/pool/fremantle/free/i/i2c-tools/i2c-tools_3.0.2-1maemo3_armel.deb and install locally on your kali linux |
| 01:55.22 | DocScrutinizer05 | FalconSpy: ^^^ |
| 01:55.55 | DocScrutinizer05 | my scripts should be mostly OS-afnostic anyway |
| 01:56.37 | DocScrutinizer05 | credits where credit due: bq27200.sh is by ShadowJK |
| 01:59.08 | FalconSpy | so if i run your calibration through maemo it should hopefully show the correct charge % in kali? |
| 01:59.20 | FalconSpy | Your tool won't work since it is looking for armhf |
| 02:01.59 | DocScrutinizer05 | yes |
| 02:03.16 | DocScrutinizer05 | there's a CI (capacity incorrect) bit in that bat gauge chip that gets reset by calibration. I guess that's first culprit for your problems (after power manager doing the fundamentally wrong thing, to start with) |
| 02:04.05 | DocScrutinizer05 | my tool looks for armhf? nope |
| 02:04.11 | DocScrutinizer05 | i2ctools might |
| 02:04.44 | FalconSpy | https://pastebin.com/cN7N6TZ5 is the upower dump |
| 02:05.18 | DocScrutinizer05 | no idea, what's that? |
| 02:05.47 | FalconSpy | Tool that gives I guess the information about all sources of power |
| 02:06.01 | DocScrutinizer05 | obviously it's defect then |
| 02:06.15 | DocScrutinizer05 | I can't help fix defect kali linux tools |
| 02:10.50 | DocScrutinizer05 | and please find a better pastebin, this one doesn't allow zooming the way too small text font |
| 02:15.39 | *** join/#maemo at1as (~at1as@wsip-24-120-54-4.lv.lv.cox.net) |
| 02:16.45 | DocScrutinizer05 | anyway that stuff is non-coherent: /org/freedesktop/UPower/devices/battery_bq27200_0 tells a bogus "energy-full: 7.91478 Wh" (should be 3.x Wh) and "capacity: 100%" (full) at "voltage: 3.788 V" which isn't bad but for sure not full |
| 02:18.40 | DocScrutinizer05 | "state: discharging" while /org/freedesktop/UPower/devices/battery_bq24150a_0 says "state: charging" -- not even the most braindead power manager should shut down device when it's charging |
| 02:21.18 | DocScrutinizer05 | /org/freedesktop/UPower/devices/line_power_isp1704 says "online: no" so not charging |
| 02:21.38 | DocScrutinizer05 | and /org/freedesktop/UPower/devices/battery_rx51_battery is pretty much completely confused |
| 02:23.00 | DocScrutinizer05 | also I'd think /org/freedesktop/UPower/devices/battery_rx51_battery would be mutually exclusive with /org/freedesktop/UPower/devices/battery_bq27200_0 in a few aspects, they both use same source of info, or at least should. For sure they report about same battery |
| 02:24.47 | DocScrutinizer05 | that stuff evidently is pretty much messed up in kali linux, sorry |
| 02:42.00 | *** join/#maemo at1as (~at1as@wsip-24-120-54-4.lv.lv.cox.net) |
| 02:46.34 | *** join/#maemo at1as (~at1as@wsip-24-120-54-4.lv.lv.cox.net) |
| 02:54.33 | *** join/#maemo at1as (~at1as@wsip-24-120-54-4.lv.lv.cox.net) |
| 02:57.24 | *** join/#maemo Natch (~Natch@h-155-122.A444.priv.bahnhof.se) |
| 05:03.06 | *** join/#maemo Wizzup_ (~Wizzup@a82-161-36-93.adsl.xs4all.nl) |
| 05:23.02 | *** join/#maemo juiceme (~juice@cerebro.liukuma.net) |
| 05:24.27 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 07:10.31 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 07:42.30 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 09:36.55 | *** join/#maemo mp107 (~mp107___@PC-109-125-232-42.wegrow.domtel.com.pl) |
| 10:01.43 | ShadowJK | Default maemo doesn't use the hardware battery fuel gauge chip really... That's why it works in stock maemo. |
| 10:02.02 | bencoh | ? |
| 10:02.18 | bencoh | you mean it doesn't use the capacity reported by gasgauge |
| 10:02.47 | ShadowJK | AFter getting the hardware chip (bq27200) calibrated, it should provide reasonable data to other operating systems as well.. However, that it says 0 is quite peculiar, usually what happens is that you get over-estimation of capacity :) |
| 10:02.52 | ShadowJK | yes I mean that |
| 10:03.04 | ShadowJK | But maybe the kernel modules and such just report 0 for "unknown" |
| 10:12.02 | *** join/#maemo shentey (~shentey@x4e34e600.dyn.telefonica.de) |
| 10:20.48 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 10:29.06 | *** join/#maemo rysiek|pl (~quassel@static.51.54.9.176.clients.your-server.de) |
| 10:31.27 | *** join/#maemo NotKit (~nekit@178.45.158.164) |
| 10:33.50 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 10:56.56 | *** join/#maemo shentey (~shentey@x4e34e600.dyn.telefonica.de) |
| 11:56.30 | *** join/#maemo Pali (~pali@Maemo/community/contributor/Pali) |
| 12:07.58 | *** join/#maemo shentey (~shentey@x4e34e600.dyn.telefonica.de) |
| 12:30.28 | *** join/#maemo Vajb (~Vajb@85-76-73-111-nat.elisa-mobile.fi) |
| 13:10.54 | *** join/#maemo LjL (~ljl@unaffiliated/ljl) |
| 14:04.55 | *** join/#maemo at1as (~at1as@ip70-189-208-35.lv.lv.cox.net) |
| 14:19.40 | *** join/#maemo err0r3o3 (~err0r3o3@213-240-109-9.adsl.highway.telekom.at) |
| 14:54.52 | *** join/#maemo xorly (~xorly@ip-86-49-24-93.net.upcbroadband.cz) |
| 14:57.24 | *** join/#maemo xes (~xes@unaffiliated/xes) |
| 15:02.51 | *** join/#maemo err0r3o3_ (~err0r3o3@212-197-142-43.adsl.highway.telekom.at) |
| 15:49.22 | *** join/#maemo mavhc (~mavhc@cpc77319-basf12-2-0-cust433.12-3.cable.virginm.net) |
| 16:38.22 | Pali | DocScrutinizer05: fm transmitter in n900 is doing something nasty, once I start it and it transmit some periodic beep |
| 16:38.36 | Pali | it can be detected only when n900 does not play any sound/music |
| 16:38.46 | KotCzarny | pali: it does it until you start playing something |
| 16:39.02 | KotCzarny | i guess for making detecting n900 easier |
| 16:39.39 | Pali | really? I think I can detect that beep also when n900 play some music... |
| 16:39.51 | KotCzarny | what about when you play silence? |
| 16:39.52 | Pali | I will look into rtl-sdr dump what it is |
| 16:39.54 | KotCzarny | or close to silence? |
| 16:40.15 | KotCzarny | i think it stops then |
| 16:48.29 | sicelo | i also thought the beeps were 'correct.' i don't recall hearing them during active transmission (and i used it today) |
| 16:49.48 | sicelo | https://talk.maemo.org/archive/index.php/t-42766.html |
| 16:51.16 | KotCzarny | nice, i didnt know those beeps are configurable |
| 16:52.00 | Pali | looks like, yes beeps disappear when playing something |
| 16:53.50 | Pali | and there is something else with transmitter, it changes frequency in time by 2.8kHz offset |
| 16:54.38 | bencoh | strange |
| 16:54.41 | KotCzarny | maybe that's that deviation param? |
| 16:56.18 | Pali | when I set to transmit at 105.8MHz then I see it in 105,8047MHz and frequency starts changing until it is 105,8016MHz |
| 16:57.16 | Pali | and after some time it changes back to 105,804... and I see in time graph that base frequency is really changing... |
| 16:57.49 | KotCzarny | some spreadspectrum algo? or just bad design somewhere? |
| 16:57.56 | Pali | and I'm not able to see this problem in other FM transmitters, so it is for sure problem in n900 transmitter and not in my receiver |
| 16:59.43 | sixwheeledbeast^ | I believe the beep is an intentional feature, after a while of beeping the fm transmitter is switched off. Like a standby mode. |
| 17:00.28 | Pali | see: https://imgur.com/a/eY5uq |
| 17:01.14 | KotCzarny | it's not vertical line |
| 17:01.36 | Pali | yes |
| 17:02.36 | Pali | maybe n900 fm transmitter is not able to fix fm frequency?? |
| 17:03.05 | KotCzarny | "good enough technology [tm]" ;) |
| 17:04.27 | sixwheeledbeast^ | hmm, is that reproducible on multiple devices I wonder? |
| 17:04.49 | sixwheeledbeast^ | What time period is that over? |
| 17:05.28 | Pali | that yellow dots are beeps |
| 17:05.52 | Pali | in the middle should be mono part of sound |
| 17:10.17 | sixwheeledbeast^ | oh I see |
| 17:46.28 | DocScrutinizer05 | sicelo: why the unbearable archive instead of https://talk.maemo.org/showthread?t=42766 |
| 17:48.13 | DocScrutinizer05 | Pali: FM channels are 50kHu wide in Germany, maybe 25kHz in USA (not sure). Anyway a 2.x kHz drift is irrelevant |
| 17:48.56 | DocScrutinizer05 | or was it 100kHz in EU, 50kHz in USA? |
| 17:49.29 | Pali | seems that gnuradio and rtl_fm do not have a problem with 2kHz drift... |
| 17:49.31 | Pali | but it is normal? |
| 17:50.21 | DocScrutinizer05 | 1kHz drift in 100MHz is 0.01 promille, not even TCOs can do that good |
| 17:50.51 | Pali | that picture of signal looks strange... it is not vertical line, nor continuous |
| 17:52.24 | DocScrutinizer05 | non-issue |
| 17:52.48 | DocScrutinizer05 | read the datasheet of FM-TX |
| 17:55.34 | DocScrutinizer05 | I'm not sure which timebase/oscillator the chip uses, but for sure it's no specially temperature compensated oscillator, so drifts are expected |
| 17:56.07 | DocScrutinizer05 | particularly when your N900 warms up during usage |
| 17:57.35 | Pali | ok |
| 17:58.58 | Pali | anyway, it is possible to use ordinary telescopic antenna for receiving CB? |
| 18:01.42 | DocScrutinizer05 | sure |
| 18:01.51 | DocScrutinizer05 | every walkietalkie does |
| 18:02.53 | DocScrutinizer05 | but you can't use RTL dongle plus antemma stb, it starts at 5ÃMHz iirc |
| 18:03.04 | DocScrutinizer05 | 50MHz |
| 18:03.27 | DocScrutinizer05 | CB is 27MHz |
| 18:04.16 | DocScrutinizer05 | so you want an antenna of at least 1m length, and elctrical inductive compensation |
| 18:21.46 | Pali | rtl-sdr with R820T has range 24 â 1766 MHz with experimental 500 kHz â 28.8 MHz and up to 1864 MHz |
| 18:26.39 | *** join/#maemo deep-book-gk_ (~1wm_su@119.81.29.178) |
| 18:28.12 | *** part/#maemo deep-book-gk_ (~1wm_su@119.81.29.178) |
| 18:36.01 | DocScrutinizer05 | wow |
| 18:37.05 | DocScrutinizer05 | 500k - 28.8M is mere I/Q direct sampling, the results are questionable particularly for sensitivity |
| 18:37.18 | DocScrutinizer05 | afaik |
| 18:38.39 | DocScrutinizer05 | but for tests you can get away with it for sure, I.E. when the distance from your TX to RTL antenna are less than 1M |
| 18:38.42 | DocScrutinizer05 | 1m* |
| 18:40.12 | DocScrutinizer05 | generally sensitivity of rtl is a problem |
| 18:42.03 | DocScrutinizer05 | then you also have poor mirror frequency suppression, and also problems with aliasing |
| 18:42.37 | DocScrutinizer05 | input signal filtering in RTL is basically non-existent |
| 18:43.20 | xes | ..antenna connector, clock drift, temperature.. |
| 18:43.59 | DocScrutinizer05 | yeah, well it costs like 10 bucks, what do you expect? |
| 18:45.16 | xes | in fact, noelec version fixes many of the problems |
| 18:54.44 | *** join/#maemo MetalGearSolid (~MetalGear@unaffiliated/metalgearsolid) |
| 19:05.13 | *** join/#maemo pagurus (~user@p4FDC3E7D.dip0.t-ipconnect.de) |
| 19:05.40 | *** join/#maemo xy2_ (~xy2_@94.239.177.175) |
| 19:09.49 | DocScrutinizer05 | ok, I stand corrected. http://www.rtl-sdr.com/wp-content/uploads/2013/04/R820T_datasheet-Non_R-20111130_unlocked1.pdf says it gas input filter with image rejection of 65dBc |
| 19:09.55 | DocScrutinizer05 | has* |
| 19:14.13 | DocScrutinizer05 | so >>input signal filtering in RTL is basically non-existent<< is an incorrect statement |
| 20:08.36 | DocScrutinizer05 | LOL! Opensuse bash does autocompletion from "scp x1 neo900:/ho" to "scp x1 neo900:/home/" and then on to the actually existing user homedirs - heck this does indeed use stealth remote login to destination to autocomplete |
| 20:13.34 | Pali | ubuntu is doing same for a longer time |
| 20:14.03 | Pali | it is great when user has configured ssh-agent in -c mode :D |
| 20:14.43 | Pali | every tab autocompletion is subject to manual confirmation of usage of ssh key... |
| 20:24.13 | DocScrutinizer05 | LOL |
| 20:24.40 | DocScrutinizer05 | may I quote you? |
| 20:46.26 | *** join/#maemo florian (~fuchs@Maemo/community/contributor/florian) |
| 20:47.07 | DocScrutinizer05 | less +'/_scp_remote_files()' /usr/share/bash-completion/completions/scp |
| 20:55.19 | *** join/#maemo dafox (~dafox@2a02:a448:c25a:1:7061:3b2a:37df:ded3) |
| 20:55.44 | DocScrutinizer05 | I guess the lines like "files=$( ssh -o 'Batchmode yes' $userhost ..." could use some watchdog to catch ssh locking up during log in |
| 20:56.04 | DocScrutinizer05 | seen this more than once |
| 20:56.37 | *** join/#maemo deep-book-gk_ (~1wm_su@158.85.67.146) |
| 20:59.05 | *** part/#maemo deep-book-gk_ (~1wm_su@158.85.67.146) |
| 23:11.13 | *** join/#maemo ced117 (~ced117@ghost.ced117.net) |
| 23:11.13 | *** join/#maemo ced117 (~ced117@opensuse/member/ced117) |
| 23:38.13 | *** join/#maemo vahe[m] (vahediaspi@gateway/shell/matrix.org/x-xaphzdavdgxdxppu) |
| 23:41.15 | *** join/#maemo ollieparanoid[m] (ollieparan@gateway/shell/matrix.org/x-egifpmswqqqvnrak) |
| 23:41.15 | *** join/#maemo chfoo[m] (chfoomatri@gateway/shell/matrix.org/x-bhwhrryaspopbkqy) |
| 23:41.22 | *** join/#maemo MartijnBraam (martijnbra@gateway/shell/matrix.org/x-payzqpxwmihuwdpo) |