Word count: 3734. Estimated reading time: 18 minutes.

Summary: The CFSensor XGZP6897D differential pressure sensor has been tested and compared to the Bosch BMP390 barometric pressure sensor. The results show that the XGZP6897D is stable, reliable, and good for its price, but it has a high noise level as a percentage of signal, which makes it less accurate than the BMP390. However, the XGZP6897D’s differential design eliminates the problem of absolute drift in barometric sensors, and it doubles the signal to be measured.

Friday 22 August 2025: 20:00.

Word count: 3734. Estimated reading time: 18 minutes.

Summary: The CFSensor XGZP6897D differential pressure sensor has been tested and compared to the Bosch BMP390 barometric pressure sensor. The results show that the XGZP6897D is stable, reliable, and good for its price, but it has a high noise level as a percentage of signal, which makes it less accurate than the BMP390. However, the XGZP6897D’s differential design eliminates the problem of absolute drift in barometric sensors, and it doubles the signal to be measured.

My how the summer has flown! You would wonder how it is possible to struggle to find the time to test differential pressure sensors when you’re unemployed, but it really has been a case of go, go, go these last two weeks. Here I am, hours before I depart for Czechia for the WG14 meeting, and I am only just now finishing up the last of my outstanding projects. I probably won’t sleep well tonight (too stressed about stuff remaining to get done), but tomorrow night I ought to sleep like a baby unless the hotel bed annoys me.

As you might gather, I have been quite busy, week before last I took the Fiido T2 Longtail down to my Dad’s house which is near Cork to create a new base station from which to explore. Last week I then took Henry and Julia on the back of it around Cork’s rather new cycle lane infrastructure whose high point culminated in a 65 km round trip to Haulbowline Island, which is where the Irish navy is based. We were on dedicated cycle lane infrastructure almost the entire trip, only falling back to roads between Monkstown and Ringaskiddy, and of course between my Dad’s house in Kerry Pike and Shandon. Here it is as a map:

Why Haulbowline Island? The bike’s battery can do maybe 80 km with the kids on the back, so 65 km gives a margin of safety. It needed 880 Wh to charge, so that might have been 800 Wh expended. I know on my own without the added weight of the kids I did 85 km and still had enough in the battery that I could have done a bit more. Also, Haulbowline Island is about where the dedicated cycle infrastructure stops – after that, it is country roads at best.

Whilst it’s great that there is dedicated cycling infrastructure at all now in Cork, I can’t say I think much of the stuff along the north quays in the city centre which requires constant stops and waits for cars. Once you get out towards the Marina Market though, then things get vastly better and the stretch of the converted Blackrock Railway line out to Mahon is truly spectacular in parts – eye achingly pretty as you zoom under old stone bridges with craggy rock sides and mature trees above you. The part after that from Rochestown to Passage West along the seafront isn’t half bad either especially on a sunny day, though I think the other side up to Blackrock Castle along the seafront still prettier again.

They’ve got some world class cycle paths there, and I look forward to them completing joining up the cycle path coming out of Crosshaven to the Cork City cycle paths, then you could jaunt down to Crosshaven possibly starting from the dedicated cycle path beginning in Ballincollig Regional Park, along seafront or within former railway for most of it i.e. away from cars. Might be about 45 km each way, much of it very pretty especially in warm weather.

Anyway, that’s all for next summer now I suspect. Myself and/or the kids did 430 km on that bike this summer according to its odometer. So maybe one tank of petrol in a car. I might get a bit more in during September if the weather remains nice, but I expect to likely not do more than 500 km this summer in total. That is still a fairly respectable distance for leisure rather than commuting travel I think.

The CFSensor XGZP6897D differential pressure sensor

