08-19-2021, 01:13 PM
hrs.data is generated by a diagnostic mode I added to the heart rate application to allow people who are interested to record test data to try and develop more robust heart rate detection algorithms using real data gathered from the HRS3300 sensor on the PineTime. Some people have reported that the initial algorithm I developers doesn't work well for them. Gathering a wider range of data sets is the first step to developing better heart rate detection algorithms.
The current heart rate detection algorithm does not attempt to estimate heart rate variability so I assumed you were gathering hrs.data in order to implement new algorithms.
If you are trying to do overnight logging then I'm extremely skeptical that using the diagnostic features built into the existing heart rate detection implementation is the best way to approach things. Whether you split the files up or not it will still yield over a megabyte of samples and that will take a long time to transfer over BLE. Instead, once you have implemented suitable algorithms, then surely it is better to process the raw data on the watch and log BPM and HRV values instead (e.g. write a new app that is similar to heart.py but keeps the screen off and logs the BPM to a file rather than showing it on the screen).
If you really do want to capture raw samples then you should write you own logger so you can add some form of compression to the data (e.g. write a new app that is similar to heart.py but inject samples into a compressor instead of injecting them into the PPG algorithm). The major drawback with this approach is that you will have to add a compressor yourself: there is nothing builtin to wasp-os to help you compress data.
The current heart rate detection algorithm does not attempt to estimate heart rate variability so I assumed you were gathering hrs.data in order to implement new algorithms.
If you are trying to do overnight logging then I'm extremely skeptical that using the diagnostic features built into the existing heart rate detection implementation is the best way to approach things. Whether you split the files up or not it will still yield over a megabyte of samples and that will take a long time to transfer over BLE. Instead, once you have implemented suitable algorithms, then surely it is better to process the raw data on the watch and log BPM and HRV values instead (e.g. write a new app that is similar to heart.py but keeps the screen off and logs the BPM to a file rather than showing it on the screen).
If you really do want to capture raw samples then you should write you own logger so you can add some form of compression to the data (e.g. write a new app that is similar to heart.py but inject samples into a compressor instead of injecting them into the PPG algorithm). The major drawback with this approach is that you will have to add a compressor yourself: there is nothing builtin to wasp-os to help you compress data.