As I'm finally getting the majority of orders out the door now I want to turn my attention to the missing piece for my new hardware. I wasn't really sure if I was going to be able to include this but the quality of my data is so much better than I expected that this will be a really solid inclusion and take our new device's capabilities to the next level.
If you've done any biofeedback, one of the first kinds you'll hear about is something called Heart Rate Variability using a little ECG ear clip or skin patch. Essentially, as you breathe or fluctuate in various states of relaxation and anticipation your heart rate fluctuates with it. When you breathe in your heart rate rises slightly and as you breathe out it returns to baseline. This variability is good at highlighting states of anxiety for instance if it's really erratic. A high, stable variability with a slow, deep, and stable breathing pattern is considered ideal for your body, as it apparently improves cognitive flexibility - if mainly by helping with anxiety levels. There's a bit more to it than that but I'm not really an expert, and there is a lot of interest on the medical side as well.
So Pulse Rate Variability is what this measure is called when you perform this with a PPG sensor instead - i.e. the HEG. This is different because the wave shapes are much smoother using light as the pulse you are seeing is due to arterial wall dilation rather than the electrical pulse from the heart. You can learn a lot about your physical health based on the shapes of these waves on different parts of your bodies and diagnose many health problems it turns out. The different nature of the information also holds more physiological clues than what an ECG can show.
However, the standard methods used in ECG monitors for HRV don't translate so well for PPG waves. This has left me a little stumped until I finally found some useful material for how to conquer this problem. Turns out it's fairly new to use a pulse ox over an ECG for this so we'll be making some good headway by implementing PRV features in our software.
So how, then?
Well I thought about using just an FFT and hoping for the best by just picking out the local maxima in the pulse range (~0.5Hz - 4Hz), and that's certainly something I'm going to try as I already wrote an entire library for doing GPU FFT work, but a couple a couple papers I found appear to get very accurate results for both the PRV measure and performing Base Scale Entropy Analysis in real time:
Assessment of pulse rate variability by the method of pulse frequency demodulation
A Real-Time Analysis Method for Pulse Rate Variability Based on Improved Basic Scale Entropy
The first paper uses a fairly classic frequency mixing method with some extra degrees of freedom to make the analysis more accurate. The second paper pretty much just adds a sliding window to standard base scale entropy analysis. I don't even know what you're supposed to do with that second piece of data but it's been requested along with coherence. Coherence is a bit easier, especially if the FFT method proves to be just fine.
I'll be working on getting this implemented ASAP. Let me know if you have any expertise with this type of math and can help me write out the equations required for the pulse frequency demodulation algorithm in that first paper I linked. I am going to ask my local RF gurus for some guidance but this is all open to anyone. None of it looks *that* hard, just detail oriented.
On a side note I am planning to get out of my shell a bit and begin doing a hangout/streaming thing beginning next year where I'll show off my development process over stream and invite anyone in to shoot the shit and workshop ideas like this one. We are also going to get a new software format fairly soon with the tools created for our new Web BCI platform for the FreeEEG32 (and beyond) and then adapting the HEG app features into it to make a robust, multiplatform software base for all kinds of BCI - all web based (still installable) and easily accessible for 1-click plug-and-play for simple or sophisticated devices. What's going to be cool about this format is it will let you code modules for it without having to know as much as you do now to begin to break my code down (plus I haven't properly documented it yet with the constant big changes) and take full advantage of nodejs and interoperability options e.g. to link with massive scientific code bases in Python or C++. We think this will be a really powerful tool at that point where suddenly there won't be nearly as big of a mess trying to create software around BCI.