[TESTING] SCBS: Improved battery meter system

[jonpry]

The code for scbs is here scbs in scbs - Gitorious

There is just a stupid build script for making it under ubuntu assuming you already have meschach installed. I'm sure it could be built for win32, but I haven't tried. I have a feeling the code could be made several times faster by removing meschach. At least it would be several times faster on x86, on arm novfp its not clear how much time is wasted with memory allocation because the math is just oh so slow anyways.

I have limited data on the consistency of the numbers. From my own experience, the numbers i get all "work", ie my battery meter is always accurate enough that I cannot prove it to be wrong. But there is a great deal of variation in them. Say +/- 25%. That may seem like a lot but its really only -6dB of noise.

It would be nice to get them more consistent, and i have some ideas on how to do it. But none of it is easy, and I wonder what the purpose of getting battery readings accurate to 6 decimal places really is.

[manekineko]

Originally Posted by jonpry

The code for scbs is here scbs in scbs - Gitorious

I have limited data on the consistency of the numbers. From my own experience, the numbers i get all "work", ie my battery meter is always accurate enough that I cannot prove it to be wrong. But there is a great deal of variation in them. Say +/- 25%. That may seem like a lot but its really only -6dB of noise.

It would be nice to get them more consistent, and i have some ideas on how to do it. But none of it is easy, and I wonder what the purpose of getting battery readings accurate to 6 decimal places really is.

Cool, is there any explanation anywhere on what each of these numbers means? So +/- 25% is still within a few percentage points on the battery meter?

Unrelatedly, just got hit be the connected-to-charger-battery-suddenly-drained-out bug. I'd really been hoping that one would have gotten taken care of by having more accurate readings on the battery meter. Battery drained down to nothing over the course of 4000 ticks of the log, all while it was connected to the charger, and had been connected for like 15000 ticks. Not sure if it's helpful for anybody, but on the off chance it is, I attached my scbs log.

[arrrghhh]

Originally Posted by manekineko

Unrelatedly, just got hit be the connected-to-charger-battery-suddenly-drained-out bug. I'd really been hoping that one would have gotten taken care of by having more accurate readings on the battery meter. Battery drained down to nothing over the course of 4000 ticks of the log, all while it was connected to the charger, and had been connected for like 15000 ticks. Not sure if it's helpful for anybody, but on the off chance it is, I attached my scbs log.

I've heard this happening to people on WinMo - I've had it literally happen once - you seem to get it much more frequently - for that reason, I think this is a hardware issue, not a software issue.

[manekineko]

Originally Posted by arrrghhh

I've heard this happening to people on WinMo - I've had it literally happen once - you seem to get it much more frequently - for that reason, I think this is a hardware issue, not a software issue.

Interesting, didn't know it happened on WinMo.

Yeah, I do seem to get hit by this annoyingly often, maybe once every month or two.

It is solved by a reboot, though, which makes it seem like it might be a software issue, but at the very least seems to suggest it can be solved by software.

[jonpry]

Manekineko,

Somewhere in this thread there is an explanation of the parameters. What scbs.conf were you using when this discharge happened? Do you know of the battery really did discharge or is it possible the readings were wrong?

[manekineko]

Originally Posted by jonpry

Manekineko,

Somewhere in this thread there is an explanation of the parameters. What scbs.conf were you using when this discharge happened? Do you know of the battery really did discharge or is it possible the readings were wrong?

scbs conf was using the values I posted here:
http://forum.ppcgeeks.com/android-tp...ml#post2087146

Battery really did discharge, when I turned it off, the light was orange indicating charging rather than green indicating charged, and when I rebooted into WinMo battery percentage was consistent with Android, indicating something like 2% charge remaining.

Found the explanation you referenced, in case anyone else was wondering:
http://forum.ppcgeeks.com/android-tp...ml#post2085359

[manekineko]

Yikes, got hit by the bug again, only this time I didn't catch it in time and it drained the battery flat to the point it couldn't boot or charge normally anymore.

Twice in two days is a lot even for me, hopefully it's a coincidence to when I started to use the improved battery meter.

[toadlife]

Originally Posted by arrrghhh

What I'm wondering is how to stop it? Does it just perpetually take logs?

By default, it logs to /sdcard/scbs.log, but you can effectively disable logging by making it log to /dev/null

e.g. `scbs -d -co /sdcard/scbs.conf -lf /dev/null`

Here are the command line options...

 # scbs --help
scbs --help
Warning: Failed to open config file /etc/scbs.conf
Super cool battery software, version: 0.04.a

Usage: scbs [OPTIONS]
Start battery daemon or perform maintance functions on data files.

Mandatory arguments for long options are mandatory for short options too.
  -h, --help                display this help and exit
  -v, --version             display scbh version number
  -pn                       print nan warnings to console
  -df PATH                  use device file def:(/dev/scbs0)
  -lf PATH                  use file for logging def:(/sdcard/scbs.log)
  -co PATH                  use file for initial config def:(/etc/scbs.conf)
  -d                        start sbcs in daemon mode
  -s INT                    set the sleep mode data interval def:(5000)
  -w INT                    set the wake mode data interval def:(5000)
  -cf REAL                  set the charge scale factor def:(0.312500000)
  -vf REAL                  set the voltage scale factor def:(1.098000000)
  -se REAL                  set the sleep error constant def:(0.007000000)
  -ln PATH                  open data file and use it to compute linearization
  -n PATH                   open data file and use it to compute Rc,Cc,Re,Cb
  -nr REAL                  set nls learning rate def:(0.000010000)
  -wf                       write the computed battery model out to the config file
  -l PATH                   open data file and generate stream of Cb estimates
  -lr REAL                  set luenberger learning rate def:(0.000001000)
  -rc REAL                  set Rc value def:(0.028796000)
  -re REAL                  set Re value def:(0.130299000)
  -cc REAL                  set Cc value def:(2.064020000)
  -cb REAL                  set Cb value def:(64.219460000)
  -sl REAL                  set Cb slope value def:(0.000000000)

[ndno]

Originally Posted by toadlife

By default, it logs to /sdcard/scbs.log, but you can effectively disable logging by making it log to /dev/null

e.g. `scbs -d -co /sdcard/scbs.conf -lf /dev/null`

Here are the command line options...

Thanks for the syntax. I think I'm happy with my model now so I'm going to disable logging by redirectly to /dev/null. That should lighten up the writes to the SD card constantly.

[toadlife]

jonpry,

I'm having a strange issue with scbs and was wondering if you could shed some light on why this was happening.

I've integrated scbs into F22's latest rootfs and in /init I've integrated the following code, which starts debug logging and scbs

    logfiledate=`date +%Y%m%d%H%M%S`
    cat /proc/kmsg>"$card"/debuglogs_kmsg_"$logfiledate".txt &    
    logcat -v time >"$card"/debuglogs_logcat_time_"$logfiledate".txt &
    logcat -v time -b radio>"$card"/debuglogs_logcat_time_radio_"$logfiledate".txt &


    dev=$(cat /sys/class/scbs/0/dev | sed -e "s/:/ /g")
    mknod /dev/scbs0 c $dev


    scbs -d -co /sdcard/scbs.conf

The problem I am having is that, if I enable scbs, it causes both instances of logcat to crash with the errors 'unable to access /dev/log/main' and 'unable to access /dev/log/radio'.

I tried starting scbs before the logging and after, and it makes no difference. I also tried some other things like having the script sleep for 5 seconds but the result is always the same. If I start scbs via gscript logcat does not blow up, so it seems like it might have to do with them being fired of in the same tty.