Search results for:

Ah, that is what I call a really impressive reaction time: -7h ;-)
Thanks
And sorry for the wrong attribution. Thanks for the app!
(Test needs to wait until tomorrow)

same here

update: After leaving with long press I got
"Uncaught Error: Unhandled promise rejection: InternalError: BLE task completed that wasn't
scheduled (SERVICE/NONE)" in IDE
(don't know if that is realated)

@Gordon: Got the bthrm update from dev app store today.
Like very much what I see in the changelog (especially RR).
Unfortunatly somehow 0.05 broke the app for me. No more connection to polar H10.
After going back to 0.04 connection is back again.

We are looking for 95-98% of a good step counter. 20% is far too inaccurate

Yes of course. That interval was meant to exclude degenerate cases. Just means something like "we can assume Fitbit/Mi not worse than 20%".

This is where the bulk of our thinking needs to go.

Yes, I am very aware of that.
I also did record some of those already (eg see attached one that I do think will be pretty challenging from a cahier. Here we do have regular patterns that might look very much like steps when the hand moves goods over the scanner)
But thats exactly the point: to seperate those phases with and without steps in real life situations. That is almost impossible if alternating relative rapidly (as opposed to car driving /sleeping). With the development tool of ankle measure, those could be determined I hope (eg. for cashier I wouldn't expect any correlation when moving goods, only when walking)
What I am up to is to generate a more relieable step signal for training purposes (each step, not only sum number).

I seem not to be able to express myself clearly - I am very sorry for that.
Lets continue that discussion after I can present some code here. That may clearify (or invalidate) my idea.
And please don't get me wrong: I am very impressed what you achieved already!
For my personal uscase its already more than good enough. I play with that not out of need but scientific curiosity. (I did work with acc in the past on quite challenging problems in my job).
On the other hand: when haveing more time I might concentrate on heart rate, that is more in need right now I think. Have no prior experince with PPG signals though.

b) real ground truth,

Hmm, I think the only truth would be that it was a bangle nearer the ground.

No, that is the idea of a) with the thesis that ankle is easier than wrist -which of cours is to bee seen and needs to be testet. I hope to see a much more robust outcome when varying parameters.

b) contains a bit of real ground truth! We have two acc input data streams a,b for which we know for sure that steps(a)-steps(b) =! 0. So even if we do not know the number of steps, we know that the bigger that difference is, the worse the algorithm "steps()" performs. No approximation here.
It is just a necessary, not a sufficient condition thought, so can not be used alone. E.g steps(x)=0 would be considered perfect but is completely useless obviously.
Still I think its a powerfull error measure, available with limited effort. If degenerate cases are excluded (eg. by demanding step count within +-20% of Mi/Fitbit or so) I would expect that to be a powerfull objective measure for guiding search.

Have you uploaded 4 separate logs, looks like 2 logs.

yes, should be 4 different logs: 2 walks with two devices each.
I see 4 attachments here, what do you see?

Do you have the step counts recorded by the Bangle as well?

No unfortunatly not. Will do this next time.
But the numbers in harness look reasonalby:
X_STEPS = 6, RAW_THRESHOLD = 14
File, Expected, Simulated, Diff, %, (Original)
210202a-Mi-walk1-b1-accellog2-Mi3=1609.c­sv, 1609, 1664, 55, 103.42 %, (1113)
210202a-Mi-walk1-b2-accellog2-Mi3=1609.c­sv, 1609, 1473, -136, 91.55 %, (1590)
210202b-Mi-walk2-b1-accellog5-Mi3=5593.c­sv, 5593, 5854, 261, 104.67 %, (2892)
210202b-Mi-walk2-b2-accellog5-Mi3=5593.c­sv, 5593, 5450, -143, 97.44 %, (5665)
TOTAL DIFFERENCE 331

X_STEPS = 6, RAW_THRESHOLD = 16
File, Expected, Simulated, Diff, %, (Original)
210202a-Mi-walk1-b1-accellog2-Mi3=1609.c­sv, 1609, 1645, 36, 102.24 %, (1113)
210202a-Mi-walk1-b2-accellog2-Mi3=1609.c­sv, 1609, 1423, -186, 88.44 %, (1590)
210202b-Mi-walk2-b1-accellog5-Mi3=5593.c­sv, 5593, 5835, 242, 104.33 %, (2892)
210202b-Mi-walk2-b2-accellog5-Mi3=5593.c­sv, 5593, 5383, -210, 96.25 %, (5665)
TOTAL DIFFERENCE 372

Just a quick manual test. Havent understood the auto search yet.

You see that bangle1 (ankle) is closer to Mi3 than bangle2 (wrist) - but its not as clear and stable as I would have expected

By the way: doing that experiment I found

• acc recorder menu is not working well on bangle1. On bangle2 one typically navigates the menu with touch and then stops with button. On bangle1 one typically navigates the menu with button and very often this start is immediatly recognised as stop.
  
• since download takes a while I didn't wait and later on mixed up the files first. So in addition to go from file number to date/time as filename as already discussed in some thread (for recorder app though, but thats equally valid for all recorders) one can think of inlcuding the 4hex name of the device also in the filename. That would make very clear what recording that is also after download.
  

We know extraction of steps from acc is difficult and best way to improve is test against a set of known results - as you did with stepcount.c
We also know that ground truth data is needed for that but difficult to come by (counting steps is cumbersome and other devices might not be reliable).

So what about the following idea (new or already discussed?): strap another bangle1/2 or puck at ankle.
That gives us
a) a file from wich step count should be extractable much more reliable since foot has much stronger and clearer pattern and much less distractions (other movements done with arm)
There could be a special ankle algorithm, but using the same one should work also I think especially if bangle2 for both would be used.
b) real ground truth, in that we know both recordings do have exactly the same step count (even if we do not know the count, we do have an error measure to minimize from the difference)

So far I have recorded two such pairs. Both times bangle2 (b2) at wrist and bangle1 (b1) over ankle. Additionaly I had a Mi3 band for comparison.
I have not done much analysis yet due to time limitations, but thought I post it here anyway in case anybody is interested to follow the idea or look into the files.

Looks to me something broke GPS?!
I also did test yesterday and didn't manage to get GPS anymore, despite agps download.
Wasn't a problem before.
Main things I changed: updated from 2v11 to 2v11.61 and installed Bluetooth HRM.

Did a short quick test for Accelamaze and 4:20 clock on bangle1.
Both seem to work fine :-)
Successfully did one 10x10 maze, and see time and text for the clock.

Ah good. I see the commit "significantly improved beat detection using peak finding and zero c…"
Thanks

@myownself

I have looked at a lot of papers. I remember one was a particularly good overview, I will see if I can dig it out again @Mi.

If you can find that, would be great.

also some of the more novel features we can extract.

What do you have in mind here?
While we must get the basics right first, it might make sense to incorperate in data collection already. I can measure and record SpO2, so do plan to record this for data sets also and see if it can be predicted from bangle2 data.

@johan_m_o: as far as I understood its about lat/lon distance calculation and just accidentaly the same factor as km/mi for our distance from equator.

@HughB: v0.03 really made the difference:
Phone 5,40km, Bangle 5.4km!! :-)
Also steps got much better with 2v11: Mi3-band (worn besides bangle) 8000, Bangle 7842. Thats about 2% differnce, wich is quite ok (and also all the error could come from Mi3, we dont't know)

Still heartrate is completely broken for me. As said I plan to dig deeper into this soon.
Is there already an recorder for raw data of the HR sensor? Otherwise I would need to start with this. Shouldn't bee too difficult with the accelerometer recorder as an example I hope.

Update: Typing the above text brought step counter to 8240.
So people: do particiapte in forms! - as good as any exercise ;-)

Thanks for the link, got 0.03.
And thanks a lot for your all your work @HughB. I am new to the community, but when I browse the forum, in a lot of the recent progress I see your name involved.

Short confirmation of already reported observations:
tested v0.02 on a longer walk yesterday and compared with app on phone.
phone 2.93km = bangle2 4.7km
phone 6.03 km = bangle2 9.7km
Thats both a factor of 0.62

HR was much too low definitively (39-45). My wife had plausible values on her bangle2.

How would I test v0.03? I see only v0.02 also in development app store. (not really important, can wait)

+1 for full date in filename

@Gordon:

Heart rate - ... we need to take a more scientific approach like was done with the step counter.

I plan to dig into this in the next weeks (as time allows). Will check what you did with step counter. First step I planned so far would be to record PolarH10 and bangle2 raw in sync in situations with increasing level of hand movement (rest, bike, running, ...) and for a spectrum of heart rates (and therfore also HRV from unregular to regular).
If anybody is working on this right now, or has good links to papers/proven code/ML models, I would be happy to hear about that. Will open a new thread when I really begin or have first results.

I do have the manufacturer's binary blob, so I may just give in and use that at some
point soon as I think more people care about having an accurate HRM than having an 'open' one!

I definitely care about the 'open', but you might be right about the majority. Would be great if you could keep the 'open' as an option at least.

For relative rotation you need to use gyro.
An absolute orientation can be calculated vertically (because you can measure the direction of gravitation force), but horizontally you turn around the direction of gravity so that force is of no use. Compass could be a solution but probably too unreliable.
But for your volume usecase relative should be good. So try to read gyro.
(Didn't use IMU on puck yet myself so cannot help with specific commands, but do have experience from other hardware)

And it seems that the WebIDE approach cannot be used if the watch does not start up properly anymore

Yes it can. :-) I was also in the situation shown in first picture above.
You need to release the button while the "=" move.
Have the WEBIDE prepared (navigate to update button via settings already (gear symbol upper right) and start update (dont take too long, there seems to be a timeout)
(Make sure that no other bluetooth device like your computer does interfere. Also make sure there is no coupling from android itself)

@avanc: I had using Chrome on ubuntu. Using Chrome on Android 11 it worked flawlessly then.

(sorry, didnt see the "dont have android" at first. Keep it here for reference in case others have same problem)

There was some discussion on kickstarter forum about that.
Try using WebIDE via chrome on an android phone. that seems to be most stable and reliable.
Worked for at least 3 people (that had the same issue on PC)

Yes the Nike is really nice.
I also like this that you (@Gordon) had on your early gallery:
https://hackaday.io/project/175577/galle­ry#9479be5ae92b13efad064e26f02f3f4a

I guess that is from the original manufacturers software - or is this already realized on bangle?