-
Notifications
You must be signed in to change notification settings - Fork 636
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for oximeter MAX30100 #2623
Comments
Internally, I2C .h wraps Wire, since it is the only available I2C API provided by the Core. I don't see any issues in c/p directly to the sensor class omitting the lib itself and extra code it introduces for sketch use-cases. No need to set up Wire, writers and readers are already implemented, big-endian / little-endian code as well. Don't forget the (c) info, obviously. |
Hello. Let's see if I understood your approach:
I don't think Wire is used anywhere else. |
see
removing begin() and setClock() might be enough, unless you also declare i2c .h funcs manually I would still suggest to take a look at a possibility of extracting some code into a single sensor class file, removing the lib dependency. Might be easier to debug in the future. |
Yes, it is probably better; by the way, it seems that the algorithms to calculate sp02 are not so trivial and there are variants (for example, this one seems to be quite a bit more complex than Oxullo's https://github.com/sparkfun/SparkFun_MAX3010x_Sensor_Library/tree/master/src ); a perzonalizaded version should be easier to maintain. |
https://github.com/sparkfun/SparkFun_MAX3010x_Sensor_Library/blob/72d5308df500ae1a64cc9d63e950c68c96dc78d5/examples/Example8_SPO2/Example8_SPO2.ino#L86 also mentions that it takes some time to gather all of the results provide a meaningful output |
The first 100 samples are for the algorithm to work properly (it needs to remove the DC component from the signal among other things); then it recalculates the Spo2 every 25 samples. The Sparkfun example is blocking
I don't see the problem with calculating the average, median, etc., in a standard way. |
Well, for the moment, I made the sensor code directly using the Sparkfun library, I included it in sensor.cpp and the build at least worked (I don't know if it is using a lot of memory; platformIO showed me Checking size .pio\build\nodemcu-lolin\firmware.elf I guess the next step should be to migrate the Sparkfun library code into MAX30100Sensor.h
|
Hm... I thought it would make some sense to re-use 'filtered' data storage to attempt to somewhat reduce number of buffers, but I have missed the part about the internal storage and the number of samples required.
pre() usually converts raw to actual values. tick() usually gathers the raw data, in this case it would read from the i2c (either all at once or split in batches). value() should preferably output already converted data
u32 is natively handled, no problem here. just watch out when allocating sensor class on stack and prefer heap (400bytes times two per instance) |
Description
I've been studying the possibility of giving support to the MAX30100 sensor; from what I've seen it should be very similar to the support given for DHT sensors; instead of temperature and humidity, oxygen percentage and pulses per minute should be reported (I wrote some code, I'll upload it later). My biggest doubt is which library to use. Of those I saw, the most suitable one seemed to me to be this one https://registry.platformio.org/libraries/oxullo/MAX30100lib
My doubt is if it can be used as it is under Espurna; this library directly uses Wire and I don't know if it generates any port problems or something similar (from what I've seen, Espurna doesn't use Wire for i2c connections).
Could this library be used directly? Or, would I have to use another one?
Thanks
Solution
No response
Alternatives
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: