Very high value PULSE_SENSOR_TIMING_ANALYSIS
Jardu opened this issue · comments
Dear PulseSensor Team,
after successfully checking and calling serveral times PULSE_SENSOR_TIMING_ANALYSIS on my own sketch I called the PULSE_SENSOR_TIMING_ANALYSIS function on the original "PulseSensor_BPM_Alternative" sketch in order to compare the values with my sketch. After 30 sec I get an extremely high third value (maximum variation). Apparently the reading is ok, I feel my pulse and and it seems sincronized with the LED.
Is there an explanation for that value? It´s basically the maximum of an "int"
Thank you in advance for a short feedback.
Jardu
Pinging @bneedhamia again on this.
I will have a chance to look into it later today.
Are there any major differences between you sketch and the BOM_Alternative?
My pulse sensor is packed during a house remodel, so I'm sorry I'm not in a position to reproduce the problem just now. I did take a look at the timing analysis code, and have a few ideas.
It sounds to me like you're using the timing analysis correctly, but to double-check: When you use PULSE_SENSOR_TIMING_ANALYSIS, the only change you should make to the Sketch or the PulseSensorPlayground Library is to change the two lines in PulseSensorPlayground.h from:
#define PULSE_SENSOR_TIMING_ANALYSIS false
//#define PULSE_SENSOR_TIMING_ANALYSIS true
to
//#define PULSE_SENSOR_TIMING_ANALYSIS false
#define PULSE_SENSOR_TIMING_ANALYSIS true
Once you've made that change, you should recompile and run the unmodified Sketch (PulseSensor_BPM_Alternative in this case).
The Sketch should run normally for 30 seconds, then print the minimum jitter (microseconds variation in sample times), the average offset (microseconds between the ideal and real sample time) and the maximum jitter. The Sketch should then stop.
A large maximum jitter value suggests that something in the Sketch sometimes takes a very long time. A value of 32767 says that the maximum jitter is larger than 32 milliseconds. A jitter that large could cause the pulse sensor library to behave strangely, because the Sketch is not reading pulse sensor values at a regular rate.
I don't understand the printout in the screen shot. It looks as though a printout is happening every few milliseconds - is that true? If the Sketch is not using interrupts to sample the pulse sensor, and it's printing something every few milliseconds, that would explain the large maximum jitter number. In that case, the jitter is normally low, but when a printout happens, the Sketch stops reading the pulse sensor for many milliseconds.
Did you add code to PulseSensor_BPM_Alternative.ino, to print the lines that look like:
01:23:58.249 -> 68,890,468? If so, please remove that printout code and run PulseSensor_BPM_Alternative again.
Thanks for being adventurous and trying out the timing analysis code, and good luck.
Dear bneedhamia,
thank you for your detailed feedback. I followed carefully your instructions. I changed the PulseSensorTimingAnalysis (PSTA) the way you decribed it above.
In this case I´m using the original code "PulseSensor_BPM_Alternative.ino" The one and only change I made ist the (PSTA). The serial output is the result of "pulseSensor.outputSample();". The values are BPM, IBI, Signal. Before the arrow is the timestamp. If I comment "pulseSensor.outputSample();" out I´ll get the following: -1, 0, 1. Consequently this means if there is no serial printing, the jitter maintains on low values?
In my sketch I comment out "pulseSensor.outputSample();". I´m just printing the IBI once a beat happens:
if (pulseSensor.sawStartOfBeat()) {
if(digitalRead(Pin1) == HIGH){
Serial.println (pulseSensor.getInterBeatIntervalMs());
}
}
And the feedback is something like -1 0 4.
The rest of the sketch is basically the same.
Best regards.
Jardu
Yes, if there's no Serial printing, the low jitter numbers make sense.
Is it the serial printing that is contributing to the jitter?
If so, would it make sense to increase the baud rate and try again?
Now that I've thought a bit longer about it, I wonder whether that huge maximum jitter is a just startup artifact. I remembered it's a maximum number collected over the whole run of the Sketch, If, for example, after starting the Pulse Sensor the Serial output hangs the Sketch to wait for the Serial Monitor to open, that could produce a huge maximum jitter number.
If the baud rate weren't high enough, I'd expect the average offset number to also be high, showing that the Sketch had to frequently pause to wait for output. So I don't think baud rate is a problem in this case.
One experiment you could try is to wait to start the Pulse Sensor until the Serial connection is up and running: in setup() using "while (!Serial);" before the pulseSensor.begin() call.
Feature Creep Warning: one feature you could consider adding would be a PulseSensorPlayground method called "restartTiming()" or such, that would, if PULSE_SENSOR_TIMING_ANALYSIS was true, clear the statistics in the PulseSensorTimingStatistics object - just as if that timing object was just now created. That way a sophisticated timing user could call restartTiming() some time after the Sketch was running smoothly, or after some event that they knew would delay the pulse sensor sampling. ...or in Agile style, you could wait until a customer has an issue with a large maximum jitter number, and work out a suitable solution then.
Quick question for @Jardu : is the initial problem solved? That is, does the timing output look correct when you run your Sketch?
@bneedhamia: Thank you for your advice, I´ll will check the ""while (!Serial);" before the pulseSensor.begin() " idea. As mentioned, theres is actulally no problem, when I run my basic sketch:
....
if (pulseSensor.sawStartOfBeat()) {
if(digitalRead(Pin1) == HIGH){
Serial.println (pulseSensor.getInterBeatIntervalMs());
}
}
....
I just call once the IBI value. The problem only occurs p.e. when calling "pulseSensor.outputSample();" before "pulseSensor.sawStartOfBeat()" and calling "pulseSensor.outputBeat();" within "pulseSensor.sawStartOfBeat()" as in the original PulseSensor_BPM_alternative-sketch.
Does this answer the question concerning the initial problem?
Thank you and best regards.
Jardu
Yes, thanks.