Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Battery Sensor issues #7

Open
nleo575 opened this issue Oct 30, 2019 · 3 comments
Open

Battery Sensor issues #7

nleo575 opened this issue Oct 30, 2019 · 3 comments
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@nleo575
Copy link

nleo575 commented Oct 30, 2019

During analysis of the battery sensor data we have noticed the following:

(a) The sensor records data at a fixed rate of ~1 minute. This should be moved to an event based recording (as the Android version does) instead to reduce resource usage and storage requirements.

(b) Status codes are not the same as with Android. These could be changed programmatically so that they match (e.g. 4 would be recoded as 3 to match the Android one, the rest would not need to be changed since 2 = charing on both and 5 = full on both).

(c) Data in the battery_charges and battery_discharges tables isn't accurate in certain situations. We have identified some events that would cause the sensor to record an incorrect battery_end and double_end_timestamp and thus give an inaccurate entry in the respective tables:

  1. The device enters low power mode. When the device exists low power mode (presumably because the phone was charged to > 80%) it still considers this the same charge/discharge period. This is especially problematic because the battery_start could be less than the battery_end for a discharge cycle and vice versa for a charge cycle. The elapsed time could also be off by a lot. These should considered two distinct periods.

  2. The app crashes or is force closed by the user and the user restarts it some time later. The time before the app stopped should be considered the end of the last charging/discharging period and a new period should be started from the time that the app restarted. Like entering low power mode, we have no idea what the phone did while the app wasn't running.

  3. The user or OS shuts down/restarts the phone. The next time the app starts should be the beginning of a new charge or discharge period and the most recent recording should be the end of the last period.

Basically we want to avoid an incorrect delta battery level or an incorrect delta time.

@tetujin tetujin transferred this issue from tetujin/aware-client-ios-v2 Mar 14, 2020
@tetujin
Copy link
Owner

tetujin commented Mar 14, 2020

I transferred this issue to AWARE-library repository from AWARE-UI repository, because this is a bug in the AWARE-library.

@tetujin tetujin added bug Something isn't working good first issue Good for newcomers labels Mar 14, 2020
@tetujin
Copy link
Owner

tetujin commented Mar 14, 2020

(a) is fixed in the latest version of library.

@tetujin
Copy link
Owner

tetujin commented Mar 14, 2020

About (b), I'm thinking to create a special database table for iOS battery sensor like iOS Activity Recognition Sensor because the battery events are a bit different between iOS and Android. I think we should save data as raw as possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants