Add support for the MAX30102 heart rate and blood oxygen sensor

[jclsn]

I have created a device tree overlay for the above sensor with the help of PhilE from the forum. The sensor is now fully recognized. I updated the build config files for all models, though I am not sure about the correct naming there, as they seem to differ in every config. This should be verified.

[pelwell]

As discussed on the Forum thread (https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=317957) I'll take this and merge it into the existing i2c-sensor overlay. In the process I'll change the config settings to make the driver a loadable module (=m instead of =y).

[jclsn]

Yes, that makes sense. Thank you for the support! This is probably what makes the Pi so successful in comparison to many other SBC.

…

Am 18.08.2021 um 15:06 schrieb Phil Elwell ***@***.***>:  As discussed on the Forum thread (https://www.raspberrypi.org/forums/viewtopic.php?f=107&t=317957) I'll take this and merge it into the existing i2c-sensor overlay. In the process I'll change the config settings to make the driver a loadable module (=m instead of =y). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[pelwell]

Can you fetch your rpi-5.10.y branch again and test the new i2c-sensor overlay? You'll find that it's been force pushed - git reset --hard rpi-5.10.y should put you back on track.

[jclsn]

Yes, I will try that later. Maybe I should also add an override for the LED intensity.

…

Am 18.08.2021 um 16:49 schrieb Phil Elwell ***@***.***>:  Can you fetch your rpi-5.10.y branch again and test the new i2c-sensor overlay? You'll find that it's been force pushed - git reset --hard rpi-5.10.y should put you back on track. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jclsn]

