Inaccurate sleep/wake recognition
I'm not sure if Gadgetbridge processes raw data from Mi Band or just simply fetches it, but Mi Band doesn't recognise wakeup properly, it shows that my activity is 'light sleep' not 'activity'. There are sporadic short 'activity' graphs among sleep graphs, but no sign of fully 'waking up'. This inaccurate sleep detection is resulted in much longer sleep hour, such as 12 hours of sleep instead of 8 hours of actual sleep.
Or maybe it's because my Mi Band is broken. Any ideas?
@official-jkim we merely collect the raw data (minute samples) from the device and put them on the graphs.
We started collecting ideas / algorithms for interpreting the data in the following wiki page:
Any further ideas and contribution is much welcome.
See also #135 and other issues...
All of these devices are not particularly accurate for measurements of sleep. One big issue with them is the manufactures mostly implicitly over sell their accuracy. (heck rigorous checks of the pedometer functions also do not pan out well either. ) I added one reference to the wiki page above. Gadgetbridge documentation should in my opinion have some explanation of this.
I can happily provide more details on how raw* data is coming from the different devices (original miband and pebble health). That would be a description of how things are, not an explanation on how activity tracking works.
Thanks for contributing to our wiki! Do you think that what I proposed above could help you giving the explanation you have in mind?
*We usually refer to this as "raw" data but in fact they are already manipulated on the devices. For both miband and pebble we get per-minute aggregated data, for instance.
I think my Mi Band is broken, as you said even Mi Band's raw data is manipulated on the device. Now it doesn't recognise 'wakeup' at all, recognises any activity as 'sleep' constantly. After even most intensive shake action and highest activity value, Mi Band recognises it as very short 'activity' and then go back to recognising it as 'light sleep'. Oh well, time to throw it away. Seems it's not a Gadgetbridge's fault.
I think that's a good start. I'll try to find some more objective stuff on the accuracy to reference. The manufacturers have no incentive to publish data that says there devices arent' accurate so it may be har dto come by. I'd be interested to see what data the devices are putting out as that would help in trying to figure out what if any analysis gadgetbridge should do with it.
Thanks that's really helpful. I did find some methods for using the raw actigraphy data.
It looks like the devices don't report enough for gadgetbridge to use it's own method, so may not be worth more time.
Gradeing of sleep via actigraphy alone is controvesial at best. For sleep no sleep accuracy often around 90% for a given epoch it's like spell check where even 99% accuracy can lead to lots of unreadable sentences. It's really hard to gauge the actual utility of a given method.
I suspect they are using Sadeh's algorithm as it's been around for a while, widely and is fairly simple to calculate on hardware like the MI band.:
SI(sleep index)( = 7.601 - 0.065 * mu - 0.056_sigma - 0.0703_LogAct- 1.08 nat
SI = sleep index (>1 is considered asleep)
mu = mean activity in an 11 minute window centered on the current epoch
sigma = standard deviation of activity for the last 6 min
LogAct= natural log of the activity in the current epoch increased by 1
nat = the number of epochs in the 11 minute window 50<= epoch activity <= 100
ref: Sadeh and Sharky Sleep 1994:17: 201-207
Really interesting! Thanks! Some post processing that happens for sure in other apps is the identification of deep sleep periods, are there known ways to calculate these? Currently we have no clean way to show deep sleep to the user because we only have punctual data, and adjacent deep sleep samples aren't good enough.
If you could share some algorithm I can apply it to the pebble health samples: on the watch I can see the deep sleep periods but they are not transferred to the phone (only the total amount of deep sleep seconds is transmitted, without temporal coordinates) so I could "easily" check if they use the same algo.
I will look for a method. There are no good validated methods I'm aware of for deep vs light sleep. Sleep stages are defined formally by EEG findings which no wearable collects. Apparently a common method is to look for periods of complete inactivity and call that REM. While a reasonable thought it has problems as some just don't move much in their sleep. Certain sleep disorders such as Sleep paralysis and rem behavior disorder violate these assumptions.
Is there an easy way to see a raw data file or can you post one here? I'm trying to understand better what exactly the devices are providing.
I realised that it's neither Gadgetbridge's fault, nor my Mi Band's fault. It's Xiaomi's fault. I returned my Mi Band and got a new one, and now it's happening again. No wakeup(activity) data, only sleep(light/deep) data. Different band, same firmware version, same problem. I think latest firmware is not processing sleep/awake data properly.
You could downgrade to a different version with Gadetbridge. There is very preliminary information how to do it at https://github.com/Freeyourgadget/Gadgetbridge/wiki/User-Documentation. For Mi Band 1A, firmware version 126.96.36.199 (MiFit 1.5.912-1539) works pretty well.
Thanks, but I don't know where to get the firmware. It seems Mi Fit APK file itself contains a firmware, but I couldn't find neither 188.8.131.52 firmware nor 1.5.912-1539 Mi Fit app. Can you do me a favor?
I can, but unfortunately not now, because I'm away for the weekend. I think you can find it on apkmirror.com, though.
@official-jkim I deleted your comment because I believe there may be issues distributing firmware files. Further there is a bug on github that make shared files from forked repositories look like they are part of the original repo.
HR sensing is totally OK for my MiBand 1s
How can this improve sleep-detection?
On my 1S, activity and sleep detection is totally bogus. HR did not work at all until I upgraded the firmware and the Mi Band firmware gave me > 23h of sleep per day. With my new firmware 184.108.40.206, things look a lot better.
“All of these devices are not particularly accurate for measurements of sleep” — @Samarium151
I was really surprised to see just how accurate the MiFit app recognises my sleep lengths. When using the official app for a bit more than the last two months, I never had an incident, where the “fell asleep”- and “wake up”-times were wrong.
“This inaccurate sleep detection is resulted in much longer sleep hour, such as 12 hours of sleep instead of 8 hours of actual sleep.” — @official-jkim
However, I have witnessed the opposite with Gadgetbridge. The software will display me as being awake long after falling asleep and long before actually waking up. Thus, I get much fewer sleeping hours per app as I actually do.
I'm wearing my tracking band (MiFit 1S) quite loosely.
@0nse That's interesting results. Which firmware version do you use? The version that came with my 1S was utterly broken, it reported > 23h sleep per day.
But if you use the same device and firmware both with Mi Fit and Gadgetbridge, and the results are really different, then I'd love to analyze that.
Gadgetbridge has an option in the Mi Band settings to keep activity data on the device. If you enable that, you could
- sleep a night
- then fetch activity data with Gadgetbridge
- then fetch activity data with Mi Fit
and compare the results. I'd love to hear them.
- FW: 220.127.116.11
- HR: 18.104.22.168
I will report back when I have the results of the same night by both apps.
Edit: For some reason, I cannot get MiFit and GB to both read out the info although I have set GB to keep the data on the device and I open up GB before MiFit. What happens most of the time is that neither of the two apps will be able to fetch any data. The update to MiFit 2.0 didn't make things any better. So for now, I cannot report any comparisons.
I can only say that GB will already think that I am awake when I am in very light sleep where MiFit would ignore this little light sleep peak. Here's an example with Sleep as Android as reference.
I guess this correlates with the MiBand ignoring sleep when it happens anytime but at night. That is, neither MiFit nor GB would detect sleep patterns (although one can clearly recognise them when looking at the activity graph) when sleep started in the morning, which is bad for people working night shifts.
The image also shows that GB will irregularly recognise my band as being not worn although that is false.
Since a few weeks we have two helper functions that allow for changing the stored sample type. See this method and the one that follows.
The former overwrites any stored type with the desired one, the latter changes only from a specific sample type to another (use case: change from "awake" to "sleeping" but preserve eventual "deep sleep" samples.
The GUI to let users change their samples is still missing, though.
Just wanted to share my results with you. I experience similar results. E.g. last night I slept for around 7 hours but GB only shows around 2 hours. In general I get far less sleep time in GB as in MiFit. I'll try to track one night with GB and MiFit. Is there any good method to provide the results beside the activity graphs?
always provide the mi band fw version, and if you have a heart rate sensor, then indicate whether you enabled the sensor to measure during sleep or not.
Also check if the settings are correct (e.g. if you wear it on the left or right wrist).
do you wear it loosely or have it tight?
so far, we don't do any post processing of the data that the band provides. Maybe we need to do that.
The data measured with my 1S with fw version 22.214.171.124 look pretty realistic to me, wearing the band tightly.
- Sorry, forgot to mention my hard- and software specs. I have the Mi1S (FW 126.96.36.199) and use the HR sensor for sleep improvement
- Is set correctly
- Rather loosely, I tried it a bit tighter but that doesn't seem to improve measurements.
I'll try to downgrade the FW after doing some tests with MiFit. Maybe the FW you mentioned works better with GB.
@v1r0x what kind of activity does GB show when it's not sleep? Green activity? Also, did you use the same data for GB and mifit by syncing with GB first, but keeping the data on the band?
Yes, green activity. I didn't compare GB and MiFit, but the results from MiFit seemed to be more precise before I switched to GB.
Sleep records from Mi Band 2 significantly different than what Mi Fit says they are.
I've been doing an experiment with both Gadgetbridge (0.16 self-compiled) and Mi Fit (2.2.9) connected to the same Mi Band 2 (HW v0.1.3.2, FW v188.8.131.52). I know the Wiki says this doesn't work but it seems to work for me. The sleep records from both apps are significantly different. I am careful to not use either app after going to bed, and try to remember to sync first Gadgetbridge followed by Mi Fit in the morning. Gadgetbridge is configured to leave data on the device. I got the order wrong 5 mornings out of 14 but None of the numbers match for the other days. For about 3 days they are vaguely in the same ballpark after allowing for Gadgetbridge having the "light" and "dark" categories the wrong way round.
The temporal distribution of light and deep sleep each night varies even more between both apps which makes me wonder if Gadgetbridge interpretation of the "raw" data is correct, or if Mi Fit does additional processing.
I have the same issue, and the HR is between 60-90 with the HR detection used for sleep state enabled - still it shows as deep sleep(!) which I think given the HR is kind of obviously not true...?
...unless I'm dreaming this right now and not actually typing a GitHub comment 😄
FW: 184.108.40.206, HW: V0.1.3.3 (Xiaomi Mi Band 2), Gadgetbridge 0.26.5 (f-droid)
Now as I'm typing this, my HR seems to have reached 100 though and it went from graphing deep sleep right into activity (even though I am sitting and typing, not even standing up). The pulse looks kind of correct to me, but the sleep thing is just completely off.
Edit: oops, ignore this, mixed up the tickets. 😆
Deleting a branch is permanent. It CANNOT be undone. Continue?