The last time I wrote here in the series on my house build about pressure sensors it was April earlier this year. In that post I came away quite impressed with the Bosch BMP390 temperature and barometric pressure sensor, which for €4 inc VAT delivers +/- 3 Pa relative accuracy with a +/- 2 Pa stochastic noise. For a barometric pressure sensor – which isn’t designed to measure relative pressure differentials – that is very good for the money. In that post, I mentioned that the CFSensor XGZP6897D had in six months dropped from €45 to a tenner, which suddenly brought it into scope. A differential pressure sensor – as the name would imply – is exactly the correct sensor to use for measuring relative pressure differentials such as between the front and back of a fan. Here is one of those XGZP6897D sensors, I bought the packaging with the 2.54 mm spaced pins to make it easy to solder onto a breadboard:

A reminder of its claimed specification compared to the BMP390 sensor:

| | Noise | Relative accuracy | Absolute accuracy | Cost incl delivery | | | —– | —————– | —————– | —————— | | BMP390 barometric pressure sensor | 2 Pa | +/- 3 Pa | +/- 50 Pa | €4 | | XGZP6897D differential pressure sensor
(-500 Pa to +500 Pa model) | 25 Pa
(2.5% of range) | +/- 10 Pa
(1% of range) | n/a | €7 |

The noise and relative accuracy looks bad, but because this is a differential sensor, you can measure the difference between low and high pressure sides of a fan, rather than absolutely measure each side with its own barometric sensor. That then eliminates the problem of absolute drift in a barometric sensor, and it also doubles the signal to be measured.

As you may have noticed in the table above, since April it has dropped in price still further to €7, making it even more in scope at only 2x the cost of the Bosch sensor. At the time I didn’t know why, but now I can tell you it is because CFSensor have rather irritatingly silently swapped out the implementation without changing the model number. Yes, the new implementation has a completely incompatible i2c interface – different registers, different address, different mode of operation, even the values read come in a different bit format. Despite using identical model numbers. They are, in effect, completely different sensors at the software level and would require entirely separate drivers.

The ESPHome documentation for the XGZP68xx component hasn’t yet been updated to mention any of these shenanigans, so the first thing I did was fix those docs which can be found at https://github.com/esphome/esphome-docs/pull/5255. In short, it comes down to the part number:

• XGZP6897D001Kxxxx is the older non-C series, which appears at I²C address 0x6d and supplies a 24 bit signed integer for the pressure.
• XGZP6897DC001Kxxxx is the newer C series, which appears at I²C address 0x58 and supplied a 21 bit signed integer for the pressure using a completely different register numbering and layout.

Yes this is very stupid on the part of CFSensor, but worse is to come. Have a look at the sensors I received from Aliexpress:

These are all supposed to be -500 Pa to +500 Pa range sensors, and maybe they are (the one I’ve soldered onto the breadboard definitely is). But the part numbers are all over the place, and worse, none of them are listed on CFSensor’s current list of part numbers. Apparently according to the internet they like to iterate the part numbers frequently (which is fine, I suppose) and release datasheets to match. This iteration cycle is a few months at most. No, they do not produce a single list of all part numbers and which batch they belong to – you need to manually assemble that information by studying the two dozen or so datasheets, and manually constructing a spreadsheet of all the part numbers and which datasheet they refer to.

In short, I cannot tell quickly what pressure range those parts are, whether the Aliexpress vendor made a mistake or not, or indeed much else at all. The only thing I do know is they are non-C series sensors, which makes sense as surely stock is being cleared onto Aliexpress, which is why these sensors are suddenly so cheap.

I know Chinese vendors have a reputation for this kind of shitty confusing packaging stuff, but to be honest apart from the crap documentation and failure to change the god damn part number when you change the I²C address the datasheet is pretty well written and contains all the information you need, albeit in poorly translated English sometimes. I have seen far, far, worse.

Once you get the sensor hooked up and talking to ESPHome, your impression improves still further. This sensor is good for the money – it is stable, not flaky, over the few days I’ve been testing it it has been fairly unsurprising and definitely reliable. Again, I have seen far, far worse.

