Most recent activity
-
Hi all,
linking to this other thread, I had setup a repo for testing algorithms on Bangle JS. We currently have algos for step counting but it would make sense to add HR as well.
I have some student working on HR from PPG on mobile phones, but, if time allows, would like also to contribute to BangleJS.
The first thing to do would be to collect raw PPG data, as it comes to the algorithm, with a reference HR from another, trusted, sensor.
Once we are happy with the HR, it would be also cool to see if we can extract other parameters, such as respiration rate, but that would probably come later...
-
thanks for the explanation, now it's more or less clear.
As for testing, I have created a repo for testing the algos of BangleJS. Currently it contains only the step counter, but we could happily add also the heart rate. The idea is to upload some test data with reference (maybe coming from another commercial sensor) and benchmark different algorithms.
-
Hi,
I have some students developing an algorithm to detect HR from raw PPG. We are trying to make the algorithm somewhat hardware indipendent, so the outcome could be applicable to Bangle as well (if good enough!). But first I wanted to understand how the current implementation works.
I know you used to compute autocorrelation at some point, but the current algorithm seems more like a peak detector? As the code is not greatly commented, can anybody (Gordon?) explain a little what is the idea behind?
Thanks a lot,
Dario -
I forget how little portable C is!
OK, I have renamed time_t to sc_time_t so it doesn't conflict with linux time_t. Try pulling.Need some 1 hour logs for sleep, driving, working, sitting watching TV - all ZERO step logs.
Yes, but let's not forget collecting steps data under different circumstances (slow walk, fast walk, running, etc).
It would be nice if we could involve other users, just to confirm that there are no major differences across devices.
-
Hi @fanoush, I have followed your work closely in the past. I can see that this is a collaboration among the best experts in reverse engineering watches there are around 😀!
As far as I understand what you are saying, the driver is just an implementation of the I2C protocol, and you have reverse-engineered it. Quite an achievement without a datasheet.
As for the higher level library, the reason why you do not want to use it is because it's not open sourced?
In any case, the fact that it requires acceleration is an indication that it makes use of it to probably discard data that is corrupted by movement. We could probably record some raw signals, including acceleration and PPG and put them in a repository for benchmarking different versions of algorithms. We would also need a reference heart rate for that, which we can obtain from another device, like a Polar or similar. Then we could invite people to test their best algorithms in some sort of competition...
I am working on an HR detection algorithm with students, but using the PPG from a smartphone. As the problem is similar, I may try to include data from the BangleJS as well. I'll keep you informed.
-
Hello, I have added the espruino step counter as well (with minor changes in names). Looks like it has better accuracy than the Oxford one, especially in absence of movement. Well done!
We could use this repository to try to improve the algos with further tweaking. Pull requests are very welcome.
-
Hi,
sorry there were a few bugs, I should have fixed them now, please pull. I have also run some more benchmarks with your new data and tuned the movement detection stage a bit.It would be useful to keep the same file names so that provenance of the logs can be tracked.
Yes, good idea! The only requirement is that the first characters correspond to what we consider the "ground truth".
The Accelerometer logs below are all ZERO steps and should be part of the controlled test data in my view.
Yes, if you are sure about the fact that you did not do any step.
These and similar logs must form at least 50% of the test data in any test harness.
The more data we have the better. Actually we should also include running and walking in different conditions, like on soft floor, hard floor, with and without shoes etc.
No algorithm is going to be perfect, some may be more precise when walking, others when not. In the end it depends on the use case: runners may prefer better accuracy when running, others may prefer better accuracy when walking etc.
As a general aim I think we should try to have something as good as an average fitness tracker.
-
Hello @Gordon , thanks for the reply.
I understand that it makes sense to try with a more ad-hoc peak detector, especially if you know that the hardware is always the same. Our algorithm can be optimised a lot, starting from removing the buffers, but we didn't have enough time for that. As for the heart rate, I would probably trust the proprietary blob better than anything else. With time, if we manage to get a reliable algorithm, we would ideally get rid of it.
Back to the competition idea: I have created a repository where we can test algorithms, see here.
I have already populated it with the data I have collected myself plus some of the data collected by @HughB. I have not included those files where the two measurements of steps are too different, because I don't trust either, and for those that I have included, I have computed the average between the two given step counts.
@HughB would you be able to send me a pull request with your algorithm? Please check the structure inside the dummy algo. If that doesn't fit with yours, I am happy to change it, just le me know (or submit an issue on Github).
With time, we can add more algorithms, or simply improve ours. It's going to be fun (at least for me😀).
I would like to keep this repository also for testing the algorithms for heart rate or sleep detection when we get to it, and I will probably share it with students if I manage to involve some.
For developing a good algorithm we would need the following:
looks like we can get all of them with the apps we have?