Most recent activity
-
thanks for the availability and the suggestions! You will be receiving pull requests soon 😃. I'll keep the signature as it is for now, and only change it if it is required.
One little note about the code, I see that you mostly use generic types like short, int, float etc. We will try to keep that style too, although I wonder if it wouldn't make more sense to be more specific and indicate also the n. of bits? What's the philosophy here?
Re. activity detection: it is not planned at the moment, but it's something I'd like to work on at some point.
-
hello again, some news about the new algorithms benchmark.
Data: we have prepared a data collection protocol, we aim at 20 people, doing different activities, both on treadmill and outdoor walking. The protocol will get an ethical approval from Politecnico di Milano. Right now we don't have the permission to publish the data, but we are planning to obtain it. I understand that the data is what you would mostly appreciate, so I am keen to publish those files, but it may take some time. We are planning to acquire the data at its default sampling frequency for both acceleration and PPG. Would that be OK for you, or would it make more sense to acquire at higher frequencies, in case you want to test out different frequencies?
Tests: the repository for the tests that you have may need some adaptation though. We are starting with the step counter and we can already see some changes to make. Concretely:
- the main.c needs to be adapted to be able to run different algorithms, not just 2 (espruino and "original"), we are going to change it and make it more general. I hope that it's OK?
- in terms of output, I would suggest to print out just the totals, comma separated, then that could be copied into a spreadsheet where all sorts of statistics can be done. Or we add stats to main.c, but maybe after the totals.
- algorithms would go into a dedicated folder, that includes moving the "original" algorithm into its own .h/.c files instead of being mixed within main.c. We can keep the espruino one linked from the Espruino code so it's always upated to the last version.
If you are OK with these, we will be sending pull requests, as we advance with the task. You can of course review those and suggest changes if there's anything you don't like.
Another issue: from what I understand the current API for the step counter (stepcount_new(int accMagSquared)) return a 1 if a step is detected or a 0 otherwise (and in some cases it tries to make up for lost steps too? haven't studied this well yet). I would suggest to change the signature to something that is more generalisable for other algorithms, for example instead of returning the "new" steps, it would return the total step count, since the algorithm was inited (or reset) and instead of accepting the magnitude as argument, it could accept the raw x, y and z. I know that this has repercussions in many places within the Esrpuino code, so it's a lot to ask, but it would make the signature compatible with algorithms that are based on different approaches. Let me know how doable this would be. We can of course decide later, if and when we have some good alternative candidate algorithm.
Thanks!
- the main.c needs to be adapted to be able to run different algorithms, not just 2 (espruino and "original"), we are going to change it and make it more general. I hope that it's OK?
-
thanks for the answers!
That would allow to do circular buffer in the file.
A circular buffer is roughly the idea I am thinking about: as new data comes in it gets appended. When the file is full, old data gets overwritten. This should be possible pre-allocating enough space using also the size parameter in the write() method so that I can re-write on the same file with offset in the write() method to append. However, the documentation says that I can't rewrite the same position on the same file which brings two problems:
Problem 1: I cannot rewrite older data. Workaround is to pre-allocate enough space and not overwrite. If space ends, I either create a larger file (and copy the existing content), or I give up and warn the user. I can live with the second, though not great.
Problem 2: I need to keep track of what is the last byte that was written on the file, otherwise when I read back the file I will get all the "empty" data, the 0xFF bytes. Solutions are that I either impose that 0xFF cannot be used or that I keep track of the actual size of the storage file in a separate permanent memory, but Storage (and StorageFiles) would not work for this because I cannot rewrite them.
Do you wise people have a better idea?
Gordon, maybe you can extend the current API to support overwriting already written positions? -
Hello,
we are building a sort of fitness tracker type of app. The idea is to store data at a high(ish) freuency (minute by minute or so) which does not fit with the already existing health database that you have implemented.
In order to use space efficiently, we would like to save the data in a binary format, AND we need to append data to the file. Basically the files are written in append mode on sensors reading, and read week or so for synchronization with a smartphone.
Which option do you suggest using?
Storage.write() and Storage.read(). The problem with these is that there is no append mode. Maybe pre-allocating the file size and then writing with an offset would work? If yes, is there any efficient way to read bytes instead of strings (ideally without preloading everyting into RAM)?
StorageFiles offer a handy append mode, but, AFAIK, one can only write strings.
Flash library, would do to access the underlying flash memory, but I checked how much memory was available and got only 250kB, which makes me think that it points at the 1024kB on-chip flash instead of the exteranl 8MB flash? There is no way to access that memory directly (and safely)?
any other idea?
Thanks.
-
what do you use for capturing the reference data?
HR: Polar HR sensor with BLE (based on ECG)
Steps: we put an IMU on a shoe. With some simple thresholding, the step count is quite reliable. -
@Gordon I am working with 2 students on the algorithms for HR and steps. We would like to integrate with your work in the most efficient way so that, in case they come up with something promising, you can integrate their code easily into the firmware.
What we are going to do:
- collect raw data with reference, both step count and heart rate
- test out a few alternative algos and compare them in terms of accuracy / resources utilization
I am aware of these two repos that you have created:
https://github.com/gfwilliams/EspruinoHRMTestHarness
and
https://github.com/gfwilliams/step-countWe can simply push code to those 2, or, maybe more efficiently, we could merge them into one?
Some guidance would be greatly appreciated.Thanks...
- collect raw data with reference, both step count and heart rate
-
My wishlist:
- OLED or (even cooler) e-ink
- more buttons (useful but not strictly needed)
- accelerometer with integrated step counter (Bosch has some really good ones)
- PPG sensor with well documented HW and SW
- multi color PPG (for example green and infrared) for oxygen saturation
I think that there is demand for really programmable smartwatches. So far the only ones I am aware of are yours and PineTime.
- OLED or (even cooler) e-ink
-
Hello all,
very interesting developments here!
I have been trying the new algorithms myself too. I had the Heart Rate Monitor app on the Bangls JS (version 2 bought from Kickstarter campaign, FW 2v19), and another smartwatch plus a PPG from the samrtphone on the other arm. I have noticed some differences, especially at lower HRs, but couldn't do this very systematically. I am planning to do some more tests with a bluetooth Polar ECG belt in the coming days and will report back.I have read in this thread that the manufacturer's library also supports SPO2 and Blood Pressure. It would be extremely interesting to receive these 2 as well. I do not trust BP at all, but SPO2 is doable and has been proven reliable on other devices (for example Withings). Is there any plan to support these? And /or to allow collecting PPG from the 2 LEDs (my understanding is that there is a green LED and an Infrared LED)?
Thanks!
Hi Gordon,
I have some news. The students have completed their work on development and bencharming of the algorithms. They had time to work only on the step counting, we have left the heart rate measurement for later. We decided to create our own repository for this, as it was more practical. It doesn't follow the code conventions of Espruino completely, but it should be relatively simple to adapt the code in case you want to try it within the firmware. The repository is here: https://github.com/VirginiaSek/Algo
But I guess that you would be more interested in the results from the tests the students have done. I am sharing their thesis here in attachment.
If you want to discuss these results, I am happy to do it here or by email or a call. As for the data they collected and used, we would need to take it privately.
Hope this helps!