Can't acquire .sawStartOfBeat()

[olsonap]

Can't acquire .sawStartOfBeat()

[olsonap]

For clarity, the above code was formatted weird and I'm not great with markup yet. The run() function is inside an infinite while loop in main.cpp. The while loop shown in the code snippet is (obviously) commented out.

[olsonap]

Turns out that was a baud rate issue due to multiple baud rate settings.

HOWEVER, now I'm getting BPM that's about two times too high and if it comes down, it tends to creep up. I think I'm dealing with a timing issue, but I'm not sure how to resolve. I'm using vTaskDelay(10 / portTICK_RATE_MS); at the moment and BPM is pretty stable at 200 on the earlobe.

[biomurph]

@olsonap
if your feeling stable with a BPM of 200, you might be in cardiac arrest....

There are known issues when you just dive into the ESP32 land with our library. It is doable, but it's not easy.
Please look at some old issues? There seems to be a way to integrate the timer on the ESP32 to get more accurate sample rate that our algorithm can work with. It's likely that the high (inaccurate) BPM that you're getting is a result of that.

Tell me more about your hardware. I have an ESP32 here, but it usually helps to know exactly what you're using.

Also SUPER IMPORTANT! send me a pic of your Pulse Sensor and hardware setup. Sounds crazy, but it can help enormously.

[olsonap]

Lol, what I meant was the BPM is holding (stable) at about 200 BPM despite my very normal, 2-digit heartrate.

I'm using a tinyPICO from UnexpectedMaker (UM), which uses an ESP32-PICO-D4. I'm also using UM's I2S audio shield. The bulk of the code is coming from ESP-IDF examples, including a2dp-gatts-coex and gatts-server. I'm using two pulsesensor.com sensors (I'll attach an image shortly) and I've seen how many fakes are out there but I think I've got real ones based on the issues section on this page. I'm using a lipoly battery from adafruit although it's been plugged into 5V during the development process.
My sensors are connected to 3v3, ground, pin 4 (sensor 0) and pin 32 (sensor 1).

I think I'm still dealing with a baud rate issue. When I force part of the IDF down to 9600, I get one good HR from just one of the sensors. When I allow the system to use 115200, both sensors work poorly at inflated bpms. If this is what's going on, it's an IDF issue and I think it'll work better when I'm no longer using the serial monitor.

Just thinking out loud.

[olsonap]

[olsonap]

Hardware's not much to look at I'm afraid.

[biomurph]

I can verify that you're using a legit PulseSensor, and not some cheap knockoff.

have you tried just running the pulse sensor code on your platform without any other stuff?
The ESP32 can be tricky because it is a microcontroller and a radio, so it will get 'hijacked' by the radio and loose it's sense of time.
Other things:
I'm not sure what you're doing with the 'run' and 'main' loops. What's your dev environment?
There may be real issues using our existing library given that we require accurate timing to get good IBI and BPM values. Again, check the issues past for mention of ESP or other wifi modules.

[olsonap]

I got it working well in Arduino using the serial monitor and a sketch very closely resembling the run() function. Of course, I had to use your alternative method with interrupts off, but that was always the plan anyway. The values were all very reasonable and didn't float around at all after a couple seconds. That's when I started moving over to the IDE, but I had to make a lot of adjustments to my epressif coexistence code in the process. I'm using the ESP-IDF in Visual Studio Basic, and I'm using "Arduino as a component" to keep your library functional. There's a little bit of C and C++ mixing involved too.

[olsonap]

I'll look into past issues tomorrow. I'm optimistic though, it feels like I'm close

[biomurph]

Yeah, it sounds like a kludge.

can you get the serial port running and look at the signal? That is always my go-to. If I can see a signal that is legit, then I at least think that I can find the artifacts I'm looking for in it...

Also, I think there is really some fundamental timing that's not being addressed.

[olsonap]

It's working great 👍

[biomurph]

Yes, that looks great.

I think you're right. the issue you're having is with the ESP variant and not with the hardware.
Interesting that you can get good data when you are at a lower baud rate...
It's hard to tell from your code being formatted weirdly in this thread, but try to see if there are areas where you are spending too much time doing stuff.

When not using the hardware timer, the BPM Alternative sketch is 'manually' gathering the beats based on a software timer set to 500Hz (sample every 2mS). When you call the sawNewSample() function, that's when it checks to see if it's time to get the next sample. I would think that a higher baud rate would make the duration of your time 'doing stuff' greatly reduced.

Also, we are relying on the ability to do software timing in microseconds. This can be problematic in the ESP32
https://esp32developer.com/programming-in-c-c/delays/delays
That's just one reference, but I don't think the ESP32 can do sub millisecond timing without grabbing a hardware timer.
If you don't need to constantly report the BPM, you can gather data during dedicated time, and then report it?

[olsonap]

Hello again.
So how many times should I be calling analogRead(PulseWire) per second to be successful?

Also, I need to calculate PIR. Any tips on how to get the time values of these points?

I just need to get the time value of peaks and lows.

[biomurph]

@olsonap
In our PulseSensor Playground library, we are targeting a 500Hz sample rate. That has been determined to be optimal for accurate BPM and IBI (Interbeat Interval) values.
If you're not using the PulseSensor Playground library, you will need to time your sample reading to be as accurate as you need. The lower the frequency of sample reading, then the lower resolution of BPM and IBI.

As I mentioned, the ESP hardware has some issues when using the millis() and micros() timing functions in Arduino.
There is an old issue thread on this repo that has some code that a user wrote to grab a hardware timer on th ESP that you can find and use, I'm sure.

As for your PIR requirement, you should know that the Pulse Sensor hardware does not deliver a "raw" PPG signal. We condition the signal with hardware filtering and amplification to deliver a large, clean, easy to use pulse signal.
If you are looking for the raw PPG to find time-domain artifacts and morphology, you may need to get a different sensor.

[olsonap]

Understood. It looks like it was running at a very consistent 202Hz. I managed to find what I believe is a reliable timer in the ESP-IDF and have sped it up to as much as 1650Hz by adjusting baud rate and trimming some fat. I'll have the sensors in front of me later to test.

The PIR I'm after is a dimensionless ratio, so I don't necessarily care about time, just the distance between peaks.

[biomurph]

@olsonap Oh, great! Glad to hear that you have captured a consistent sample rate.
Please note that in my research and understanding, you don't need to go much over 500Hz. You will need time between sample taking to run algorithms and do other things, likely?

Also, I understand the PIR, and it is derived from the raw PPG waveform. Our Pulse Sensor hardware does filtering and amplification on the raw waveform, so you will likely get values for PIR that are not 'real', meaning that they are not based on actual photodiode current.

[olsonap]

Oh okay. That's fine for my purposes I'd say. I was thinking of altering PulseSensor.cpp a bit to find the sampleCount of two consecutive troughs (calling their sampleCounts systole1 and systole2) and then the next peak (diastole). (diastole-systole1)/(systole2-systole1) would be my pseudo-PIR.

[biomurph]

@olsonap sounds like a plan!

If your feel resolved, please close this issue.
Let us know if you have any other questions or project ideas.

[olsonap]

Thanks for your help!