would it make more sense to acquire at higher frequencies, in case you want to test out different frequencies?
That's a tricky one. A higher sample rate means the HRM sensor will adjust quicker, so even if you take samples out it may not give an accurate comparison. I think maybe just stick with the default rate (for that and the step counting).
It's worth noting that right now we don't calibrate the frequency so it can depend slightly on the watch. In the OEM firmwares they fine-tune the sampling frequency to exactly 10Hz.
In terms of changes to the test harness - yes, that all sounds good.
I would appreciate it if you could try and ensure the existing step count data can run with the step counter too so we can have a clear idea of how new algorithms perform with that too. I don't care about HRM as we don't have much data there.
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
I'd prefer not to handle 'total step count' because we're juggling a few different step totals inside Espruino already and I don't want one more. It feels like a trivial for an algorithm to just keep an internal counter and output the difference between current and last? We can always ensure we handle negative step differences if that needs to happen.
But on the x/y/z front, yes, that makes complete sense to change the signature. Ideally pass accMagSquared too so existing algorithms aren't having to calculate it out twice.
... but before we mess with the Espruino repo, let's get some data and algorithms - you can always ensure your repo uses the new call signature, and then you can just have a stub:
int stepcount_new_ext(int x, int y, int z, int accMagSquared) {
return stepcount_new(accMagSquared);
}
I'm not sure if this is a good extra thing to have, but some trackers have an 'activity' value for what it thinks you're doing - sleeping, walking, running, etc. Something that could detect that would be a really neat addition (but obviously your data would need marking up somehow)
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
That's a tricky one. A higher sample rate means the HRM sensor will adjust quicker, so even if you take samples out it may not give an accurate comparison. I think maybe just stick with the default rate (for that and the step counting).
It's worth noting that right now we don't calibrate the frequency so it can depend slightly on the watch. In the OEM firmwares they fine-tune the sampling frequency to exactly 10Hz.
In terms of changes to the test harness - yes, that all sounds good.
I would appreciate it if you could try and ensure the existing step count data can run with the step counter too so we can have a clear idea of how new algorithms perform with that too. I don't care about HRM as we don't have much data there.
I'd prefer not to handle 'total step count' because we're juggling a few different step totals inside Espruino already and I don't want one more. It feels like a trivial for an algorithm to just keep an internal counter and output the difference between current and last? We can always ensure we handle negative step differences if that needs to happen.
But on the x/y/z front, yes, that makes complete sense to change the signature. Ideally pass accMagSquared too so existing algorithms aren't having to calculate it out twice.
... but before we mess with the Espruino repo, let's get some data and algorithms - you can always ensure your repo uses the new call signature, and then you can just have a stub:
I'm not sure if this is a good extra thing to have, but some trackers have an 'activity' value for what it thinks you're doing - sleeping, walking, running, etc. Something that could detect that would be a really neat addition (but obviously your data would need marking up somehow)