One issue with the ESPHome driver was that it did not support setting oversampling, so you always got the default of 4096x. The sensor supports up to 32768x oversampling, which makes a big difference to measurement quality reducing stochastic noise by about half, so I had to go improve the ESPHome driver which can be found at https://github.com/esphome/esphome/pull/10306.

Anyway, here is the testing rig:

I’ve attached two lengths of silicone pressure hose to the sensor which I’ve soldered onto a breadboard (I actually soldered two as you’ll notice in case one was a dud to save me having to break out the soldering stuff again). As before, the Bosch BMP390 remains taped to the side of the bilge fan, and I inserted the low pressure tube into the air intake and the high pressure tube into the air outlet while the fan ran at full speed on 12v, which is 9 m/s air flow. As usual, I recorded the readings over time, and I found:

| | Reading | Min-Max difference
across readings
(i.e. noise) | Min-Max percentage
of sensor range | Half min-max percentage
of reading | | | —–– | ———————————————————–– | ————————————— | ————————————— | | XGZP6897D Idling (over ten minutes) | 0 Pa | 0.573 Pa | 0.06% | n/a | | XGZP6897D High pressure tube in outlet, low pressure tube to atmosphere | 16.6 Pa | 10.44 Pa | 1.44% | 31% | | XGZP6897D High pressure tube in outlet, low pressure tube in inlet | 61.05 Pa | 23.87 Pa | 2.39% | 20% | | For comparison: BMP390 | 18.66 Pa | 3.833 Pa | n/a | 10% |

Obviously this fan is open to the air, so has the lowest possible static pressure differential (approx 37 Pa according to the BMP390). A noise level of 30% of the reading makes it hard to accurately control a fan in response. A 20% noise level is better, but to be honest, a 10% noise level is far better again. In the house’s future ventilation system, the pressure differential should be a good bit higher than 37 Pa, so the noise as a percentage of signal should significantly decrease.

There is more nuance to these readings however. You might have noticed that the XGZP6897D reads a bit less than the BMP390 for the single tube case, yet well more than twice for the dual tube case. What gives? Well, it turns out that the XGZP6897D is overly sensitive to low pressures in a similar way as I found with the BMP280 (the very cheap pressure sensor), which the BMP390 does not suffer from. Moreover, the XGZP6897D’s low pressure port is especially sensitive to pressures below atmosphere, giving a reading of ~40 Pa, whereas its high pressure port reads ~25 Pa in the fan inlet. For the fan outlet, I did not find any noticeable difference between the high pressure and low pressure ports, both read ~17 Pa.

This is why ~60 Pa gets read when both ports are in use if you connect the low pressure port to the inlet and the high pressure port to the outlet. If you flip them around from how they are supposed to be i.e. put high pressure port to the inlet and low pressure port to the outlet, you get ~40 Pa. Which I think is actually about accurate.

The reason that the high pressure port is the high pressure port is because it is protected against high pressures, though this only matters in practice for the high pressure range sensors (>= 50 kPa). I suspect that as a result, it gets a harder shell or something else which peforms better at ignoring atmospheric pressure. For the very low pressure range sensors, you absolutely could reverse the connection without problem as far as I can tell from the datasheet which claims that you can apply up to 2500 Pa (5x) to either port of this +/- 500 Pa range sensor safely.

In the end, the CFSensor XGZP6897D costs €7 while an equivalent sensor from Honeywell or Sensiron costs €30 (which is hugely down from over €100 last year), or from Kele about €85. I would be fairly sure neither of those treats pressures less than atmosphere inaccurately, and as we will see below, they claim much better accuracy than the CFSensor sensors.

The bilge fan’s maximum static pressure

