Heart rate sensor MAX30102

[richard]

the filter is not really the issue, its the variability of the data that is problematical, every 128 sample is subtly different.
light leakage, finger pressure and position and even finger compression time lead to wildly variable readings. my max30102 housing is probable not ideal either
i use for this filter
fv = fv*x + nv*(y)

where x+y = 1, fv = average nv = new value

in pbp terms x y
ave = (ave ** 60000) + (buffer[index] ** 5535 ) ;60000 + 5535 = 65535
or
ave = (ave */ 250) + (buffer[index] */ 5 ) ;250+ 5 = 255

depending on finesse required, the introduced phase shift has no bearing on the result either.
it may not be as fast as your method but has better control and in this case speed is of no importance

[richard]

well my sensor was not 5v tolerant its now a random number generator , in the bin
i give up

[astanapane]

Richard which sensor did you have? Could you please let us know? for avoiding it in the future.

Based on cardiovascular medical graph, the post #44 and post #49 looks fine.

I think #49 it is a bit better which doesnt mean the in #44 the graph is not acceptable.

[richard]

my module was clearly marked as 3.3v its the one with slots in the board to tie it on your finger
the code has little if any effect on the graphical result. the result depends on your finger and its placement
ambient light etc, my holder is a little tight it constricts circulation a bit and i need to change fingers every 10 minutes to get good data
i found a spare [must have bought 2] i will be more careful with this one.

i still cannot get a algo to find the right peaks. on a graph it looks so obvious even in the crappy reads beats are distinctive, by the absolute shits computers are stupid. breaking the search into 32 sample blocks gets me the block highest highs and lowest lows but there is no guarantee the high in a block is actually a peak or whether continues to ramp up into the next block

[astanapane]

I guess you have this one



https://www.teachmemicro.com/max3010...r-for-arduino/

I also have 2 of those, but in the schematic the input voltage is 3.3V to 5V.



or you are talking about the logic level? So i also need to take care about it and supply the PIC with 3.3V.

[richard]

interesting mine has no jumper fitted, its not dead just gives random results , temp works ok still
led still comes on
i will solder the jumper and try again

[Ioannis]

It is very important to:

1. have the finger cleaned with alcohol before testing and also clean the sensor with alcohol too.
2. Not pressing hard the finger on the sensor, the shell of the sensor should be lightly tight on the finger.
3. No ambient light should come in the sensor area. Most if not all commercial devices are black for a purpose.

Hope this helps.

Ioannis

[richard]

i cleaned the screen with metho it had a spec of gunge in the wrong spot now restored. mine will not run for long at 5v 3-4 minutes then the readings are crap, jumper made nil difference. i notice the led got substantially brighter when it goes strange. 5v is a no go for this unit

[richard]

I think the LPF should not be so aggressive.

if you want automatic pulse measurement that remains to be seen, a pretty picture is a different story


you can adjust filter as you see fit

the filter is not really the issue, its the variability of the data that is problematical, every 128 sample is subtly different.
light leakage, finger pressure and position and even finger compression time lead to wildly variable readings. my max30102 housing is probable not ideal either
i use for this filter
fv = fv*x + nv*(y)

where x+y = 1, fv = average nv = new value

in pbp terms x y
ave = (ave ** 60000) + (buffer[index] ** 5535 ) ;60000 + 5535 = 65535
or
ave = (ave */ 250) + (buffer[index] */ 5 ) ;250+ 5 = 255

depending on finesse required, the introduced phase shift has no bearing on the result either.
it may not be as fast as your method but has better control and in this case speed is of no importance

@ PutMulResult?D _average ;RED AVERAGE
ave = DIV32 128 ;RED AVERAGE
reg = OVF_COUNTER
i2cread sda,scl,ADDR,reg,[reg ]
DEBUG 13,10,"OverFlows ",DEC reg,9,dec ave,9,hex ave
FOR index = 0 TO 255 step 2
ave = (ave ** 57000) + (buffer[index] ** 8535 )
lpfdata[index>>1]=ave
;.....lpf..;;;;----red-----;;;;======-ir-========
DEBUG 13,10,dec ave,9,dec buffer[index],9,dec buffer[index+1]

NEXT
' RETURN

[astanapane]

sorry for my late response. I was really busy these days.

thanks for the info. I will do some changes and tests.

[Ioannis]

I do not know if it is suitable for this project, but I had good results with Darrels Taylor ADC oversampling routines (http://dt.picbasic.co.uk/CODEX/AnalogueOverSampling).

Also Kalman filters maybe of use. I find them difficult to implement though.

Ioannis

[richard]

no amount of low pass filtering will remove the dc component, ultimately it just makes it worse.
the dc component needs to be removed to make detection of the beat peaks reliable.
there is plenty of raw data posted, you can always ask for more. feel free to have a go

[Ioannis]

I am not currently on this project. Was disappointed and set it aside. Removing DC component with firmware I think is too difficult.

The oversampling of DT routines were tested and applied on other projects with amazing results (costing in program speed of course, nothing is free).

Ioannis