High heart rates reported incorrectly

[Mr-99]

When the heart rate exceeds 100, it jumps to 50. Can you help me?(Sorry, my English is not very good.)

[aromring]

Please refer to the "HOW TO REPORT BUGS" section in README.md file in this Github repository. In particular, I need a sample of raw data that results in the observed behavior.

[Mr-99]

Thank you for your reply.What I want to ask is whether anyone else has encountered this situation.

[aromring]

Yes, indeed, by a strange coincidence, on the very same day I've received an e-mail message describing the same kind of problem. Was it you? In any case, that person sent me two raw signals coming from the detector, which allowed me to diagnose the problem. My response is copied below: "Hi ***,

It is exactly what I suspected. First, let me thank you for sharing your data - this helped immensely! Indeed, you get a clean, good signal, so there is no problem from that angle. Post-processing is also done correctly, either by you or my algorithm.

So why it does not result in correct HR? This is because my algorithm was designed for nocturnal applications where the typical heart rate is around 60 bpm. This results in a typical period of 25 samples between pulses. Now look at the autocorrelation curve is Step 4: 25 is in the vicinity of the first peak, maximum of which corresponds to the currently measured period (23 in this example). To save computing time, and this is critical, autocorrelation is evaluated for the smallest possible number of points on the curve. Now, what would happen if the initial period was, e.g. 50 instead of 25? The algorithm would find the maximum of the second peak instead, at 46, and the predicted HR would be the half of the actual one.

This is what happens in your case. Since you're applying the algorithm outside its domain of applicability, the initial period of 25 is too long and it picks the second autocorrelation peak for your first signal, and third peak for your second signal. Thus the real HR for your first example was 2 65 = 130 bpm, and 3 51 = 153 in the second case.

Obviously, this is a bug from the point of view of all applications, although an acceptable behavior in its domain of applicability. The remedy is obvious: greatly increase CPU load to make sure all relevant autocorrelation peaks are covered. I will think about making it as efficient as possible. In the meantime, I'd like to suggest a workaround: in the algorthm_by_RF.h file change the following parameter:

define TYPICAL_HR 60

to, e.g.

define TYPICAL_HR 120

in addition to modifying MAX_HR. Again, this alone has its own domain of applicability limited to physical exertion situations and not working during sleep.

If you have a Github account, then you'll receive a notification when appropriate bug fix is ready."

[Mr-99]

well.Thank you again for your contribution to open source software.I closed the problem.

[aromring]

I've reopened this issue under a new title, since I haven't got any time to fix the code.

[GOKUandVEGET]

I changed the typical heart rate, but it didn't work. How do I need to modify? Thank you!

[aromring]

I will be glad to help. Please open the README file here: https://github.com/aromring/MAX30102_by_RF/blob/master/README.md scroll down to HOW TO REPORT BUGS section and follow instructions therein.

[GOKUandVEGET]

It's the solution to this problem. According to you, changing the typical heart rate to 120 doesn't work. It's still wrong at high heart rate

[GOKUandVEGET]

Yes, indeed, by a strange coincidence, on the very same day I've received an e-mail message describing the same kind of problem. Was it you? In any case, that person sent me two raw signals coming from the detector, which allowed me to diagnose the problem. My response is copied below: "Hi ***,

It is exactly what I suspected. First, let me thank you for sharing your data - this helped immensely! Indeed, you get a clean, good signal, so there is no problem from that angle. Post-processing is also done correctly, either by you or my algorithm.

So why it does not result in correct HR? This is because my algorithm was designed for nocturnal applications where the typical heart rate is around 60 bpm. This results in a typical period of 25 samples between pulses. Now look at the autocorrelation curve is Step 4: 25 is in the vicinity of the first peak, maximum of which corresponds to the currently measured period (23 in this example). To save computing time, and this is critical, autocorrelation is evaluated for the smallest possible number of points on the curve. Now, what would happen if the initial period was, e.g. 50 instead of 25? The algorithm would find the maximum of the second peak instead, at 46, and the predicted HR would be the half of the actual one.

This is what happens in your case. Since you're applying the algorithm outside its domain of applicability, the initial period of 25 is too long and it picks the second autocorrelation peak for your first signal, and third peak for your second signal. Thus the real HR for your first example was 2 65 = 130 bpm, and 3 51 = 153 in the second case.

Obviously, this is a bug from the point of view of all applications, although an acceptable behavior in its domain of applicability. The remedy is obvious: greatly increase CPU load to make sure all relevant autocorrelation peaks are covered. I will think about making it as efficient as possible. In the meantime, I'd like to suggest a workaround: in the algorthm_by_RF.h file change the following parameter:

define TYPICAL_HR 60

to, e.g.

define TYPICAL_HR 120

in addition to modifying MAX_HR. Again, this alone has its own domain of applicability limited to physical exertion situations and not working during sleep.

If you have a Github account, then you'll receive a notification when appropriate bug fix is ready."

If I want to adapt this code to a heart rate of 40-150, how should I modify the code

[aromring]

The new HighHeartRate branch of this code fixes this bug. Keep in mind that it's beta version. I will be very grateful for someone to test it!

[aromring]

With today's merger of HighHeartRate branch this bug is considered to be fixed.