xgzp68xx component is missing oversampling support

[ned14]

Component name

xgzp68xx

Link to component documentation on our website

https://esphome.io/components/sensor/xgzp68xx.html

Describe the enhancement

https://cfsensor.com/wp-content/uploads/2022/11/XGZP6897D-Pressure-Sensor-V3.1.pdf shows that the sensor can perform oversampling for both pressure and temperature. The current driver code at https://github.com/esphome/esphome/blob/dev/esphome/components/xgzp68xx/xgzp68xx.cpp does not utilise this support however.

Use cases

Without oversampling, the sensor experiences very considerable noise. Readings jump around about about +/- 10 Pa. This would be similar to the Bosch series of barometric sensors - you really do need oversampling turned on to get usable stability in readings.

Anything else?

In my opinion, there is too much arithmetic division by non-constants in the current driver source code. Division is very slow on CPUs like the ESP32. There is also use of pow() for constants which should be instead stored into static const vars, or better constexpr (the compiler cannot constant fold C functions which can affect errno). The driver source code in general seems to deviate quite far from the datasheet, though I'd be the first to say that the datasheet documentation is very unclear.

The documentation says that the default K value of 4096 is suitable for +/- 500 Pa sensors. I have exactly one of those sensors, and I had to use a K value of 16384 to get the correct pressure range. I verified that the sensor model is definitely a +/- 500 Pa sensor using a separate pressure sensor.

I think the driver implementation code at https://github.com/fanfanlatulipe26/XGZP6897D/blob/main/src/XGZP6897D.cpp is much better written, better matches the datasheet, and the current driver code ought to be replaced with that.

[github-actions[bot]]

🏷️ I've automatically added the component: xgzp68xx label to help categorize this feature request.

[ned14]

I went ahead and implemented a solution to this:

• ESPHome PR: Add oversampling configuration to xgzp68xx. Also tidy up implementation. esphome#10306
• Docs PR: Update docs for xgzp68xx component. esphome-docs#5255

[gcormier]

The K value comes from the datasheet. What is your sensor part number?

[ned14]

The Keles are similarly priced to Honeywells yes?

I'm in the unusual position that I can insert the BMP390 directly into the airflow in my use case. We have rectangular phenolic foam ducting with a 100 mm fan going into it, so it's easy to cut a hole for the wires for the BMP390.

I agree that for many other use cases, the barbs are the issue, though perhaps an airtight solution for a BMP390 could be 3d printed on a good enough 3d printer? I will need tubes in other areas of my solution, but those have plenty of pressure difference so the noise on the XGZP6897D will be very acceptable.

BTW I took a photo of my Aliexpress sourced XGZP6897D's which is attached. They are supposed to be the -500 to +500 Pa model. As you can see, the part numbers are all over the place. The one I soldered in I didn't look at the part number beforehand so I've no idea what it is, but I've independently verified it is definitely some -500 to +500 Pa model.

[gcormier]

001D is probably the +/- 500.

They could also be damaged. There is a pressure range they will gain a permanent offset, and then a higher pressure they are damaged.

[ned14]

The one I've soldered on appears to have a different initial offset every time I power it on. I've seen -40 Pa, +5 Pa, -2 Pa and a few others. I have a theory it's to do with the temperature compensation not quite working right. Or they may be sensitive to strong light.

I've also noticed if I "shock" it by blowing into the tube repeatedly, the offset can move. I'm not going full force or anything, but I am exceeding its maximum reading by a bit. They seem to have a "memory". They appear to have been designed to work best with static airflow and slowly changing pressures. And I suspect the higher pressure range sensors work much better than the low pressure range sensors, but I don't have any to test.

I have seen much worse sensors than these though. Everything with these sensors so far I believe I can mitigate in software. So far, the device always responds, it always produces reasonable numbers, it doesn't flake out. That's better than some. Obviously I've only been testing for a few days, not months nor years in the field, but so far so good with these.

[gcormier]

Once I get a supply I'm happy to send you a fully assembled board for free if you want to continue testing and documenting your findings :) Just got back and read through your posts on your blog, interesting stuff!

[ned14]

You're referring to the non-linear sensor response as documented at https://www.nedprod.com/Niall_stuff/vdiary/archives/1755892849.html?

Yes it was interesting. It may of course just be the specific sensor module I tested, but I have noticed this over sensitivity to pressures below atmosphere in many if not most of the cheap sensors I've tested in the past. I suppose in many use cases, you'd have pressure A above atmosphere which is greater or less than pressure B above atmosphere, but in either case all pressures before the sensor are always above atmosphere.

I'll take free stuff any day, but I would caution that stuff coming into the EU from outside can easily attract a substantial import duty charge if the paperwork isn't done correctly. I once received out of the blue a donation from Intel of a bunch of very fancy stuff in thanks for some help I gave them, but the import duty charge was hundreds of euro, so I reluctantly had to send them back because ultimately I didn't need those very fancy items. It was very nice of them, very appreciated, but I do wish they had asked first so we could have avoided the customs charge.

[ned14]

Main PR esphome/esphome#10306 has been updated to undo the v2 renaming.