Many posts here in the past few months have wondered what the bilge fan’s maximum static pressure us, as its manufacturer gave no claims for anything bar air flow (which we found from testing met those claims). We know from last post that if run on 12v in free air, you get 9 metres per second of airflow, which is 254 m3/hr, which is correct for 12v instead of 24v operation. I did say last post I found mention in a review on US Amazon that its maximum static pressure at 24v is 225 Pa, which I think might turn into 70 Pa at 12v. Using that 70 Pa guesstimate, I came up with an estimated air leakage for the dual Naber Thermobox non-return valve solution as 5.55 m3/hr at 50 Pa. Let’s see if we can do better using this differential pressure sensor!

Firstly I taped as tight as I could make it a plastic sheet over one end of the fan:

It probably leaks a little, but not too bad. I then turned the fan on full. The XGZP6897D read a very stable mean of 38.65 Pa, min was 37.02 and max was 40.02. The min-max difference was only 3 Pa, or +/- 3.9% of the reading. Much better than before when there was airflow! It would seem that the XGZP6897D does not like airflow much, but if there is no airflow and just static pressure, it really is quite low noise.

The BMP390, which I had intended as the control sensor, it did not do well at all. It began at 1009.321 hPa. When I turned on the fan, it rapidly went up to 1009.545 hPa, but it then just kept on rising. After ninety seconds it breached 1010 Pa, after which I cut the power. It then took twenty minutes to get back to atmospheric pressure:

• +5 mins: 1009.595 hPa
• +10 mins: 1009.387 hPa
• +15 mins: 1009.349 hPa
• +20 mins: 1009.341 hPa (but now rising slowly, because I’m fairly sure atmospheric pressure is currently rising)

I’ll be honest, I was very surprised to see this happen, so I ran the test for a second time to make sure and to see if there was ever a point at which the BMP390 sensor might stop rising.

• +0 mins: 1009.348 hPa
• +5 mins: 1010.380 hPa
• +10 mins: 1010.447 hPa (it seems to stabilise at about seven minutes). I now turn the fan OFF.
• +15 mins: 1009.419 hPa
• +20 mins: 1009.249 hPa (and falling slowly, I think we’ve reached atmospheric pressure)

Obviously a 110 Pa static pressure is improbable, plus it took many minutes for the sensor to stop raising the value, though I find the 39 Pa read by the XGZP6897D a bit disappointing though more plausible. Interestingly, if you add the other tube to the inlet, it rises to 45 Pa so I suspect there must be more air leakage happening than I can notice – after all, if it were truly fully sealed, the fan should be just cavitating and not drawing any air.

I then did even more testing, and I discovered that the BMP390 only starts doing this monotonic reading rise once the static pressure reaches about 25 Pa. This is why I never noticed it before – the open fan doesn’t generate more than 20 Pa pressure, so this behaviour never turned up before. As to why the BMP390 does this, I can only speculate: perhaps it has a macro sensor and a micro sensor, and if the micro sensor exceeds range then its firmware starts incrementing offsets until the micro sensor stops being out of range?

In any case, the BMP390 adjusts too slowly for pressures above 25 Pa difference from atmospheric to be useful for controlling fan speeds. I guess the sole option remaining is the XGZP6897D or some other differential pressure sensor.

Conclusions

The first item is that my air leakage estimation for the dual Naber Thermobox was underestimated. If the maximum static pressure of this fan is more like 50 Pa than 70 Pa, then we actually had an air leakage rate of 7.168 m3/hr. That means two of them would contribute about 2.85% to whole house air leakage, which is still acceptable I think.

The second item is that this research has turned out to be very valuable. I was going to go off and base the ventilation boost fan speed control on barometric pressure sensors. Now I know those can’t possibly work for this use case. I have to use a differential pressure sensor, which is now the cheapest solution to estimating air flow entering each inlet, and exiting each outlet.

I was thinking what if I put one hose before the fan and leave the other hose exposed to the room? If the fan is off, there will be a slight pressure drop due to the fan blocking air flow. One could, theoretically, calculate the air flow from that small pressure drop. If the fan is running, the pressure before the fan would drop, and the pressure in the room would slightly increase. I am minded that single port CFSensor pressure sensors are currently going for about €4 inc VAT on Aliexpress. That would nearly halve the cost.

