Huami raw_kind research #686
Open
opened 5 years ago by Vebryn
·
58 comments
No Milestone
No Assignees
7 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Freeyourgadget/Gadgetbridge#686
Loading…
Reference in new issue
There is no content yet.
Delete Branch '%!s(<nil>)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
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
9f05aff11bI 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
rawKindinformation 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 3 years 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
208and219is 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