I just finished compiling. The solution before was better. I know have this view I think I am missing some interfaces (or I just can't find them).

…

On Aug. 18 2021, at 4:58 pm, Jan Claußen ***@***.***> wrote: Yes, I will try that later. Maybe I should also add an override for the LED intensity. > Am 18.08.2021 um 16:49 schrieb Phil Elwell ***@***.***>: >  > Can you fetch your rpi-5.10.y branch again and test the new i2c-sensor overlay? You'll find that it's been force pushed - git reset --hard rpi-5.10.y should put you back on track. > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub (#4535 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AEW47NZGYFL2THPWHX35Y4DT5PB7NANCNFSM5CL7H6VA). > >

[pelwell]

There were two errors in the overlay - the sensor was being enabled by default, and the I2C interface wasn't being enabled for max30102. Try now.

[jclsn]

The pull is taking quite long this time. I have 3d print a case for this thing. Will be back in three hours approximately and get back to you then!

…

On Aug. 19 2021, at 4:02 pm, Phil Elwell ***@***.***> wrote: There were two errors in the overlay - the sensor was being enabled by default, and the I2C interface wasn't being enabled for max30102. Try now. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub (#4535 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AEW47N63HPP6LVC2WTARLD3T5UFITANCNFSM5CL7H6VA).

[jclsn]

Sorry, my bad. I never figured you could commit to my fork and tried to build the master Pi kernel. I am still a bit new to Github. I am pulling the PR version now...

[jclsn]

Yes, it looks good. The iio device is visible again. Before merging I would like to play around with the overrides a bit more. This could take me some time, since I have four different sensors lying around here and I will take care of the analog ones first. So I don't really know if overlay is in usable state yet.

…

On Aug. 19 2021, at 8:17 pm, Jan Claußen ***@***.***> wrote: Ah yes, should be right. It is missing in the kernel though. Did you want me to push from the main Pi kernel tree? I guess not... On Aug. 19 2021, at 8:12 pm, Jan Claußen ***@***.***> wrote: > No, same issue as before. I can't access the interface of the device. The driver is not being loaded at all. I think the flags for adding the module are wrong. I can also not find the CONFIG_MAX30102=m in the config file. Was it removed again? > > When I was compiling before I checked that one by using xconfig. I am not sure about the actual name. I just tried it again with xconfig, but can't find it in bcm2711_deconfig afterwards. Strange... > On Aug. 19 2021, at 4:09 pm, Jan Claußen ***@***.***> wrote: > > The pull is taking quite long this time. I have 3d print a case for this thing. Will be back in three hours approximately and get back to you then! > > > > On Aug. 19 2021, at 4:02 pm, Phil Elwell ***@***.***> wrote: > > > > > > > > > There were two errors in the overlay - the sensor was being enabled by default, and the I2C interface wasn't being enabled for max30102. Try now. > > > — > > > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub (#4535 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AEW47N63HPP6LVC2WTARLD3T5UFITANCNFSM5CL7H6VA). > > > > > >

[pelwell]

There's no rush - take your time.

[jclsn]

I've been trying to compile the kernel again, but the Pi is somehow using 5.10.63 instead of 5.10.74. I then tried to upgrade the Pi kernel, fetch upstream sources to 5.10.92 and add the driver again, but when I booted almost no modules were loaded. Is there any way I can just add this module to the existing kernel without recompiling? I tried copying the max30102.ko into the right folder, but the module doesn't seem to be available.

Or how can I tell the Pi to boot the 5.10.74 kernel I compiled?

[jclsn]

Seems there was the kmod binary missing when copying the modules to the rootfs. I can load the module with modprobe now, but it doesn't last until the next boot. I also can't see the device, although I am pretty sure that it is connected right.

Any idea why modprobe doesn't last until the next boot? I think last time I did not have to load the module manually. Just setting

dtoverlay=max30102,int_pin=4

was enough.

[pelwell]

Any idea why modprobe doesn't last until the next boot?

Calls to modprobe are not persistent - modules will remain loaded until they are explicitly unloaded or the device is rebooted.

If you are asking why modprobe is necessary then it is probably because you haven't run depmod to update modules.alias. You can confirm whether the module is correctly registered with:

$ grep max30102 /lib/modules/`uname -r`/modules.alias

[jclsn]

Hmm output is

alias i2c:max30105 max30102
alias i2c:max30102 max30102
alias of:N*T*Cmaxim,max30105C* max30102
alias of:N*T*Cmaxim,max30105 max30102
alias of:N*T*Cmaxim,max30102C* max30102
alias of:N*T*Cmaxim,max30102 max30102

so I guess it works. The sensor isn't appearing in the sysfs though

I realized that the first time I installed the modules on the SD card there was a notification that depmod was missing. I then installed the kmod package and ran it again without errors. Does it maybe not work if it failed the first time?

[jclsn]

I also don't understand where the commits have gone. In my repository there is only the commit listed that I want to merge. I just wanted to fix the line in the readme you added, but I am a bit confused.

[jclsn]

Yeah, I don't know. I've recompiled and pushed files again to SD card but it doesn't work. The module is added to module.dep

kernel/drivers/iio/health/max30102.ko: kernel/drivers/iio/buffer/kfifo_buf.ko kernel/drivers/iio/industrialio.ko kernel/drivers/base/regmap/regmap-i2c.ko

Actually this sensor isn't important to the project anymore. I just wanted to get it to work for the sake of completeness, but it is too time-consuming.

[jclsn]

Well, I guess something went wrong with my installation on the Pi. Actually I already tested this successfully, so I guess it is good to merge. If there are some improvements I can make another PR.

[pelwell]

I had to fix a last minute cut and paste error - the README referred to the MAX17040 rather than the MAX30102), but it's merged now.

[jclsn]

Alright, I will see if the new sensor makes a difference when it arrives. I think I had a similar issue on Raspbian as well though. I mentioned that before the merge, but I was having a bad conscience, because I let this PR sit here for so long. I will ask the Yocto guys as well.

[timg236]

If you are using buildroot then it might be worth using systemd or at least devtmpfs eudev rather than init scripts

[jclsn]

No, I am using Yocto, not Buildroot. I am already using systemd on it. I will flash a Raspbian image today though, to see if that makes a difference.

…

On Nov. 8 2022, at 9:24 am, Tim Gover ***@***.***> wrote: If you are using buildroot then it might be worth using systemd or at least devtmpfs eudev rather than init. — Reply to this email directly, view it on GitHub (#4535 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AEW47NZG6DOQRVIJKEAJNLTWHIE4TANCNFSM5CL7H6VA). You are receiving this because you authored the thread.

[timg236]

Also check that the .dtbos on the sd card are up to date and match the ones from the kernel. It’s easy to end up with stale files. Just guesses though!

[jclsn]

So I just installed a fresh copy of Raspian and added

dtparam=i2c1=on
dtparam=i2c_arm=on
dtoverlay=max30102,int_pin=4

to the config.txt

I have exactly the same issues as on the Yocto image. The module is not being populated under i2c or iio...

I also tried hooking up a new sensor in case the old one here was broken. Same thing.

[pelwell]

I have one of these on order, but it will take about 3 weeks to arrive.

[jclsn]

Guess it wouldn’t help if I send you one of mine due to customs, would it? Anyway, three weeks are fine by me.

…

Am 14.11.2022 um 11:59 schrieb Phil Elwell ***@***.***>:  I have one of these on order, but it will take about 3 weeks to arrive. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[pelwell]

It probably depends where you are. If you were to mark the item as a gift (which it would be) and of low value (also true) then it shouldn't be held up much, but if 3 weeks doesn't sound awful then it's better to wait.

[jclsn]

It's fine. I will take care of other projects meanwhile. Thank you for taking care of it.

[pelwell]

The max30102 I ordered has arrived. Once I soldered on the headers and wired it up, and the driver loaded and probed as expected.

The only relevant line in config.txt is:

dtoverlay=i2c-sensor,max30102

I didn't specify int_pin=4 because that is the default, but it still works if you do.

I do, however, get a kernel crash when I try to read from the device - the active_scan_mask is NULL in the interrupt handler. Even with a patched driver and it never seems to get any measurements, but perhaps that's because I've only connected the SDA, SCL, INT, VIN and GND pins.

[pelwell]

Looking at the waveforms on a scope, the INT signal looks like a near clone of the SDA signal, as if there is coupling or even a short between the pins. As long as I keep the INT pin disconnected the driver seems to work. I'm putting this down to bad hardware or wiring - everything else seems to work as intended.

[jclsn]

Hmm strange that it doesn't work for me then. Maybe my Pi has a problem. I should try another one. Will see if I can make it this weekend. Schedule is full though

[jclsn]

Oh I just realized that I had the wrong line in config.txt

I had

dtoverlay=max30102

and not

dtoverlay=i2c-sensor, max30102

I am pretty sure that it used to be like that though. Weird. Anyway, I can now load the sensor and read from it without issues.

Thank your for the assistance! Glad we got it working.

[jclsn]

Still no idea where to find the actual data buffer. I can turn the LEDs on and off, but no idea where to find the actual ADC reading...