Or would it be better to put each hose each side of the fan? Then when the fan is running, the pressure differential would be much higher, so how much work the fan is doing would be more accurate to estimate. But then how do you estimate how much air flow is actually going into the room? The greater the air flow, the greater the differential from the room pressure.

Obviously you could fit two sensors here, but that feels overkill and unnecessary expense and hassle wiring in more pipes. I don’t know on that one.

Are there better sensors than the XGZP6897D for me to test? From what ESPHome supports:

• Honeywell ABP i2c sensors (starts from 6,000 Pa upwards, no use for HVAC)
• NPI-19 (starts from 17,000 Pa upwards, no use for HVAC)
• TE-M3200 (starts from 400,000 Pa upwards, no use for HVAC)
• Honeywell ABP 2 i2c sensors (starts from 250 Pa upwards), costs about €20, single port so measures against atmosphere. A dual port model starts from 600 Pa upwards and costs about €30. Accuracy is 1.5% with long term stability of +/- 0.25% of range.
• Sensirion SDP31 i2c sensors (starts from 500 Pa upwards), costs about €30. Accuracy is 3% with long term stability of +/- 0.1 Pa.

I’m a bit hesitant to be spending an additional €30 per ventilation inlet and outlet in the house. We have a fair few of them, so it would add up quickly.

Also, once you’re into the €30 price range, why arse around with differential pressure sensors when you can fit an air velocity sensor directly and call it a day? The FS3000 costs about €20, unfortunately its SMD package would be a pain to hand solder. Its breakout board off Aliexpress is about €55 inc VAT delivered. That’s very pricey if fitting one per inlet and outlet, but it might be an idea to fit a few in select places, then you can figure out how much air flow is going down various tee junctions of the ventilation. Accuracy is about +/- 5%, and as far as I can tell all near substitutes are far more expensive again. I do note that at the time of reading that in some places in the US the breakout board price has dropped to US$20, if so, maybe the Euro price will be dropping shortly. Definitely one to watch out for.

If the price does come down, I ought to get one and test it. There are very few reviews of that sensor, the only obvious one at https://www.yoctopuce.com/EN/article/testing-the-renesas-fs3000-air-speed-sensor reckons this sensor doesn’t work well. So we may be back to differential pressure sensors in the future anyway.

What’s next?

At the end of September I’m taking a solo holiday in Spain for ten days. I’m going to go see the families of two people I knew from back when I lived in Madrid – one still in Madrid, the other in Bilbao. As they can only see me at weekends, I’ll be taking a road trip across Spain during the weekdays during which I’ll be mainly visiting ancient Roman shit, but I’ll also get in some spectacular nature. It should be fun, it should also refresh my long neglected Spanish speaking skills and I’ll get to see people I haven’t seen in well over a decade, plus their children!

Before that, the kids will have returned from school so I’ll have no excuse to not (a) get the services layout for the house completed (b) actually start losing weight, as I’ll be going tee total from September onwards as I do every year. There will also be two posts coming here on these topics:

The Huawei D2 watch, which as of today replaced my Amazfit GTS 2 Mini watch which I’ve had since 2021 (its battery swelled and the screen popped off, so I’ll have some cool pictures of its insides). 1.

The Google Pixel 9 Pro phone, which will be replacing my very long standing current phone the Samsung Galaxy S10 which has been my daily driver since – believe it or not – since 2020, making it five years long in the tooth. Which is by far and away the longest I’ve ever used a single phone, for reasons I’ll get into in that post. Indeed, I may have to write two posts on the new phone, because I have replaced its firmware with https://grapheneos.org/, and I have come to a number of realisations about that OS in the last few days of playing with it which I think I ought to write down for later reference.

Anyway, all that is for after I get back from Czechia which will be week after next. Maybe see you then!

#house