Before opening an issue please confirm the following:
Your issue is:
I export data from GB database. I look on RAW_KIND column, there is a lot of values:
0
1
10
11
12
16
17
3
33
34
49
50
66
82
9
According source code, there is some known values:
public static final int TYPE_DEEP_SLEEP = 4;
public static final int TYPE_LIGHT_SLEEP = 5;
public static final int TYPE_ACTIVITY = -1;
public static final int TYPE_UNKNOWN = -1;
public static final int TYPE_NONWEAR = 3;
public static final int TYPE_CHARGING = 6;
// public static final byte TYPE_NREM = 5; // DEEP SLEEP
// public static final byte TYPE_ONBED = 7;
// public static final byte TYPE_REM = 4; // LIGHT SLEEP
// public static final byte TYPE_RUNNING = 2;
// public static final byte TYPE_SLIENT = 0;
// public static final byte TYPE_USER = 100;
// public static final byte TYPE_WALKING = 1;
What about other values ? Do we have any ideas ?
Best regards.
Your wearable device is: Miband2
Your android version is: 7
Your Gadgetbridge version is: 0.19.1
#### Before opening an issue please confirm the following:
- [x] I have read the [wiki](https://github.com/Freeyourgadget/Gadgetbridge/wiki), and I didn't find a solution to my problem / an answer to my question.
- [x] I have searched the [issues](https://github.com/Freeyourgadget/Gadgetbridge/issues), and I didn't find a solution to my problem / an answer to my question.
#### Your issue is:
I export data from GB database. I look on RAW_KIND column, there is a lot of values:
```
0
1
10
11
12
16
17
3
33
34
49
50
66
82
9
```
According source code, there is some known values:
```
public static final int TYPE_DEEP_SLEEP = 4;
public static final int TYPE_LIGHT_SLEEP = 5;
public static final int TYPE_ACTIVITY = -1;
public static final int TYPE_UNKNOWN = -1;
public static final int TYPE_NONWEAR = 3;
public static final int TYPE_CHARGING = 6;
// public static final byte TYPE_NREM = 5; // DEEP SLEEP
// public static final byte TYPE_ONBED = 7;
// public static final byte TYPE_REM = 4; // LIGHT SLEEP
// public static final byte TYPE_RUNNING = 2;
// public static final byte TYPE_SLIENT = 0;
// public static final byte TYPE_USER = 100;
// public static final byte TYPE_WALKING = 1;
```
What about other values ? Do we have any ideas ?
Best regards.
#### Your wearable device is: Miband2
#### Your android version is: 7
#### Your Gadgetbridge version is: 0.19.1
No, we have no idea. Also, the values have changed in recent firmware versions (see #650), so the above values (at least regarding sleep) are not used anymore.
No, we have no idea. Also, the values have changed in recent firmware versions (see #650), so the above values (at least regarding sleep) are not used anymore.
0 -> unknown
1 -> walking
10 -> occurs all along day and night... no idea
11 -> occurs twice a day, one when I fall asleep and one other 12h later
12 -> occurs twice a day, one when I wake up and one other 12h later
16 -> occurs at 0h
17 -> occurs only when I walk, is it an higher step speed ?
3 -> not worn
9 -> must of time at night, light or deep sleep ?
98 -> running
97 -> start of running session
82 -> end of running session
What I notice on my data (3 days basis):
```
0 -> unknown
1 -> walking
10 -> occurs all along day and night... no idea
11 -> occurs twice a day, one when I fall asleep and one other 12h later
12 -> occurs twice a day, one when I wake up and one other 12h later
16 -> occurs at 0h
17 -> occurs only when I walk, is it an higher step speed ?
3 -> not worn
9 -> must of time at night, light or deep sleep ?
98 -> running
97 -> start of running session
82 -> end of running session
```
raw_kind from 1.0.1.50 differs totally from previous version. It's really hard to determine activity kind:
1 -> walking
105 -> wake up during sleep
106
112 -> sleep, raw_intensity = 0
115 -> not worn
121
122 -> sleep, raw_intensity =<20
123 -> fall asleep
124
16
17 -> 1 min before and 1 min after walking
26
28 ->
80 -> no step
83
89 -> wake up
90
91
96
99
I'm going to complete this list in a few days. I will have more data. Hope it will be easier to determine activity kind.
raw_kind from 1.0.1.50 differs totally from previous version. It's really hard to determine activity kind:
```
1 -> walking
105 -> wake up during sleep
106
112 -> sleep, raw_intensity = 0
115 -> not worn
121
122 -> sleep, raw_intensity =<20
123 -> fall asleep
124
16
17 -> 1 min before and 1 min after walking
26
28 ->
80 -> no step
83
89 -> wake up
90
91
96
99
```
I'm going to complete this list in a few days. I will have more data. Hope it will be easier to determine activity kind.
Just chiming in to say that if some values are reported one minute before running/walking/doing any activity, it means that some postprocessing is happening on the device as well now.
Just chiming in to say that if some values are reported one minute **before** running/walking/doing any activity, it means that some postprocessing is happening on the device as well now.
Sometimes some relations might be more apparent when viewing the byte values in base 2 (bits) instead of numbers in base 10 (I didn't do any conversion in this specific case, just speaking out of experience)
Sometimes some relations **might** be more apparent when viewing the byte values in base 2 (bits) instead of numbers in base 10 (I didn't do any conversion in this specific case, just speaking out of experience)
Hey! i would like to revive this issue!
First question: Is Gadgetbridge able to interpret Data according to Firmware version? I guess it would be nice if Gadgetbridge marks every data it pulls, with the version the Mi Band 2 was running at that time. So data can also be retrospectively interpreted correctly by Gadgetbridge.
I would be interested if soembody did some additional research or tried to implement something. I can not program, but if needed I could try to analyse my data, to see what means what.
So does Gadgetbridge dump all data? Also data it doesn't know? Is this then the "RAW_KIND" column?
Thanks!
Hey! i would like to revive this issue!
First question: Is Gadgetbridge able to interpret Data according to Firmware version? I guess it would be nice if Gadgetbridge marks every data it pulls, with the version the Mi Band 2 was running at that time. So data can also be retrospectively interpreted correctly by Gadgetbridge.
I would be interested if soembody did some additional research or tried to implement something. I can not program, but if needed I could try to analyse my data, to see what means what.
So does Gadgetbridge dump all data? Also data it doesn't know? Is this then the "RAW_KIND" column?
Thanks!
AFAIK, GadgetBridge does only fetch data from Mi Band. It retrieves RAW_KIND and something like intensity, heart rate and steps. Data are stored as is. I think Mi Band determines RAW_KIND from intensity and steps.
Marking all data will encount a large overhead with no added value. We only need upgrade datetime or current firmware version when fetching.
You can follow Wiki guide to export your data and try to determine all raw_kind data. We will be able to compare our results and match id from Mi Band.
Hi,
AFAIK, GadgetBridge does only fetch data from Mi Band. It retrieves RAW_KIND and something like intensity, heart rate and steps. Data are stored as is. I think Mi Band determines RAW_KIND from intensity and steps.
Marking all data will encount a large overhead with no added value. We only need upgrade datetime or current firmware version when fetching.
You can follow Wiki guide to export your data and try to determine all raw_kind data. We will be able to compare our results and match id from Mi Band.
Well, about the firmware version. Gadgetbridge actually records that already in DEVICE_ATTRIBUTES.(timestamps from and until which version was used). So thats good.
How can I make a real time from the timestamps? Knowing when something happened might be the first start to understand the data :D
I have numbers like that: 1501625460
EDIT: i was digging through the Mi Fit app and found a setting called "pattern recognition" ("Verhaltenserkennung"). There it lets you choose something eg. Sit ups. When you select it, it asks you to do sit ups, and does a continues recording of your heart rate and movements. Then you do them until you decide to stop your workout. Then it uploads something. Now my question: Does this upload some data to the band in order to improve its recognition, or does it only upload this somewhere else and then does the processing in the app?
If this indeed uploads something to the band, maybe that could be a lot of the unknown codes? Maybe it assigns different codes to actions you can improve via the app?
Here is the bluetooth log of this: btsnoop_hci.log.txt
I don't see if it uploaded some info to the band or not, the only thing I can see in there is the continuous stream of data from the band to the phone while recording the behavior.
Maybe we also should split this up and first concentrate and restoring the sleep tracking?
My question regarding the timestamps still stands, as i cant really correlate the database entries to what I did at the moment.
Well, about the firmware version. Gadgetbridge actually records that already in DEVICE_ATTRIBUTES.(timestamps from and until which version was used). So thats good.
How can I make a real time from the timestamps? Knowing when something happened might be the first start to understand the data :D
I have numbers like that: 1501625460
EDIT: i was digging through the Mi Fit app and found a setting called "pattern recognition" ("Verhaltenserkennung"). There it lets you choose something eg. Sit ups. When you select it, it asks you to do sit ups, and does a continues recording of your heart rate and movements. Then you do them until you decide to stop your workout. Then it uploads something. Now my question: Does this upload some data to the band in order to improve its recognition, or does it only upload this somewhere else and then does the processing in the app?
If this indeed uploads something to the band, maybe that could be a lot of the unknown codes? Maybe it assigns different codes to actions you can improve via the app?
Here is the bluetooth log of this:
[btsnoop_hci.log.txt](https://github.com/Freeyourgadget/Gadgetbridge/files/1193877/btsnoop_hci.log.txt)
I don't see if it uploaded some info to the band or not, the only thing I can see in there is the continuous stream of data from the band to the phone while recording the behavior.
Maybe we also should split this up and first concentrate and restoring the sleep tracking?
My question regarding the timestamps still stands, as i cant really correlate the database entries to what I did at the moment.
New post for MiBand 2 not being worn, just lying on a table:
This dump is 0% movement. I did not touch the band or the table.
The HR sensor switches on every 2 minutes and tries to measure.
New post for **MiBand 2 not being worn,** just lying on a table:

This dump is 0% movement. I did not touch the band or the table.
The HR sensor switches on every 2 minutes and tries to measure.
New post for Miband 2 at the arm; Arm as still as possible on the table for 20 minutes... (imitating deep sleep i guess?)
New post for **Miband 2 at the arm; Arm as still as possible** on the table for 20 minutes... (imitating deep sleep i guess?)

Ok. So I set 112 as light sleep and get 4:21 light sleep, vs. 4:36 in the Mi Fit app. Doesnt seem to bad. I had a nap today, could be that this maybe is missing in Gadgetbridge.
112 with intensity of 0 means not wearing. I guess 112 intensity >0 means light sleep. I am not able to programm this, but my build system is running and I would be willing to test.
I set 122 as deep sleep and get 18 minutes (vs 41min in Mi Fit), so somethings off there, but it looks as if it is in the right places.
How can I set multiple types for an activity? Obviously we want to keep the old values in and add the new ones to it.
Ok. So I set 112 as light sleep and get 4:21 light sleep, vs. 4:36 in the Mi Fit app. Doesnt seem to bad. I had a nap today, could be that this maybe is missing in Gadgetbridge.
112 with intensity of 0 means not wearing. I guess 112 intensity >0 means light sleep. I am not able to programm this, but my build system is running and I would be willing to test.
I set 122 as deep sleep and get 18 minutes (vs 41min in Mi Fit), so somethings off there, but it looks as if it is in the right places.
How can I set multiple types for an activity? Obviously we want to keep the old values in and add the new ones to it.
Some values identify sleep start and sleep end. It apparently corresponds to 28, 105, 106 and 123. Do you get these values ? Are they better matching with official app?
Does official app detect REM period ? Is there some raw kind values related ?
Best regards.
Some values identify sleep start and sleep end. It apparently corresponds to 28, 105, 106 and 123. Do you get these values ? Are they better matching with official app?
Does official app detect REM period ? Is there some raw kind values related ?
Best regards.
Actually quite interesting.
I think 28 indicates waking + standing up. So you get active and also walk. (Steps are counted + higher raw intensity).
105 means waking up but staying in bed (no steps but high raw intensity).
106 is something very rare for me. Not quite sure about it.
123 always appears after 2-5 112s (light sleep), so that seems to be a approval of start of sleep.
The official app detects Light/deep sleep (I guess equals REM/NREM?) and times of waking up in the night.
To further test this, somebody would need to integrate a function of counting sleep from 123 until 28 or 105. I could build this myself and try to see how it fits to MiFit results.
Unfortunately I do not have access to my MiBand charger right now(and I am at 7%). I will have access again from 21. August, so that's when I will be able to test again.
Actually quite interesting.
I think 28 indicates waking + standing up. So you get active and also walk. (Steps are counted + higher raw intensity).
105 means waking up but staying in bed (no steps but high raw intensity).
106 is something very rare for me. Not quite sure about it.
123 always appears after 2-5 112s (light sleep), so that seems to be a approval of start of sleep.
The official app detects Light/deep sleep (I guess equals REM/NREM?) and times of waking up in the night.
To further test this, somebody would need to integrate a function of counting sleep from 123 until 28 or 105. I could build this myself and try to see how it fits to MiFit results.
Unfortunately I do not have access to my MiBand charger right now(and I am at 7%). I will have access again from 21. August, so that's when I will be able to test again.
@ashimokawa
I saw that you added the Amazfit Bip, which you write in the wiki is similar to the MiBand 2.
How is sleep tracking working for it? Are there parallels concerning the new firmwares for the Mi band 2?
@ashimokawa
I saw that you added the Amazfit Bip, which you write in the wiki is similar to the MiBand 2.
How is sleep tracking working for it? Are there parallels concerning the new firmwares for the Mi band 2?
@Roxxor91
Sleep tracking seems to work with the Bip.
This thread is indeed interesting (first time I read it since I never had a Mi 2), and I have to look at the raw values that come from the Bip. I will report back when I did.
@Roxxor91
Sleep tracking seems to work with the Bip.
This thread is indeed interesting (first time I read it since I never had a Mi 2), and I have to look at the raw values that come from the Bip. I will report back when I did.
Thanks for the work
I tried to figure it out as well for my Nextcloud visualization, which worked with 1.0.1.39 before: https://github.com/nickv-nextcloud/gadgetbridge
As mentioned before, it seems like Xiaomi uses some types to start/stop sleep counting.
I am unfortunately not a programmer and cant integrate it into the code to test it.
Maybe somebody could try? I would definitely test and compare to MiFit!
Details see my post from 11. August.
As mentioned before, it seems like Xiaomi uses some types to start/stop sleep counting.
I am unfortunately not a programmer and cant integrate it into the code to test it.
Maybe somebody could try? I would definitely test and compare to MiFit!
Details see my post from 11. August.
@Vebryn
Sure if you have any idea how to fix this go ahead. Honestly I have none.
For me sleep is also totally broken on Bip with firmware 0.0.8.74
I get raw kind 96 most of the time during sleep but also often 99 for some time and sporadically 105-108.
EDIT: the night before that I had mostly 80 or 90 as rawKind.
This does not fit in what you posted so far.
I think, honestly, this is completely impossible to fix without iterating over all data and do some post-processing and have a new column for a "reconstructed" activity type.
@Vebryn
Sure if you have any idea how to fix this go ahead. Honestly I have none.
For me sleep is also totally broken on Bip with firmware 0.0.8.74
I get raw kind 96 most of the time during sleep but also often 99 for some time and sporadically 105-108.
EDIT: the night before that I had mostly 80 or 90 as rawKind.
This does not fit in what you posted so far.
I think, honestly, this is completely impossible to fix without iterating over all data and do some post-processing and have a new column for a "reconstructed" activity type.
@ashimokawa
I actually think we are quite close. We just need to assign new numbers to the activities. But in order to do that, I would need to know how to add multiple numbers to one activity kind; eg. 9 AND 112 mean light sleep.
With my tests i was able to get quite close results to the MiFit app. But I replaced the numbers form the old firmwares and in result old firmware data was not interpreted correctly.
As a second step we could try to add a from -> to counter (fall asleep -> wake up) to mark obtain sleep time.
@ashimokawa
I actually think we are quite close. We just need to assign new numbers to the activities. But in order to do that, I would need to know how to add multiple numbers to one activity kind; eg. 9 AND 112 mean light sleep.
With my tests i was able to get quite close results to the MiFit app. But I replaced the numbers form the old firmwares and in result old firmware data was not interpreted correctly.
As a second step we could try to add a from -> to counter (fall asleep -> wake up) to mark obtain sleep time.
@Roxxor91
Okay, maybe it can be fixed for a Mi Band 2, for the Bip current code worked well with the initial firmware but for the latest I am really out of ideas.
I just checked what happens when I assign 80 and 90 as sleep - but when I do that I am also asleep at work. and while walking and - well half of the day, even at high intensity.
In fact I cannot even see what the difference between sleeping and working is except that there is less intensity while sleeping ;)
But maybe Mi Band 2 stuff can be fixed by improving the postprocessing we already do, for the Bip at least I am waiting for a new firmware.
Unfortunately I cannot test myself with a Mi Band 2 because I have none.
@Roxxor91
Okay, maybe it can be fixed for a Mi Band 2, for the Bip current code worked well with the initial firmware but for the latest I am really out of ideas.
I just checked what happens when I assign 80 and 90 as sleep - but when I do that I am also asleep at work. and while walking and - well half of the day, even at high intensity.
In fact I cannot even see what the difference between sleeping and working is except that there is less intensity while sleeping ;)
But maybe Mi Band 2 stuff can be fixed by improving the postprocessing we already do, for the Bip at least I am waiting for a new firmware.
Unfortunately I cannot test myself with a Mi Band 2 because I have none.
I am to stupid to make a pull request. Somebody please do that for me.
EDIT: @ashimokawa
As you were talking about intensity... Can we get that into interpretation somehow?
112 with intensity =0 means not worn.
112 with intensity >0 means light sleep.
Here is the patch for sleep tracking for MiBand 2 new firmwares:
https://gist.github.com/Roxxor91/0d3ff17153270e447d01e7afd0c54e0f
With the nice help of "LjL-Alplet" from IRC, who told me how to get multiple activity definitions into the file.
I am to stupid to make a pull request. Somebody please do that for me.
EDIT:
@ashimokawa
As you were talking about intensity... Can we get that into interpretation somehow?
112 with intensity =0 means not worn.
112 with intensity >0 means light sleep.
@Roxxor91
As expected for the Bip this does not help.
About your question:
add this at the end of the for loop in postprocess(), after line 104 in your file as posted in your gist
```
if (lastValidKind == TYPE_LIGHT_SLEEP_NEWFW && sample.getIntensity() == 0) {
sample.setRawKind(TYPE_NONWEAR);
}
```
@Roxxor91 if you are not too frustrated with github you can try the following:
fork the Gadgetbridge repository :octocat:
clone your fork
create a new branch (important! every commit in the branch will be appended to the PR! So do a branch for each distinct feature you want to implement, and add commits to the branch if things needs to be fixed)
if you don't see your fork in the dropdown on the left, click the link "compare across forks" :octocat:
choose your fork and your feature branch in the dropdowns on the right (compare) :octocat:
check that the dropdowns on the left point to the Freeyourgadget repo, master branch :octocat:
you should see only your commits, if everything is fine push "create pull request" :octocat:
the lines marked as :octocat: are performed on the github web interface, others happen on your PC.
There are faster ways and shortcuts all around, but the procedure above should work no matter what.
Hope this helps!
@Roxxor91 if you are not too frustrated with github you can try the following:
1. fork the Gadgetbridge repository :octocat:
2. clone your fork
3. create a new branch (important! every commit in the branch will be appended to the PR! So do a branch for each distinct feature you want to implement, and add commits to the branch if things needs to be fixed)
4. do your changes and commit them to the branch
5. push the branch to your fork
6. go to [this page](https://github.com/Freeyourgadget/Gadgetbridge/compare) :octocat:
7. if you don't see your fork in the dropdown on the left, click the link "compare across forks" :octocat:
8. choose your fork and your feature branch in the dropdowns **on the right** (compare) :octocat:
9. check that the dropdowns on the left point to the Freeyourgadget repo, master branch :octocat:
10. you should see only your commits, if everything is fine push "create pull request" :octocat:
the lines marked as :octocat: are performed on the github web interface, others happen on your PC.
There are faster ways and shortcuts all around, but the procedure above should work no matter what.
Hope this helps!
EDIT: By the way, I now figured out how to convert the timestamps to a real time and was able to correlate precisely now.
I think I understood most of it, but it will need some processing. (a lot of "if" arguments incoming, even though I wont be able to write them :D) I will make a new post for the explanation.
Yai! Thanks, I did it!
EDIT: By the way, I now figured out how to convert the timestamps to a real time and was able to correlate precisely now.
I think I understood most of it, but it will need some processing. (a lot of "if" arguments incoming, even though I wont be able to write them :D) I will make a new post for the explanation.
So when you are inactive, you are given the value "81".
If the value "81" is with a raw intensity of <3 for ten times, this triggers 91. -> You fell asleep.
-> Those 10x 81 are then interpreted as Light sleep (as those values cant be changed anymore, but mean that you were sleeping at that point) -> So a 91 basically means: You had light sleep the 10 minutes before.
From this point on everything is recorded as 112. Now we are in a deep sleep phase. Why? Because from here I had only 112s with raw intensity of 0! I figured out the threshold: If you have 8 times (or 8 minutes) 112s with 0 intensity, you are now in deep sleep. (we start counting deepslep from the 8th 112 with 0 intensity)
So when do I switch back to light sleep? Easy! We have a 112 with increased intensity! For me the lowest value was intensity 6 to wake up. So lets asume intensity >5 112 means you switched from deep, to light sleep.
I was ripped of my nice sleep by having to lock the door after somebody. As we already know, my waking up + walking meant i received a 28 for waking up.
If something is unclear, please comment.
So when you are inactive, you are given the value "81".
If the value "81" is with a raw intensity of <3 for ten times, this triggers 91. -> You fell asleep.
-> Those 10x 81 are then interpreted as Light sleep (as those values cant be changed anymore, but mean that you were sleeping at that point) -> So a 91 basically means: You had light sleep the 10 minutes before.
From this point on everything is recorded as 112. Now we are in a deep sleep phase. Why? Because from here I had only 112s with raw intensity of 0! I figured out the threshold: If you have 8 times (or 8 minutes) 112s with 0 intensity, you are now in deep sleep. (we start counting deepslep from the 8th 112 with 0 intensity)
So when do I switch back to light sleep? Easy! We have a 112 with increased intensity! For me the lowest value was intensity 6 to wake up. So lets asume intensity >5 112 means you switched from deep, to light sleep.
I was ripped of my nice sleep by having to lock the door after somebody. As we already know, my waking up + walking meant i received a 28 for waking up.
If something is unclear, please comment.
10 repetitions of type "81", intensity<"3" set the next minute as 91, correct?
the official app considers also the 10 minutes with type "81" as light sleep
From this point on everything is recorded as 112. Now we are in a deep sleep phase.
does this mean there is only one sample with type "91"?
this seems strange to me as it would mean at most 11 minutes of "light sleep" before deep sleeping?
If you have 8 times (or 8 minutes) 112s with 0 intensity, you are now in deep sleep.
so in this case there is not a specific value of type that changes the values in the past, correct?
So when do I switch back to light sleep? Easy! We have a 112 with increased intensity! For me the lowest value was intensity 6 to wake up.
I'm not sure if you woke up with a sequence of type 112, intensity 6 followed by type 28 or just with the first sample.
if 112/6 means "wake up", then the light sleep would be 112 with intensity < 5, correct?
So I try to summarize:
type 81: "inactive"
type 91: "inactive for too long, Roxxor91 started sleeping 10 minutes ago"
type 112: "sleeping"
type 112 with intensity "0" for 8 minutes: "deep sleep begins (now)"
type 112 with intensity >5: "sleeping"
type 28: "out of bed"
I have some questions.
- 10 repetitions of type "81", intensity<"3" set the **next minute** as 91, correct?
- the official app considers also the 10 minutes with type "81" as light sleep
> From this point on everything is recorded as 112. Now we are in a deep sleep phase.
- does this mean there is only one sample with type "91"?
- this seems strange to me as it would mean at most 11 minutes of "light sleep" before deep sleeping?
> If you have 8 times (or 8 minutes) 112s with 0 intensity, you are now in deep sleep.
- so in this case there is not a specific value of type that changes the values in the past, correct?
> So when do I switch back to light sleep? Easy! We have a 112 with increased intensity! For me the lowest value was intensity 6 to wake up.
- I'm not sure if you woke up with a sequence of type 112, intensity 6 followed by type 28 or just with the first sample.
- if 112/6 means "wake up", then the light sleep would be 112 with intensity < 5, correct?
So I try to summarize:
- type 81: "inactive"
- type 91: "inactive for too long, Roxxor91 started sleeping 10 minutes ago"
- type 112: "sleeping"
- type 112 with intensity "0" for 8 minutes: "deep sleep begins (now)"
- type 112 with intensity >5: "sleeping"
- type 28: "out of bed"
10 repetitions of type "81", intensity<"3" set the next minute as 91, correct?
the official app considers also the 10 minutes with type "81" as light sleep
Correct
does this mean there is only one sample with type "91"?
correct
this seems strange to me as it would mean at most 11 minutes of "light sleep" before deep sleeping?
You correctly calculated what MiFit was showing me. This happened because directly after it, I was sleeping with 0 movement. Also in this it started counting deep sleep from the first 112. I think this happened because it redefined the 10x 81(normally meaning inactivity, not sleep) as 10x 112 with 0 intensity, so criteria for deep sleep were met.
so in this case there is not a specific value of type that changes the values in the past, correct?
As far as I can see there is not, so correct.
I'm not sure if you woke up with a sequence of type 112, intensity 6 followed by type 28 or just with the first sample.
if 112/6 means "wake up", then the light sleep would be 112 with intensity < 5, correct?
112 with intensity doesnt mean I woke up! We are in deep sleep with 112 intensity 0, now when we get 112 intensity >5, that means that i am moving more in my sleep, saying that i am now in light sleep!
When i woke up, it is whether 28 (I got up, so the band measures my high activity and steps) or 105 (so i am doing stuff in bed, similar like sitting inactive, but as I am on my computer, my wrist movements are really intense, meaning I am certainly not sleeping anymore, but there are no steps!).
After that "he is awake again", inactivity gets coded as 81 again.
28 and 105 are not depended on your activity before, but just that you were in "general sleep mode" before, but now you are so active that you are definitely not sleeping anymore, so we leave "sleep mode" for "day" mode.
type 81: "inactive"
Yes
type 91: "inactive for too long, Roxxor91 started sleeping 10 minutes ago"
Yes
type 112: "sleeping"
Yes
type 112 with intensity "0" for 8 minutes: "deep sleep begins (now)"
Yes
type 112 with intensity >5: "sleeping"
No, rather: type 112 with intensity >5: "deep sleep ended"
type 28: "out of bed"
Let's say: type 28 and 105: "woke up"
EDIT:
So this then also means that the approach changes quite drastically. We have to switch from a total sum to intervals which have to be recognized. I am ready to help with interpretation and testing. But I definitely cant write the code for it...
>10 repetitions of type "81", intensity<"3" set the next minute as 91, correct?
> the official app considers also the 10 minutes with type "81" as light sleep
Correct
>does this mean there is only one sample with type "91"?
correct
>this seems strange to me as it would mean at most 11 minutes of "light sleep" before deep sleeping?
You correctly calculated what MiFit was showing me. This happened because directly after it, I was sleeping with 0 movement. Also in this it started counting deep sleep from the **first** 112. I think this happened because it redefined the 10x 81(normally meaning inactivity, not sleep) as 10x 112 with 0 intensity, so criteria for deep sleep were met.
>so in this case there is not a specific value of type that changes the values in the past, correct?
As far as I can see there is not, so correct.
>I'm not sure if you woke up with a sequence of type 112, intensity 6 followed by type 28 or just with the first sample.
>if 112/6 means "wake up", then the light sleep would be 112 with intensity < 5, correct?
112 with intensity doesnt mean I woke up! We are in deep sleep with 112 intensity 0, now when we get 112 intensity >5, that means that i am moving more in my sleep, saying that i am now in light sleep!
When i woke up, it is whether 28 (I got up, so the band measures my high activity and **steps**) or 105 (so i am doing stuff in bed, similar like sitting inactive, but as I am on my computer, my wrist movements are really intense, meaning I am certainly not sleeping anymore, but there are no steps!).
After that "he is awake again", inactivity gets coded as 81 again.
28 and 105 are not depended on your activity before, but just that you were in "general sleep mode" before, but now you are so active that you are definitely not sleeping anymore, so we leave "sleep mode" for "day" mode.
>type 81: "inactive"
Yes
>type 91: "inactive for too long, Roxxor91 started sleeping 10 minutes ago"
Yes
>type 112: "sleeping"
Yes
>type 112 with intensity "0" for 8 minutes: "deep sleep begins (now)"
Yes
>type 112 with intensity >5: "sleeping"
No, rather: type 112 with intensity >5: "deep sleep ended"
>type 28: "out of bed"
Let's say: type 28 and 105: "woke up"
EDIT:
So this then also means that the approach changes quite drastically. We have to switch from a total sum to intervals which have to be recognized. I am ready to help with interpretation and testing. But I definitely cant write the code for it...
@danielegobbetti@ashimokawa@Vebryn
So just that everybody knows how I do this analysis, here is my file which I created to analyze the data. sleep interpretation.xlsx
(File created with LibreOffice Calc, but Github doesn't allow uploading .ods files...)
EDIT: And here is tonight: night 2.xlsx
Mostly the same, but something new I figured: Deep sleep was continuing at one point even though there was a 112 with intensity of 15. So not ANY intensity interrupts deep sleep, but there is some specific level.
@danielegobbetti @ashimokawa @Vebryn
So just that everybody knows how I do this analysis, here is my file which I created to analyze the data.
[sleep interpretation.xlsx](https://github.com/Freeyourgadget/Gadgetbridge/files/1269194/sleep.interpretation.xlsx)
(File created with LibreOffice Calc, but Github doesn't allow uploading .ods files...)
EDIT: And here is tonight:
[night 2.xlsx](https://github.com/Freeyourgadget/Gadgetbridge/files/1269247/night.2.xlsx)
Mostly the same, but something new I figured: Deep sleep was continuing at one point even though there was a 112 with intensity of 15. So not ANY intensity interrupts deep sleep, but there is some specific level.
I think we need to see bits at rear site. 112 is 0111 0000 and 80 is 0101 0000. these numbers mean nothing i think.
Use bitwise operation!!
Basic of my data,
I found sleep must be finished before 12 when i use "rawkind&0x0f". This is the end point of sleep.
9 is light sleep and 11 is actually deep sleep.
etc.
When I don't wear it, type 112 always appeared.
I also don't know the relationship between intensity and sleep but when sleep stage is deep sleep and intensity are high(maybe over 20?), it's going to light sleep.
I think we need to see bits at rear site. 112 is 0111 0000 and 80 is 0101 0000. these numbers mean nothing i think.
Use bitwise operation!!
Basic of my data,
I found sleep must be finished before 12 when i use "rawkind&0x0f". This is the end point of sleep.
9 is light sleep and 11 is actually deep sleep.
etc.
When I don't wear it, type 112 always appeared.
I also don't know the relationship between intensity and sleep but when sleep stage is deep sleep and intensity are high(maybe over 20?), it's going to light sleep.
Could you please elaborate on the bitwise operation? What is it, how does it help, how can I use it?
About 112: I analyzed and explained how I think sleep is determined. Concerning "not wearing": I think it only differs from sleep, as it is not able to measure heart rate (every second minute) and intensity is always 0.
Could you please elaborate on the bitwise operation? What is it, how does it help, how can I use it?
About 112: I analyzed and explained how I think sleep is determined. Concerning "not wearing": I think it only differs from sleep, as it is not able to measure heart rate (every second minute) and intensity is always 0.
@Roxxor91
With a bitwise and unimportant bits can be "thrown away" value & 0xf will thow everything away except the least significant four bits (0xf = 0b1111)
you can use it like this:
rawKind = rawKind & 0xf;
@Roxxor91
With a bitwise and unimportant bits can be "thrown away" value & 0xf will thow everything away except the least significant four bits (0xf = 0b1111)
you can use it like this:
rawKind = rawKind & 0xf;
@kizer93
Indeed the "new values" seem to come from extra bits being set.
Unfortunately just ignoring them leads to wrong sleep detection and wrong "non worn" detection.
We must find out what these flags are.
@kizer93
Indeed the "new values" seem to come from extra bits being set.
Unfortunately just ignoring them leads to wrong sleep detection and wrong "non worn" detection.
We must find out what these flags are.
@ashimokawa
Yeah I know. It won't be anything. However, When light sleep was going, rawkind are 80 and 122. That's why I'm confused between these data.
@ashimokawa
Yeah I know. It won't be anything. However, When light sleep was going, rawkind are 80 and 122. That's why I'm confused between these data.
I took the time and did some tests myself. It really seems that & 0xf will get the old values.
There was a longstanding unrelated bug that always jeopardized my tests, that is why it took so long.
I can confirm that values 11 and 12 also appeared on old firmware - in newer they just have the extra bits.
So there is nothing new except the flags, and masking these out needed some code adjustments.
What is missing
we ignore the flags and have no idea about them so far (it could also be a 4 bit value - no idea
we do not handle value 11 (could it be "fell asleep?")
we have to double check if handling 12(wake up) as activity is ok
In any case I am quite confident that this change brings the newer firmwares on par with the old ones, and the change I did does not affect old firmwares.
Pushed fixes to master 9f05aff11be983a88893b652ce093f314de47257
I took the time and did some tests myself. It really seems that & 0xf will get the old values.
There was a longstanding unrelated bug that always jeopardized my tests, that is why it took so long.
I can confirm that values 11 and 12 also appeared on old firmware - in newer they just have the extra bits.
So there is nothing new except the flags, and masking these out needed some code adjustments.
What is missing
- we ignore the flags and have no idea about them so far (it could also be a 4 bit value - no idea
- we do not handle value 11 (could it be "fell asleep?")
- we have to double check if handling 12(wake up) as activity is ok
In any case I am quite confident that this change brings the newer firmwares on par with the old ones, and the change I did does not affect old firmwares.
Gadgetbridge 0.21.4 has been tagged and will include the change mentioned above. 0.21.3 which has been build and published by F-Droid today does not contain the fix.
Gadgetbridge 0.21.4 has been tagged and will include the change mentioned above. 0.21.3 which has been build and published by F-Droid today does not contain the fix.
I did not communicate it here yet but it seems that later Mi Band 2 firmwares (>1.0.1.39) and Bip firmwares >= 0.0.8.xx do not have working deep sleep detection.
When I go to bed usually the time before I really fall asleep is marked as deep sleep, the rest as light sleep. It seems we have to do more postprocessing on the data.
What would really help if someone could tell what mifit detected (intervals) plus the raw values from the Gadgetbridge database for the same night.
I did not communicate it here yet but it seems that later Mi Band 2 firmwares (>1.0.1.39) and Bip firmwares >= 0.0.8.xx do not have working deep sleep detection.
When I go to bed usually the time before I really fall asleep is marked as deep sleep, the rest as light sleep. It seems we have to do more postprocessing on the data.
What would really help if someone could tell what mifit detected (intervals) plus the raw values from the Gadgetbridge database for the same night.
I tried to change raw_kind value in MiBand2SampleProvider
public static final int TYPE_UNSET = -1;
public static final int TYPE_NO_CHANGE = 0;
public static final int TYPE_ACTIVITY = 1;
public static final int TYPE_RUNNING = 2;
public static final int TYPE_NONWEAR = 3;
public static final int TYPE_CHARGING = 6;
public static final int TYPE_LIGHT_SLEEP = 112; //9
public static final int TYPE_IGNORE = 10;
public static final int TYPE_DEEP_SLEEP = 122; // 11
public static final int TYPE_WAKE_UP = 12;
But not work for me
The sleep chart nothing visible
my mi band 2 fw : 1.0.1.81
I tried to change raw_kind value in MiBand2SampleProvider
```
public static final int TYPE_UNSET = -1;
public static final int TYPE_NO_CHANGE = 0;
public static final int TYPE_ACTIVITY = 1;
public static final int TYPE_RUNNING = 2;
public static final int TYPE_NONWEAR = 3;
public static final int TYPE_CHARGING = 6;
public static final int TYPE_LIGHT_SLEEP = 112; //9
public static final int TYPE_IGNORE = 10;
public static final int TYPE_DEEP_SLEEP = 122; // 11
public static final int TYPE_WAKE_UP = 12;
```
But not work for me
The sleep chart nothing visible
my mi band 2 fw : 1.0.1.81
Hello,
I have gathered over 20 days of Amazfit BIP and Miband2 data extracted from BTsnoop logs and try to interpret when they happen. I used/confirmed some information from #1030, but in general I tried to look at the data compared to reality.
The firmware versions are 0.1.1.36 for BIP and 1.0.1.81 for Miband2, and I have to agree that deep sleep data (and sometimes light sleep data) is interpreted incorrectly. Without upper 4-bit nibble, the rawKind information is incomplete and cannot be interpreted fully.
The deep sleep is however hard to pick as it often starts without any visible specific flag in official application, so @Roxxor91 interpretation of several minutes of sleep with low/zero raw activity starting deep sleep may be right. But it looks like deep sleep is detected as a block of sleeps with at least 10 continuous 0x00 raw values, an occasional 0x70 and 0x79 with raw data bellow 0x20 does not seem to leave it.
I am seem not able to add the full table here so I will include it as an image attachment:
As a result, sometimes the sitting periods are interpreted as sleep and not all sleep intervals are recorded. I tried to add my own interpretations of raw activity types in following tables:
These seem to be correct in GadgetBridge
RAW a. type
Activity description
GB processing status
Comment
0x01
WALK
OK
Normal walk, swimming (at least breast stroke)
0x06
charging
OK
Device is in charger, no activity data available
0x11
WALK 1
OK
Another walk type, applies also to swimming (at least breast stroke)
0x12
RUN 1
OK
Run type
0x19
GO TO BED
OK
Lie down, beginning of the sleep period, this may serve as start of sleep marker for MiFit
0x1c
GET UP 1
OK
Get up from sleep mostly
0x21
WALK UP
OK
Indicates end of measured walk activity, walking up stairs according to #1030
0x22
RUN 2, UP
OK
Running, either up or on start of the run from walk? Seems to differ on Amazfit BIP and Miband2.
0x31
WALK 3, DOWN
OK
Walking, often downwards
0x32
RUN 3, DOWN
OK
Either running downwards, or run end, slowing to walk (downgrade to walk)? Seems to differ on Amazfit BIP and Miband2
0x42
RUN 4
OK
Seen during the run
0x51
WALK 5
OK
Guess: Walking without significant hand movements, hands horizontal
0x52
RUN 5
OK
Run type
0x53
NOT WORN 5
OK
Watch not worn, possibly lying face up
0x5c
GET UP SIT
OK
Get up
0x62
RUN 6
OK
Guess: Running without significant hand movements, hands vertical
0x63
NOT WORN 6
OK
Watch not worn, possibly lying on side
0x6c
GET UP 6
OK
Unknown, interruption of sleep/sit/stand phase
0x73
NOT WORN 7
OK
Watch not worn, deep sleep
0x7c
GET UP SLP
OK
Get up
0x41
UNKNOWN
OK?
Some kind of walk, probably.
0x13
UNKNOWN
unknown
Probably another not worn indication, but during walk phase, band was in bag at that time (?)
These seem to be sometimes interpreted differently from official application, e.g. sleeping instead of sitting.
RAW a. type
Activity description
GB processing status
Comment
0x79
SLP MOVE 9
Partially supported
Movements in sleep, serie of them may indicate a wake up and just lying in the bed, or leave deep sleep to light sleep if RAW data is present
0x5a
SIT MOVE a
Partially supported
Normal sitting with borderline raw value of 20, light sleep in sleep mode
0x59
SIT MOVE 9
Partially, detected only as L.S.
Movements in sitting, but also in sleep, if in sleep mode, serie of them may indicate a wake up and just lying in the bed, or leave deep sleep to light sleep if RAW data is present
0x10
SLOW WALK
Previous activity kept
Slow walk or light activity (no steps may be logged)
0x50
SIT
Previous activity kept
Sitting at computer, driving, transportation, eating, sometimes sleeping
0x60
STAND
Previous activity kept
Standing, sometimes sleeping (during sleep period)
0x70
SLEEP
Previous activity kept
standard sleep, also when Miband2 was not worn for long time periods
0x1a
BACK TO BED
IGNORED
Return to bed during active period before another sleep starts
0x6a
STAND ACT.
IGNORED
Normal standing with borderline raw value of 20, not observed in light or deep sleep mode
These seem to be wrongly interpreted at any time
RAW a. type
Activity description
GB processing status
Comment
0x5b
SIT MOVE b
WRONG, D.S.
Sitting down in last 10 minutes, reinterpret SLEEP/STAND indication in this time frame. Mifit does not interpret this as sleeping, but actually may be part of sleep period
0x6b
UNKNOWN
WRONG, D.S.
Not sleeping, something with standing?
0x69
STAND UP
WRONG, L.S.
Seems to be bound to standing from sitting position or sleep. Breaks sleep
0x7a
SLP MOVE a
IGNORED
Prevent deep sleep indication at this time, goes back to light sleep from deep sleep in MiFit, but may go to deep sleep immediately after
0x7b
SLP MOVE b
WRONG, D.S.
Sleep in last 10 minutes, reinterpret SIT/STAND indication in this time frame
Of course it is just data from a single person, so some interpretation may be incorrect.
I can provide the raw data in sqlite database or odt table if needed.
Hello,
I have gathered over 20 days of Amazfit BIP and Miband2 data extracted from BTsnoop logs and try to interpret when they happen. I used/confirmed some information from #1030, but in general I tried to look at the data compared to reality.
The firmware versions are 0.1.1.36 for BIP and 1.0.1.81 for Miband2, and I have to agree that deep sleep data (and sometimes light sleep data) is interpreted incorrectly. Without upper 4-bit nibble, the `rawKind` information is incomplete and cannot be interpreted fully.
The deep sleep is however hard to pick as it often starts without any visible specific flag in official application, so @Roxxor91 interpretation of several minutes of sleep with low/zero raw activity starting deep sleep may be right. But it looks like deep sleep is detected as a block of sleeps with at least 10 continuous 0x00 raw values, an occasional 0x70 and 0x79 with raw data bellow 0x20 does not seem to leave it.
I am seem not able to add the full table here so I will include it as an image attachment:

As a result, sometimes the sitting periods are interpreted as sleep and not all sleep intervals are recorded. I tried to add my own interpretations of raw activity types in following tables:
### These seem to be correct in GadgetBridge
RAW a. type | Activity description | GB processing status | Comment
-- | -- | -- | --
0x01 | WALK | OK | Normal walk, swimming (at least breast stroke)
0x06 | charging | OK | Device is in charger, no activity data available
0x11 | WALK 1 | OK | Another walk type, applies also to swimming (at least breast stroke)
0x12 | RUN 1 | OK | Run type
0x19 | GO TO BED | OK | Lie down, beginning of the sleep period, this may serve as start of sleep marker for MiFit
0x1c | GET UP 1 | OK | Get up from sleep mostly
0x21 | WALK UP | OK | Indicates end of measured walk activity, walking up stairs according to #1030
0x22 | RUN 2, UP | OK | Running, either up or on start of the run from walk? Seems to differ on Amazfit BIP and Miband2.
0x31 | WALK 3, DOWN | OK | Walking, often downwards
0x32 | RUN 3, DOWN | OK | Either running downwards, or run end, slowing to walk (downgrade to walk)? Seems to differ on Amazfit BIP and Miband2
0x42 | RUN 4 | OK | Seen during the run
0x51 | WALK 5 | OK | Guess: Walking without significant hand movements, hands horizontal
0x52 | RUN 5 | OK | Run type
0x53 | NOT WORN 5 | OK | Watch not worn, possibly lying face up
0x5c | GET UP SIT | OK | Get up
0x62 | RUN 6 | OK | Guess: Running without significant hand movements, hands vertical
0x63 | NOT WORN 6 | OK | Watch not worn, possibly lying on side
0x6c | GET UP 6 | OK | Unknown, interruption of sleep/sit/stand phase
0x73 | NOT WORN 7 | OK | Watch not worn, deep sleep
0x7c | GET UP SLP | OK | Get up
0x41 | UNKNOWN | OK? | Some kind of walk, probably.
0x13 | UNKNOWN | unknown | Probably another not worn indication, but during walk phase, band was in bag at that time (?)
### These seem to be sometimes interpreted differently from official application, e.g. sleeping instead of sitting.
RAW a. type | Activity description | GB processing status | Comment
-- | -- | -- | --
0x79 | SLP MOVE 9 | Partially supported | Movements in sleep, serie of them may indicate a wake up and just lying in the bed, or leave deep sleep to light sleep if RAW data is present
0x5a | SIT MOVE a | Partially supported | Normal sitting with borderline raw value of 20, light sleep in sleep mode
0x59 | SIT MOVE 9 | Partially, detected only as L.S. | Movements in sitting, but also in sleep, if in sleep mode, serie of them may indicate a wake up and just lying in the bed, or leave deep sleep to light sleep if RAW data is present
0x10 | SLOW WALK | Previous activity kept | Slow walk or light activity (no steps may be logged)
0x50 | SIT | Previous activity kept | Sitting at computer, driving, transportation, eating, sometimes sleeping
0x60 | STAND | Previous activity kept | Standing, sometimes sleeping (during sleep period)
0x70 | SLEEP | Previous activity kept | standard sleep, also when Miband2 was not worn for long time periods
0x1a | BACK TO BED | IGNORED | Return to bed during active period before another sleep starts
0x6a | STAND ACT. | IGNORED | Normal standing with borderline raw value of 20, not observed in light or deep sleep mode
## These seem to be wrongly interpreted at any time
RAW a. type | Activity description | GB processing status | Comment
-- | -- | -- | --
0x5b | SIT MOVE b | WRONG, D.S. | Sitting down in last 10 minutes, reinterpret SLEEP/STAND indication in this time frame. Mifit does not interpret this as sleeping, but actually may be part of sleep period
0x6b | UNKNOWN | WRONG, D.S. | Not sleeping, something with standing?
0x69 | STAND UP | WRONG, L.S. | Seems to be bound to standing from sitting position or sleep. Breaks sleep
0x7a | SLP MOVE a | IGNORED | Prevent deep sleep indication at this time, goes back to light sleep from deep sleep in MiFit, but may go to deep sleep immediately after
0x7b | SLP MOVE b | WRONG, D.S. | Sleep in last 10 minutes, reinterpret SIT/STAND indication in this time frame
Of course it is just data from a single person, so some interpretation may be incorrect.
I can provide the raw data in sqlite database or odt table if needed.
I have been holding out on this version, because it is the last version with working sleep detection.
Now, my miband2 is discharge within a day + occasionally time is wrong. Sounds like a hardware fault -- but I wonder if updating the firmware will help?
Is 1.0.1.81 really the latest fw for miband2? If there is something newer, does it help with accurate sleep detection? I am afraid of upgrading and downgrading firmware... probably not too safe.
Is this problem present in miband3 as well?
gadgetbridge version: latest
miband2 fw version: 1.0.1.34
I have been holding out on this version, because it is the last version with working sleep detection.
Now, my miband2 is discharge within a day + occasionally time is wrong. Sounds like a hardware fault -- but I wonder if updating the firmware will help?
Miband2 firmware page: https://github.com/Freeyourgadget/Gadgetbridge/wiki/Mi-Band-2-Firmware-Update shows 1.0.1.81 as the latest released with MiFit 3.3.1. Apkmirror shows that was in March 2018: https://www.apkmirror.com/uploads/page/2/?q=mi-fit
Latest MiFit release listed on apkmirror is 3.5.1.2: https://www.apkmirror.com/uploads/?q=mi-fit
Is 1.0.1.81 really the latest fw for miband2? If there is something newer, does it help with accurate sleep detection? I am afraid of upgrading and downgrading firmware... probably not too safe.
Is this problem present in miband3 as well?
I have also been looking into this. Here is a single night + day data from Amazfit Bip 1.1.5.56, Gb 0.36.2 , with marked data as per information from GDPR export and the original app.
When observing the data, the only unclear segment for me is marked with "light activity???".
Total sleep: 06:43 , deep sleep 01:36 , light sleep 05:07 , slept from 2019-10-01 23:12:00 until 2019-10-02 05:55:00
@pm-cz@vanous Thanks for the logs and explanation. Would you help me get real time continuous heart rate info just like you did with the raw_kind values? Which steps do we need to follow? I could not find the code for MiBand2&3 inside this library. I found some info about sending x15x01x01 to hrm_ctrl characteristic and then pinging every 12 seconds. Can somebody at least point me to the right direction? Thanks.
@pm-cz @vanous Thanks for the logs and explanation. Would you help me get real time continuous heart rate info just like you did with the raw_kind values? Which steps do we need to follow? I could not find the code for MiBand2&3 inside this library. I found some info about sending x15x01x01 to hrm_ctrl characteristic and then pinging every 12 seconds. Can somebody at least point me to the right direction? Thanks.
@pm-cz@vanous Thanks for the logs and explanation. Would you help me get real time continuous heart rate info just like you did with the raw_kind values? Which steps do we need to follow? I could not find the code for MiBand2&3 inside this library. I found some info about sending x15x01x01 to hrm_ctrl characteristic and then pinging every 12 seconds. Can somebody at least point me to the right direction? Thanks.
> @pm-cz @vanous Thanks for the logs and explanation. Would you help me get real time continuous heart rate info just like you did with the raw_kind values? Which steps do we need to follow? I could not find the code for MiBand2&3 inside this library. I found some info about sending x15x01x01 to hrm_ctrl characteristic and then pinging every 12 seconds. Can somebody at least point me to the right direction? Thanks.
https://github.com/Freeyourgadget/Gadgetbridge/issues/1499#issuecomment-548312938
ashimokawa
changed title from miband2 raw_kind infos to Huami raw_kind research1 year ago
From my AMAZFIT Bip I have deduced the following activity types
Running = 98, 50, 66, 82
Charging = 6
Walking = 1, 16, 17, 33, 49, 18, 34, 65
Light_Sleep = 112
Heavy_Sleep = 122
I also count 20 min of light sleep with raw_intensity =< 12 all following minutes as Heavy
Sit = 80, 96, 99
NotWorn_FaceUp = 83
NotWorn_FaceDown = 115
NotWorn = 3
NotWorn_Charging = 6
Standing = 96
SedentaryInLast5Minutes = 90
This is abit vague and requires some more testing to confirm without a doubt. Until then remains under walking.
StairClimbing = 33
Hope this helps
Hi All,
From my AMAZFIT Bip I have deduced the following activity types
Running = 98, 50, 66, 82
Charging = 6
Walking = 1, 16, 17, 33, 49, 18, 34, 65
Light_Sleep = 112
Heavy_Sleep = 122
I also count 20 min of light sleep with raw_intensity =< 12 all following minutes as Heavy
Sit = 80, 96, 99
NotWorn_FaceUp = 83
NotWorn_FaceDown = 115
NotWorn = 3
NotWorn_Charging = 6
Standing = 96
SedentaryInLast5Minutes = 90
***********
This is abit vague and requires some more testing to confirm without a doubt. Until then remains under walking.
StairClimbing = 33
Hope this helps
The post above is not very easy to read so here is take 2
Running = 98, 50, 66, 82
Walking = 1, 16, 17, 33, 49, 18, 34, 65
Light_Sleep = 112
Heavy_Sleep = 122, I also count 20 min of light sleep with raw_intensity =< 12 all following minutes as Heavy Sleep
Sit = 80, 96, 99
Standing = 96
SedentaryInLast5Minutes = 90
NotWorn = 3
NotWorn_Charging = 6
NotWorn_FaceUp = 83
NotWorn_FaceDown = 115
33 is intersting cause it sometimes acts correctly with climbing stairs and sometimes not.
Left in walking either way intil tested some more
The post above is not very easy to read so here is take 2
* Running = 98, 50, 66, 82
* Walking = 1, 16, 17, 33, 49, 18, 34, 65
* Light_Sleep = 112
* Heavy_Sleep = 122, I also count 20 min of light sleep with raw_intensity =< 12 all following minutes as Heavy Sleep
* Sit = 80, 96, 99
* Standing = 96
* SedentaryInLast5Minutes = 90
* NotWorn = 3
* NotWorn_Charging = 6
* NotWorn_FaceUp = 83
* NotWorn_FaceDown = 115
33 is intersting cause it sometimes acts correctly with climbing stairs and sometimes not.
Left in walking either way intil tested some more
First of all thanks for all your work. I have been wanting to buy an activity tracker for quite some time, but held off because of obvious concerns. The same week I discovered this app, I ordered an amazfit 5.
I'm liking it, but the imperfect sleep tracking (nearly no deep sleep) is what stood out the most to me. I haven't gotten to processing my own data yet (don't know how similar the amazfit 5 is to others mentioned above), but I figured I'd visualize the data posted above by @vanous in hopes of getting this a little further. The orange-and-red-bar is the mifit-download data, the two bars above each represent a value of a nibble from the activity-byte. The screenshot also includes the lookup-table provided by @pm-cz for easy lookup-reference.
Things that I can make up:
The fine narrow purple line indicating confirmed sleep
The fine brown line indicating confirmed wake-up
As already suggested above, the intensity (low enough for a while) seems the main factor in determining deep sleep.
Could someone (ping @ashimokawa@vanous) provide some info on the actual status of this issue? In the future I'd like to help out with integrating other things such as spo2 as well.
First of all thanks for all your work. I have been wanting to buy an activity tracker for quite some time, but held off because of obvious concerns. The same week I discovered this app, I ordered an amazfit 5.
I'm liking it, but the imperfect sleep tracking (nearly no deep sleep) is what stood out the most to me. I haven't gotten to processing my own data yet (don't know how similar the amazfit 5 is to others mentioned above), but I figured I'd visualize the data posted above by @vanous in hopes of getting this a little further. The orange-and-red-bar is the mifit-download data, the two bars above each represent a value of a nibble from the activity-byte. The screenshot also includes the lookup-table provided by @pm-cz for easy lookup-reference.
Things that I can make up:
- The fine narrow purple line indicating confirmed sleep
- The fine brown line indicating confirmed wake-up
- As already suggested above, the intensity (low enough for a while) seems the main factor in determining deep sleep.
Could someone (ping @ashimokawa @vanous) provide some info on the actual status of this issue? In the future I'd like to help out with integrating other things such as spo2 as well.
I didn't seem to find the code 208 and 219 is this thread, but they seem to indicate the start of sleep. However this is not always the case.
While using night-time monitoring
Person 1
TIMESTAMP
DEVICE_ID
USER_ID
RAW_INTENSITY
STEPS
RAW_KIND
HEART_RATE
day 0 00:43:00
1
1
10
0
80
255
day 0 00:44:00
1
1
0
0
80
255
day 0 00:45:00
1
1
0
0
208
255
day 0 00:46:00
1
1
0
0
80
255
day 0 00:47:00
1
1
6
0
80
55
day 0 00:48:00
1
1
39
0
208
255
day 0 00:49:00
1
1
37
0
217
255
day 0 00:50:00
1
1
6
0
89
255
day 0 01:04:00
1
1
0
0
80
255
day 0 01:05:00
1
1
0
0
80
255
day 0 01:06:00
1
1
0
0
208
255
day 0 01:07:00
1
1
0
0
208
55
day 0 01:08:00
1
1
0
0
219
255
day 0 01:09:00
1
1
0
0
208
255
day 0 01:10:00
1
1
0
0
240
255
day 0 01:11:00
1
1
0
0
250
255
day 1 00:46:00
1
1
0
0
80
255
day 1 00:47:00
1
1
0
0
90
56
day 1 00:48:00
1
1
0
0
208
255
day 1 00:49:00
1
1
2
0
208
255
day 1 00:50:00
1
1
0
0
219
255
day 1 00:51:00
1
1
0
0
208
255
day 1 00:52:00
1
1
0
0
240
57
day 1 00:53:00
1
1
0
0
250
255
day 2 00:19:00
1
1
0
0
80
255
day 2 00:20:00
1
1
0
0
80
255
day 2 00:21:00
1
1
0
0
208
255
day 2 00:22:00
1
1
0
0
208
255
day 2 00:23:00
1
1
0
0
219
54
day 2 00:24:00
1
1
10
0
208
255
day 2 00:25:00
1
1
0
0
240
255
day 2 00:26:00
1
1
0
0
240
255
day 2 23:56:00
1
1
0
0
80
255
day 2 23:57:00
1
1
0
0
80
255
day 2 23:58:00
1
1
0
0
208
59
day 2 23:59:00
1
1
0
0
208
255
day 3 00:00:00
1
1
0
0
219
255
day 3 00:01:00
1
1
0
0
208
255
day 3 00:02:00
1
1
0
0
240
255
day 3 00:03:00
1
1
0
0
240
61
day 4 00:03:00
1
1
0
0
80
55
day 4 00:04:00
1
1
0
0
80
255
day 4 00:05:00
1
1
0
0
208
255
day 4 00:06:00
1
1
0
0
208
255
day 4 00:07:00
1
1
0
0
219
255
day 4 00:08:00
1
1
0
0
208
55
day 4 00:09:00
1
1
0
0
240
255
day 4 00:10:00
1
1
0
0
240
255
day 5 00:34:00
1
1
0
0
90
255
day 5 00:35:00
1
1
0
0
218
255
day 5 00:36:00
1
1
0
0
208
255
day 5 00:37:00
1
1
0
0
219
255
day 5 00:38:00
1
1
0
0
208
68
day 5 00:39:00
1
1
0
0
240
255
day 5 00:40:00
1
1
0
0
240
255
day 6 00:57:00
1
1
0
0
80
255
day 6 00:58:00
1
1
0
0
80
56
day 6 00:59:00
1
1
0
0
208
255
day 6 01:00:00
1
1
0
0
208
255
day 6 01:01:00
1
1
0
0
219
255
day 6 01:02:00
1
1
0
0
208
255
day 6 01:03:00
1
1
0
0
240
48
day 6 01:04:00
1
1
0
0
240
255
person 2
TIMESTAMP
DEVICE_ID
USER_ID
RAW_INTENSITY
STEPS
RAW_KIND
HEART_RATE
01:53:00
1
1
0
0
80
255
01:54:00
1
1
0
0
80
255
01:55:00
1
1
0
0
208
255
01:56:00
1
1
0
0
208
62
01:57:00
1
1
0
0
219
255
01:58:00
1
1
0
0
208
64
01:59:00
1
1
0
0
240
63
02:00:00
1
1
0
0
240
63
Here the mi band 5 started monitoring every minute after code 219
Before opening an issue please confirm the following:
Your issue is:
I export data from GB database. I look on RAW_KIND column, there is a lot of values:
According source code, there is some known values:
What about other values ? Do we have any ideas ?
Best regards.
Your wearable device is: Miband2
Your android version is: 7
Your Gadgetbridge version is: 0.19.1
No, we have no idea. Also, the values have changed in recent firmware versions (see #650), so the above values (at least regarding sleep) are not used anymore.
What I notice on my data (3 days basis):
Great analysis! Which firmware version did you use for this?
BTW, it might be that you looked at the wrong source file for the constants. See
MiBand2SampleProvider
, which partially matches your own findings.I use 1.0.1.39 version. Last 1.0.1.50 introduces some new values according to #650. I'm going to upgrade and compare values from old version.
raw_kind from 1.0.1.50 differs totally from previous version. It's really hard to determine activity kind:
I'm going to complete this list in a few days. I will have more data. Hope it will be easier to determine activity kind.
Just chiming in to say that if some values are reported one minute before running/walking/doing any activity, it means that some postprocessing is happening on the device as well now.
Yeah, I think they try to detect begin of activities; running, walking, sleeping, etc.
Here is values from 4 activities.
Walking
Running
Sleeping
Immobile/Siting
Sometimes some relations might be more apparent when viewing the byte values in base 2 (bits) instead of numbers in base 10 (I didn't do any conversion in this specific case, just speaking out of experience)
Does GB manage activity values with different firmware version ? We can ask users to upgrade to last firmware version.
Hey! i would like to revive this issue!
First question: Is Gadgetbridge able to interpret Data according to Firmware version? I guess it would be nice if Gadgetbridge marks every data it pulls, with the version the Mi Band 2 was running at that time. So data can also be retrospectively interpreted correctly by Gadgetbridge.
I would be interested if soembody did some additional research or tried to implement something. I can not program, but if needed I could try to analyse my data, to see what means what.
So does Gadgetbridge dump all data? Also data it doesn't know? Is this then the "RAW_KIND" column?
Thanks!
Hi,
AFAIK, GadgetBridge does only fetch data from Mi Band. It retrieves RAW_KIND and something like intensity, heart rate and steps. Data are stored as is. I think Mi Band determines RAW_KIND from intensity and steps.
Marking all data will encount a large overhead with no added value. We only need upgrade datetime or current firmware version when fetching.
You can follow Wiki guide to export your data and try to determine all raw_kind data. We will be able to compare our results and match id from Mi Band.
Well, about the firmware version. Gadgetbridge actually records that already in DEVICE_ATTRIBUTES.(timestamps from and until which version was used). So thats good.
How can I make a real time from the timestamps? Knowing when something happened might be the first start to understand the data :D
I have numbers like that: 1501625460
EDIT: i was digging through the Mi Fit app and found a setting called "pattern recognition" ("Verhaltenserkennung"). There it lets you choose something eg. Sit ups. When you select it, it asks you to do sit ups, and does a continues recording of your heart rate and movements. Then you do them until you decide to stop your workout. Then it uploads something. Now my question: Does this upload some data to the band in order to improve its recognition, or does it only upload this somewhere else and then does the processing in the app?
If this indeed uploads something to the band, maybe that could be a lot of the unknown codes? Maybe it assigns different codes to actions you can improve via the app?
Here is the bluetooth log of this:
btsnoop_hci.log.txt
I don't see if it uploaded some info to the band or not, the only thing I can see in there is the continuous stream of data from the band to the phone while recording the behavior.
Maybe we also should split this up and first concentrate and restoring the sleep tracking?
My question regarding the timestamps still stands, as i cant really correlate the database entries to what I did at the moment.
New post for MiBand 2 not being worn, just lying on a table:

This dump is 0% movement. I did not touch the band or the table.
The HR sensor switches on every 2 minutes and tries to measure.
New post for Miband 2 at the arm; Arm as still as possible on the table for 20 minutes... (imitating deep sleep i guess?)

Ok. So I set 112 as light sleep and get 4:21 light sleep, vs. 4:36 in the Mi Fit app. Doesnt seem to bad. I had a nap today, could be that this maybe is missing in Gadgetbridge.
112 with intensity of 0 means not wearing. I guess 112 intensity >0 means light sleep. I am not able to programm this, but my build system is running and I would be willing to test.
I set 122 as deep sleep and get 18 minutes (vs 41min in Mi Fit), so somethings off there, but it looks as if it is in the right places.
How can I set multiple types for an activity? Obviously we want to keep the old values in and add the new ones to it.
Some values identify sleep start and sleep end. It apparently corresponds to 28, 105, 106 and 123. Do you get these values ? Are they better matching with official app?
Does official app detect REM period ? Is there some raw kind values related ?
Best regards.
Actually quite interesting.
I think 28 indicates waking + standing up. So you get active and also walk. (Steps are counted + higher raw intensity).
105 means waking up but staying in bed (no steps but high raw intensity).
106 is something very rare for me. Not quite sure about it.
123 always appears after 2-5 112s (light sleep), so that seems to be a approval of start of sleep.
The official app detects Light/deep sleep (I guess equals REM/NREM?) and times of waking up in the night.
To further test this, somebody would need to integrate a function of counting sleep from 123 until 28 or 105. I could build this myself and try to see how it fits to MiFit results.
Unfortunately I do not have access to my MiBand charger right now(and I am at 7%). I will have access again from 21. August, so that's when I will be able to test again.
@ashimokawa
I saw that you added the Amazfit Bip, which you write in the wiki is similar to the MiBand 2.
How is sleep tracking working for it? Are there parallels concerning the new firmwares for the Mi band 2?
@Roxxor91
Sleep tracking seems to work with the Bip.
This thread is indeed interesting (first time I read it since I never had a Mi 2), and I have to look at the raw values that come from the Bip. I will report back when I did.
Thanks for the work
I tried to figure it out as well for my Nextcloud visualization, which worked with 1.0.1.39 before: https://github.com/nickv-nextcloud/gadgetbridge
As mentioned before, it seems like Xiaomi uses some types to start/stop sleep counting.
I am unfortunately not a programmer and cant integrate it into the code to test it.
Maybe somebody could try? I would definitely test and compare to MiFit!
Details see my post from 11. August.
I think we have to pull request new raw_kind association based on our analyze.
@Vebryn
Sure if you have any idea how to fix this go ahead. Honestly I have none.
For me sleep is also totally broken on Bip with firmware 0.0.8.74
I get raw kind 96 most of the time during sleep but also often 99 for some time and sporadically 105-108.
EDIT: the night before that I had mostly 80 or 90 as rawKind.
This does not fit in what you posted so far.
I think, honestly, this is completely impossible to fix without iterating over all data and do some post-processing and have a new column for a "reconstructed" activity type.
@ashimokawa
I actually think we are quite close. We just need to assign new numbers to the activities. But in order to do that, I would need to know how to add multiple numbers to one activity kind; eg. 9 AND 112 mean light sleep.
With my tests i was able to get quite close results to the MiFit app. But I replaced the numbers form the old firmwares and in result old firmware data was not interpreted correctly.
As a second step we could try to add a from -> to counter (fall asleep -> wake up) to mark obtain sleep time.
@Roxxor91
Okay, maybe it can be fixed for a Mi Band 2, for the Bip current code worked well with the initial firmware but for the latest I am really out of ideas.
I just checked what happens when I assign 80 and 90 as sleep - but when I do that I am also asleep at work. and while walking and - well half of the day, even at high intensity.
In fact I cannot even see what the difference between sleeping and working is except that there is less intensity while sleeping ;)
But maybe Mi Band 2 stuff can be fixed by improving the postprocessing we already do, for the Bip at least I am waiting for a new firmware.
Unfortunately I cannot test myself with a Mi Band 2 because I have none.
Here is the patch for sleep tracking for MiBand 2 new firmwares:
https://gist.github.com/Roxxor91/0d3ff17153270e447d01e7afd0c54e0f
With the nice help of "LjL-Alplet" from IRC, who told me how to get multiple activity definitions into the file.
I am to stupid to make a pull request. Somebody please do that for me.
EDIT:
@ashimokawa
As you were talking about intensity... Can we get that into interpretation somehow?
112 with intensity =0 means not worn.
112 with intensity >0 means light sleep.
@Roxxor91
As expected for the Bip this does not help.
About your question:
add this at the end of the for loop in postprocess(), after line 104 in your file as posted in your gist
@Roxxor91 if you are not too frustrated with github you can try the following:
the lines marked as :octocat: are performed on the github web interface, others happen on your PC.
There are faster ways and shortcuts all around, but the procedure above should work no matter what.
Hope this helps!
Yai! Thanks, I did it!
EDIT: By the way, I now figured out how to convert the timestamps to a real time and was able to correlate precisely now.
I think I understood most of it, but it will need some processing. (a lot of "if" arguments incoming, even though I wont be able to write them :D) I will make a new post for the explanation.
So when you are inactive, you are given the value "81".
If the value "81" is with a raw intensity of <3 for ten times, this triggers 91. -> You fell asleep.
-> Those 10x 81 are then interpreted as Light sleep (as those values cant be changed anymore, but mean that you were sleeping at that point) -> So a 91 basically means: You had light sleep the 10 minutes before.
From this point on everything is recorded as 112. Now we are in a deep sleep phase. Why? Because from here I had only 112s with raw intensity of 0! I figured out the threshold: If you have 8 times (or 8 minutes) 112s with 0 intensity, you are now in deep sleep. (we start counting deepslep from the 8th 112 with 0 intensity)
So when do I switch back to light sleep? Easy! We have a 112 with increased intensity! For me the lowest value was intensity 6 to wake up. So lets asume intensity >5 112 means you switched from deep, to light sleep.
I was ripped of my nice sleep by having to lock the door after somebody. As we already know, my waking up + walking meant i received a 28 for waking up.
If something is unclear, please comment.
I have some questions.
So I try to summarize:
Correct
correct
You correctly calculated what MiFit was showing me. This happened because directly after it, I was sleeping with 0 movement. Also in this it started counting deep sleep from the first 112. I think this happened because it redefined the 10x 81(normally meaning inactivity, not sleep) as 10x 112 with 0 intensity, so criteria for deep sleep were met.
As far as I can see there is not, so correct.
112 with intensity doesnt mean I woke up! We are in deep sleep with 112 intensity 0, now when we get 112 intensity >5, that means that i am moving more in my sleep, saying that i am now in light sleep!
When i woke up, it is whether 28 (I got up, so the band measures my high activity and steps) or 105 (so i am doing stuff in bed, similar like sitting inactive, but as I am on my computer, my wrist movements are really intense, meaning I am certainly not sleeping anymore, but there are no steps!).
After that "he is awake again", inactivity gets coded as 81 again.
28 and 105 are not depended on your activity before, but just that you were in "general sleep mode" before, but now you are so active that you are definitely not sleeping anymore, so we leave "sleep mode" for "day" mode.
Yes
Yes
Yes
Yes
No, rather: type 112 with intensity >5: "deep sleep ended"
Let's say: type 28 and 105: "woke up"
EDIT:
So this then also means that the approach changes quite drastically. We have to switch from a total sum to intervals which have to be recognized. I am ready to help with interpretation and testing. But I definitely cant write the code for it...
@danielegobbetti @ashimokawa @Vebryn
So just that everybody knows how I do this analysis, here is my file which I created to analyze the data.
sleep interpretation.xlsx
(File created with LibreOffice Calc, but Github doesn't allow uploading .ods files...)
EDIT: And here is tonight:
night 2.xlsx
Mostly the same, but something new I figured: Deep sleep was continuing at one point even though there was a 112 with intensity of 15. So not ANY intensity interrupts deep sleep, but there is some specific level.
I think we need to see bits at rear site. 112 is 0111 0000 and 80 is 0101 0000. these numbers mean nothing i think.
Use bitwise operation!!
Basic of my data,
I found sleep must be finished before 12 when i use "rawkind&0x0f". This is the end point of sleep.
9 is light sleep and 11 is actually deep sleep.
etc.
When I don't wear it, type 112 always appeared.
I also don't know the relationship between intensity and sleep but when sleep stage is deep sleep and intensity are high(maybe over 20?), it's going to light sleep.
Could you please elaborate on the bitwise operation? What is it, how does it help, how can I use it?
About 112: I analyzed and explained how I think sleep is determined. Concerning "not wearing": I think it only differs from sleep, as it is not able to measure heart rate (every second minute) and intensity is always 0.
@Roxxor91
With a bitwise and unimportant bits can be "thrown away" value & 0xf will thow everything away except the least significant four bits (0xf = 0b1111)
you can use it like this:
rawKind = rawKind & 0xf;
@kizer93
Indeed the "new values" seem to come from extra bits being set.
Unfortunately just ignoring them leads to wrong sleep detection and wrong "non worn" detection.
We must find out what these flags are.
@ashimokawa
Yeah I know. It won't be anything. However, When light sleep was going, rawkind are 80 and 122. That's why I'm confused between these data.
Pushed fixes to master
9f05aff11b
I took the time and did some tests myself. It really seems that & 0xf will get the old values.
There was a longstanding unrelated bug that always jeopardized my tests, that is why it took so long.
I can confirm that values 11 and 12 also appeared on old firmware - in newer they just have the extra bits.
So there is nothing new except the flags, and masking these out needed some code adjustments.
What is missing
In any case I am quite confident that this change brings the newer firmwares on par with the old ones, and the change I did does not affect old firmwares.
Gadgetbridge 0.21.4 has been tagged and will include the change mentioned above. 0.21.3 which has been build and published by F-Droid today does not contain the fix.
I did not communicate it here yet but it seems that later Mi Band 2 firmwares (>1.0.1.39) and Bip firmwares >= 0.0.8.xx do not have working deep sleep detection.
When I go to bed usually the time before I really fall asleep is marked as deep sleep, the rest as light sleep. It seems we have to do more postprocessing on the data.
What would really help if someone could tell what mifit detected (intervals) plus the raw values from the Gadgetbridge database for the same night.
My post from 1. September includes everything you asked for.
@Roxxor91
Thank you for reminding me. Downloaded. Will have a closer look around the weekend.
@ashimokawa
Any news on this one?
Excuse me does anybody experience this problem on Mi Band 2 on FW 1.0.1.69 too?
@Micky007 yes, this occurs on 1.0.1.69 as well
I tried to change raw_kind value in MiBand2SampleProvider
But not work for me
The sleep chart nothing visible
my mi band 2 fw : 1.0.1.81
Hello,
I have gathered over 20 days of Amazfit BIP and Miband2 data extracted from BTsnoop logs and try to interpret when they happen. I used/confirmed some information from #1030, but in general I tried to look at the data compared to reality.
The firmware versions are 0.1.1.36 for BIP and 1.0.1.81 for Miband2, and I have to agree that deep sleep data (and sometimes light sleep data) is interpreted incorrectly. Without upper 4-bit nibble, the
rawKind
information is incomplete and cannot be interpreted fully.The deep sleep is however hard to pick as it often starts without any visible specific flag in official application, so @Roxxor91 interpretation of several minutes of sleep with low/zero raw activity starting deep sleep may be right. But it looks like deep sleep is detected as a block of sleeps with at least 10 continuous 0x00 raw values, an occasional 0x70 and 0x79 with raw data bellow 0x20 does not seem to leave it.
I am seem not able to add the full table here so I will include it as an image attachment:

As a result, sometimes the sitting periods are interpreted as sleep and not all sleep intervals are recorded. I tried to add my own interpretations of raw activity types in following tables:
These seem to be correct in GadgetBridge
These seem to be sometimes interpreted differently from official application, e.g. sleeping instead of sitting.
These seem to be wrongly interpreted at any time
Of course it is just data from a single person, so some interpretation may be incorrect.
I can provide the raw data in sqlite database or odt table if needed.
gadgetbridge version: latest
miband2 fw version: 1.0.1.34
I have been holding out on this version, because it is the last version with working sleep detection.
Now, my miband2 is discharge within a day + occasionally time is wrong. Sounds like a hardware fault -- but I wonder if updating the firmware will help?
Miband2 firmware page: https://github.com/Freeyourgadget/Gadgetbridge/wiki/Mi-Band-2-Firmware-Update shows 1.0.1.81 as the latest released with MiFit 3.3.1. Apkmirror shows that was in March 2018: https://www.apkmirror.com/uploads/page/2/?q=mi-fit
Latest MiFit release listed on apkmirror is 3.5.1.2: https://www.apkmirror.com/uploads/?q=mi-fit
Is 1.0.1.81 really the latest fw for miband2? If there is something newer, does it help with accurate sleep detection? I am afraid of upgrading and downgrading firmware... probably not too safe.
Is this problem present in miband3 as well?
@pm-cz has there been any progress on your effort of deep sleep recognition? (your data would seem comprehensible at a first glance)
I have also been looking into this. Here is a single night + day data from Amazfit Bip 1.1.5.56, Gb 0.36.2 , with marked data as per information from GDPR export and the original app.
When observing the data, the only unclear segment for me is marked with "light activity???".
Total sleep: 06:43 , deep sleep 01:36 , light sleep 05:07 , slept from 2019-10-01 23:12:00 until 2019-10-02 05:55:00
23:12 - 23:30 light sleep
23:31 - 23:40 deep sleep
23:41 - 23:50 light sleep
23:51 - 00:03 deep sleep
00:04 - 01:13 light sleep
01:14 - 01:33 deep sleep
01:34 - 02:02 light sleep
02:03 - 02:15 deep sleep
02:16 - 02:26 light sleep
02:27 - 02:39 deep sleep
02:40 - 03:55 light sleep
03:56 - 04:08 deep sleep
04:09 - 04:18 light sleep
04:19 - 04:32 deep sleep
04:33 - 05:54 light sleep
Total steps: 13156 , used 430 kcals , walked 10390 meters
06:12 - 06:38 184 steps light activity
08:23 - 08:28 326 steps slow walking
12:31 - 12:35 140 steps slow walking
13:05 - 13:40 3723 steps fast walking
16:10 - 16:15 549 steps slow walking
16:16 - 16:42 2791 steps fast walking
17:30 - 17:37 426 steps slow walking
17:52 - 18:16 530 steps light activity
18:17 - 18:27 1331 steps fast walking
19:19 - 19:27 1438 steps running
Gb database data is 1h shifted to the above.
@pm-cz @vanous Thanks for the logs and explanation. Would you help me get real time continuous heart rate info just like you did with the raw_kind values? Which steps do we need to follow? I could not find the code for MiBand2&3 inside this library. I found some info about sending x15x01x01 to hrm_ctrl characteristic and then pinging every 12 seconds. Can somebody at least point me to the right direction? Thanks.
https://github.com/Freeyourgadget/Gadgetbridge/issues/1499#issuecomment-548312938
miband2 raw_kind infosto Huami raw_kind research 1 year agoHi All,
From my AMAZFIT Bip I have deduced the following activity types
Running = 98, 50, 66, 82
Charging = 6
Walking = 1, 16, 17, 33, 49, 18, 34, 65
Light_Sleep = 112
Heavy_Sleep = 122
I also count 20 min of light sleep with raw_intensity =< 12 all following minutes as Heavy
Sit = 80, 96, 99
NotWorn_FaceUp = 83
NotWorn_FaceDown = 115
NotWorn = 3
NotWorn_Charging = 6
Standing = 96
SedentaryInLast5Minutes = 90
This is abit vague and requires some more testing to confirm without a doubt. Until then remains under walking.
StairClimbing = 33
Hope this helps
The post above is not very easy to read so here is take 2
33 is intersting cause it sometimes acts correctly with climbing stairs and sometimes not.
Left in walking either way intil tested some more
First of all thanks for all your work. I have been wanting to buy an activity tracker for quite some time, but held off because of obvious concerns. The same week I discovered this app, I ordered an amazfit 5.
I'm liking it, but the imperfect sleep tracking (nearly no deep sleep) is what stood out the most to me. I haven't gotten to processing my own data yet (don't know how similar the amazfit 5 is to others mentioned above), but I figured I'd visualize the data posted above by @vanous in hopes of getting this a little further. The orange-and-red-bar is the mifit-download data, the two bars above each represent a value of a nibble from the activity-byte. The screenshot also includes the lookup-table provided by @pm-cz for easy lookup-reference.
Things that I can make up:
Could someone (ping @ashimokawa @vanous) provide some info on the actual status of this issue? In the future I'd like to help out with integrating other things such as spo2 as well.
Hi,
I didn't seem to find the code
208
and219
is this thread, but they seem to indicate the start of sleep. However this is not always the case.While using night-time monitoring
Person 1
person 2
Here the mi band 5 started monitoring every minute after code
219
@beardhatcode