#686 Huami raw_kind research

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):

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

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:

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.

Yeah, I think they try to detect begin of activities; running, walking, sleeping, etc.

Here is values from 4 activities.

Walking

1
16
17
26 -> rare

Running

50 -> rare
66 - > rare
82 -> start/end
98

Sleeping

28 -> wake up
89
105 -> wake up
106 -> fall asleep
112 -> sleep, raw_intensity =0
121
122 -> sleep, raw_intensity =<20
123 -> fall asleep

Immobile/Siting

80
90
96
91 -> rare
99 -> rare

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

          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:

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 :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!

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.

• 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...

@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

• 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.

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

 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

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.