Support for SGP40 Sensors

Developers
1

I created a PR to add support for the SGP40 Sensor. I’m not a python pro, so I’m happy for any input. I’m also unsure about adding the klippy-requirement. it looks a bit “wild” to me to add a lib just to convert the raw value.

Link to the PR: sgp40: Add sgp40 support by meteyou · Pull Request #6738 · Klipper3d/klipper · GitHub

1 Like
2

If you look at the original code, there are just Python implementations, so there is no real need for external dependencies.

BTW,
Is it better than BME680?
They are the same type of sensors, and the VOC index is mostly useless without calibration under known conditions.

What is the purpose of that specific sensor here?
Strictly speaking, SGP40 is not a temperature sensor.
If you plan to use it in a filtration system or even in a chamber - the VOC index will be misleading.

According to the library code and the datasheet, it just shows you the difference from the average value of the past N hours.
So, just reloading the configuration is enough to show a polluted system as clean.

Maybe you do not even need that library in the first place.

1 Like
3

Thx for your feedback!

If you look at the original code, there are just Python implementations, so there is no real need for external dependencies.

I saw the “internal dependency”, but I could not find any example in the Klippy code for something like that. Where should i store the “VOCAlgorithm.py”?

The original lib was from here: DFRobot_SGP40/Python/raspberrypi/DFRobot_SGP40_VOCAlgorithm.py at master · DFRobot/DFRobot_SGP40 · GitHub

Is it better than BME680?
They are the same type of sensors, and the VOC index is mostly useless without calibration under known conditions.
What is the purpose of that specific sensor here?
Strictly speaking, SGP40 is not a temperature sensor.
If you plan to use it in a filtration system or even in a chamber - the VOC index will be misleading.

I just use this sensor in my Stealthmax Filter. One for “input air” and one for “output air”. So I use only use the relative values between these sensors to control the fan. I want to use a “display_template” to control a fan_generic with values from these 2 sensors. I just found it strange that this sensor is not directly supported in Klipper, so i have to import the files. so i thought i would create a PR for it directly.

4

FWIW, Sensirion is providing reference implementations here: Sensirion AG · GitHub

5

Thx! I also used this repo for the implementation: GitHub - Sensirion/python-i2c-sgp4x: The SGP40 is Sensirion’s new digital VOC (volatile organic compounds) sensor designed for easy integration into air purifiers or demand-controlled ventilation.

but it only reads the RAW value and doesn’t use any converter from RAW to VOC.

6

I’ve imported VOCAlgorithm.py and sgp40.py into my klipper and it’s works OK on my voron 2.4. Also I’ve created a macro to view sensor values. This sensor give you temp, humidity, raw voc data, and voc index.

BME680, I think that It is not sensitive to the vocs produced by our 3D printers

7

There are no kinds of VOCs and there is no VOC measurements.
Neither of these sensors can measure VOC.
To measure them there are some fancier like PMS5003

You literally measure the resistance of a wire (sensirion doc) in flame, where VOC + Oxygen makes it burn better.

The only difference is that the VOC index shows fancy meaningless numbers.
BME680 produces direct measurements of resistance and it is your job to map it or tune to real-world values in your environment. Ex: For tuned BME680 ~0kOm is heavily polluted and 1000kOm fresh air from outside.
(you can configure its temp/time of burn, to choose what to measure and how).

With SGP40 there is no configuration, actually just a 16-bit number, which can be mapped in the same way. The only difference is that by datasheet it looks reverse mapped, closer to 0 - cleaner.

image
image377×310 27.1 KB

Also, note some limitations:
image
image359×223 35.6 KB

So, again:

  • VOC Index - meaningless
  • You should not convert to a VOC Index if you wish to compare or measure something.
  • You should measure sensor values under known conditions to have an idea of what they mean.
  • To know if you really need temperature/humidity compensation - again it is preferred to measure raw values under known conditions.

There is no issue with an external VOC library because it is not needed.
There is no profit from the sensor if you do not spend time to at least get to know what it shows.

The only good analogy that I come up with, is the belt tensioner tool:

image
image450×332 27.6 KB

VOC sensors are really like this one. There is no general way to convert values from measurements in mm to real tension.
Or like a humidity sensor without temperature, you can say you have a 60% relative humidity and I have a 60% humidity, and they are very likely unequal underneath by several times in absolute humidity values.

If you want an analogy for the VOC index - imagine your thermistor will show the temperature difference between a cold start and “now”. Not 240 degree, just +220 degrees. You hit FIRMWARE_RESTART and now it is 0, and after cooldown -200.

You can spray the sensor with isopropyl alcohol, it is harmless, but you will get the idea of a “polluted” value from the sensor.