Welcome to ned Productions (non-commercial personal website, for commercial company see ned Productions Limited). Please choose an item you are interested in on the left hand side, or continue down for Niall’s virtual diary.
Niall’s virtual diary:
Started all the way back in 1998 when there was no word “blog” yet, hence “virtual diary”.
Original content has undergone multiple conversions Microsoft FrontPage => Microsoft Expression Web, legacy HTML tag soup => XHTML, XHTML => Markdown, and with a ‘various codepages’ => UTF-8 conversion for good measure. Some content, especially the older stuff, may not have entirely survived intact, especially in terms of broken links or images.
- A biography of me is here if you want to get a quick overview of who I am
- An archive of prior virtual diary entries are available here
- For a deep, meaningful moment, watch this dialogue (needs a video player), or for something which plays with your perception, check out this picture. Try moving your eyes around - are those circles rotating???
Latest entries: 
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).
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!
- Lose weight
- On this I have been spectacularly unsuccessful, I have actually slightly
gained weight
.
- On this I have been spectacularly unsuccessful, I have actually slightly
gained weight
- Do stuff with the kids I couldn’t normally do
- On this I have been very successful, they are quite sick of how much time they have been spending with me! Over 250 km with the kids on the back of the Fiido T2 Longtail and counting!
- Move ISO standards committees
- Four major paper proposals written for the WG14 meeting in August, and I am all set for the trip and meeting. I wish I had written more papers, but I think four big papers is still pretty good.
- Clear project backlogs
- I have done absolutely nothing on the 3D services layout. I now expect I’ll have to force myself to do those as if a day job after the kids go back to school. I have cleared all but one of the house build solutions testings however, so I’m going to call this a partial success.
I guess that’s an overall score of about two thirds successful? I am a bit annoyed about the lack of weight loss as I’ve been starving myself. But as mentioned last post, those trips abroad with all the nice food and all the beer from it being an unusually nice summer for Ireland I think has more than made up for calories. I expect to go completely tee total as I usually do after Megan’s birthday until Christmas, so maybe the weight will fall off then?
Regarding new employment, I haven’t been trying to find new work, but I have been watching ever more people I’ve known for years also enter the jobs market. Lots of very senior, very talented, developers. I haven’t seen it this bad in tech since the 2009 recession. If it keeps going like this, it’s going to be as bad as the 2001 recession which was especially hard on the tech industry. Anyway I’ll worry about all that next month.
This post will be about testing my solution to a long standing problem in certified Passive Houses: kitchen cooking fumes extraction.
The problem
Certified Passive House for my climate zone requires the total outer fabric u-value to be under 0.20 W/m2K or so (i.e. all windows, walls, roof, floor etc when all put together the total thermal transmittance must be below 0.2 watts per square meter per degree of temperature difference). Additionally, airtightness must be better than 0.6 indoor air changes per hour. For both these reasons, kitchen cooking fumes extraction to the outside is problematic:
Most kitchen extractor vents have a u-value around 25 W/m2K – though this is a 150 or 125 mm diameter region, so it won’t impact the building fabric average by much. Where you get more trouble is from the thermal bridging as you effectively have a hole to the outside – this causes condensation and mould unless you put perhaps 50 mm of insulation around the duct. All that insulation is unwieldy, especially if trying to route it in a kitchen e.g. behind cabinets.
Kitchen extractor vents should have a non-return valve to prevent outdoor wind blowing air into the kitchen through the extractor, which if not prevented would fill your house with lovely stale cooking smells as well as cold air. Most of these non-return valves don’t really close properly, you’ll often hear them banging with wind gusts outside. This means they ruin the excellent air tightness of your Passive House.
For these reasons the Passive House Institute recommends recirculating cooker hoods. These pass the fumes through a filter before releasing them back into the home. I’ve never been keen on these – from my own testing I have found the thin insubstantial and cheap filters typically fitted to cooker hoods saturate within a few weeks. And nobody is going to be changing these filters every few weeks in practice. If you’re going to do this right, you should fit commercial kitchen grade fume filtration which does actually work. Expect to spend thousands on such an installation, and it is noisy and uses lots of electricity to run.
The Naber Thermobox non-return valve
That made me wonder if a decent thermally broken extractor non-return valve could be possible? I had found the Naber Thermobox which is an affordable, thermally broken unit costing €48 inc VAT at the time of writing. It consists of three ABS plastic non-return valves with two 20 mm thick pockets of trapped air between them. Naber claim that this unit has a u-value of 2.2 W/m2K. They also claim that it will only open with 65 Pa of air pressure, which is implemented using two small magnets per flap to ensure that the flap is either completely closed or completely open – it cannot be slightly open, or get flapped open and closed by wind gusts. Theoretically, you could even do the air tightness blower door test without these covered because the air tightness test runs at 50 Pa, so it won’t open the Naber unit. It’s probably easier to show you a video of it than describe it in words:
The Naber Thermobox insulated non-return valve
This looks promising, though I note from inspection that it isn’t particularly air tight – the plastic flaps do have slight gaps around them as they need to permit some air to pass in order to whip them open when the extractor fan turns on.
There is something else cool about Naber’s design: each layer in these units simply snaps together. This lets you amalgamate them easily like this:

And now I have a five chambered insulated non-return valve which ought to be significantly better than a two chambered edition both thermally, and for air tightness.
Thermally broken kitchen extractor testing rig
I purchased from an online German vendor a bunch of Naber ventilation kit (enough to test if my planned duct routing under the kitchen cabinets would work – I now know it will). One of the items was a 125 mm diameter half metre long PVC pipe suitable for penetrating the wall of the house (which is 0.5 metres thick if excluding the interior service cavity). To mimic the cellulose insulation which would surround it, I fitted a roll of 40 mm thick Aluminium Silicate Ceramic Fibre blanket which I got off Amazon at €66 inc VAT per sqm (which is about 0.1 W/mK thermal conductivity which isn’t great, however its singular advantage is it is happy well past 1000 C so it’s the right stuff to use for chimney flues etc). Because the fibre blanket is itchy, I then wrapped that in Aluminium foil covered bubble wrap which is good at reflecting heat:

I then stuck Megan’s hair dryer in one end, and used my thermal camera to measure what heat was going in and what transmitted through. Unfortunately on my first attempt I didn’t realise just how hot her hair dryer gets when blowing into a highly insulated tight space and I melted my first Thermobox unit which was fifty euro wasted:

Luckily I had another two of those units for testing and the PVC duct while it warped from the heat it was sufficient for further testing. I used the lowest heat setting after this!
Initial testing revealed an issue: the hair dryer blows with considerable air pressure, and I suspected some of the heat was being unreasonably blown through the unit. So I came up with a ‘sock’ made out of greaseproof paper:

The reason I couldn’t use tinfoil is because it reflects infrared and therefore makes the thermal camera useless. The greaseproof paper is meant to be used in ovens, and it worked a treat: the hair dryer blew into the greaseproof paper sock, it heated up to 65 C or so. That was against the front of the non-return value, so some of the heat shined onto the unit under test plus the air around heated up. That then heated the first layer of ABS plastic of the unit, which then shines heat onto the air pocket and the next plastic layer behind it. As the heat cannot escape outside the sides due to the thick insulation, and the hair dryer side reaches a steady state of hot quickly enough, you can then measure how long it takes for how much heat to pass through the unit. From that, one can theoretically calculate what the thermal conductivity of the unit is.
The other part of the testing is for air tightness. For this I put one of the bilge fans in one end snug and for the other end I made a paper hole to focus all the airflow into the right size for my anemometer to measure, as the little air getting through the unit was just on the cusp of not being readable:


Thermal testing
I did two runs – I should have done more, but they are incredibly boring and tedious to do. They involve taking a photo with the thermal camera every minute. For the single unit (two air compartments) case, it wasn’t too bad: it took about fifteen minutes for the cold end to reach 25 C having started from 20.6 C. The reason I chose 25 C as the test end point is because the temperature increase (4.4 C) is approximately 10% of the hot to cold end differential (44 C), and if the cold end gets much warmer than the surrounding air then convection will carry off heat which affects the measurements.
The thermal camera does get a bit of noise at the sub degree level, but the trend is clear over time – the cold end gets warmer.
For the double unit (five air compartments) case, the testing was very considerably more tedious:
Yup, that is a full ninety minutes of testing to reach 25 C. Very, very boring to do, but I did catch up on all my internet reading I suppose. Here is a sped up time lapse of the thermal photos:
Ninety minutes of thermal photos in under one minute!
I reckon it took a good forty minutes before any heating around the top of the non-return valve becomes obvious in that video.
Straight off from that alone one can deduce that the five compartment return valve is five times more insulating than the two compartment return valve. In case you’re wondering if six non-return valves open easily when the extractor fan starts up:
If you look carefully at the design, each of the plastic flaps has a little ‘foot’ on its back designed to smack into the next layer of flap behind it. So when the front flaps open, they smack into the next layer which knocks them off their magnetic closed state i.e. opening cascades. Sellotaping two units together doesn’t affect this – each of the five layers of non return value behind the front layer open in turn.
Finally, some pictures of the hot end to round out this section:




Air tightness testing
I already showed you how I did the test above, and you could even make out a measurement. The bilge fan, which is a 24v model, but I ran it at 12v which pushes 9 m/s of air if left free:

If the fan is tightly inserted into one end of the pipe with the five air compartments non-return valve inside, I measure 0.6 m/s of air getting through a hole with diameter 65 mm:

Which is 0.002 m3 of air per second, or 7.168 m3 of air per hour. There will be 806 m3 of air in the house, this means we can leak no more than 483 m3 of air per hour at 50 Pa. This would mean that the five compartment unit should be well within Passive House air leakage, but things do depend on what static pressure is being generated by the fan outside the unit.
If when left free the bilge fan it moves 9 m/sec of air through a 100 mm diameter pipe, that is 254 m3/hr (it does about 450 m3/hr if running off 24v, so this seems about right – air flow is proportional to fan speed, so you get ~56% of max air flow on 12v instead of 24v). The manufacturer of the Seaflo fan doesn’t provide static pressure ratings (and it is hard for me to measure those until I get the differential pressure sensors up and working), but I did find a review on US Amazon where the guy reckons 0.89 inches of static pressure, which is 225 Pa. Static pressure is negatively related to air flow squared, so halving pressure only reduces air flow by one quarter. Therefore, if the fan is turning at 56% of full speed, you would expect static pressure to drop to 70 Pa.
Therefore, as a rough guesstimate, that 7.168 m3/hr at 70 Pa would be 5.55 m3/hr at 50 Pa. This would be 1.1% of the maximum air leakage allowed, which seems acceptable, even though in my specific case I’ll actually have two of these ducts – one for extraction, one for make up air to more rapidly purge the kitchen of smoke. Even then, both those ducts should contribute no more than 2.5% to whole house air leakage.
More (but harder) maths …
We have a probable air tightness measurement for the doubled up Naber Thermobox non-return valve, but can we calculate a thermal conductivity?
The formula for the rate of heat flow is:
We know the area of the unit to be 0.01227 m2 as it has a 125 mm diameter. For the two compartment test, it is 0.055 m long and the temperature difference was 44 C. Rearranging:
Simplifying:
The two compartment unit claims a u-value of 2.2 W/m2K and therefore one would expect a ~1.2 watt heat flow, which feels plausible. Let’s see if we also saw that during testing …
The thermal camera measures the surface of the final ABS plastic flap, so if ABS plastic has a heat capacity of 1500 J/kgK, a density of 1115 kg/m3, and the flaps in our case are 1 mm thick, I reckon it would require 1673 joules to raise a 1 m2 sheet one millimetre thick by one degree celsius. Or, put another way, if one applied 1673 watts to that sheet, its temperature would rise by 1C per second. For our much smaller sheet, that becomes 20.52 joules per degree.
We know it took 780 seconds for our final flap to rise by 4 degrees, therefore that was 195 seconds per degree, or 0.005128 degrees per second. This implies a heat flow of 0.11 watts, which means our testing is about a factor of ten better than the manufacturer claimed value.
Losses to convection to outside air are maybe 0.06 watts per degree above ambient air which isn’t enough to remotely close the gap.
Let’s now look at the five chambered unit: firstly, if a two chambered unit 0.055 m long has a u-value of 2.2 W/m2K, that would imply a five chambered unit 0.125 m long would have a u-value upper bound of 0.986 W/m2K. However, most of the insulation will come from the air (0.026 W/mK) versus the ABS plastic flaps (0.1 W/mK) and we have 2.5 times the number of air chambers. So I would suggest a u-value lower bound of 0.775 W/m2K. With a 37 C temperature difference, that is a heat flow between 0.352 watts and 0.448 watts which is 3.4 times better and 2.7 times better than the two chamber unit respectively. This is still rather lower than expected given my second test took five times longer than my first test, but let’s keep going by stating the heat flow equation for our second test:
Simplifying:
This time it took 5160 seconds for our final flap to rise by 2.6 degrees, therefore 0.0005039 degrees per second. This implies a heat flow of 0.01 watts, which is even more confusing because this test took five times longer than the first test, not ten times longer. It also implies a test unit u-value of 0.022 W/m2K which is plainly ridiculous.
I think I must surely have either a mistake in my maths or I made some mistake during testing. Quite frustrating after all the effort invested!
Conclusion
I suppose at least I discovered that the Naber Thermobox is not worse than manufacturer claims for thermal conductivity, and I probably did determine a reasonably accurate figure for air tightness which is useful, as the manufacturer said nothing about that aspect of the unit.
Obviously it’ll be the five chambered unit that I’ll be fitting. It should have a u-value a good bit below 1 W/m2K and an air leakage rate of around 5 m3/hr at 50 Pa. Those should enable reduced thickness insulation around the ducts, which will make routing these ducts underneath and behind the kitchen cabinets tractable, as I can only really allow for 25 mm of insulation – 50 mm just won’t fit.
Theoretically speaking, the non return valve should be installed close to the outside of the building to minimise thermal bridging. However there is a superior alternative – one could fit one half on the outside, and the other half maybe about half way through the wall. This increases the thickness of the pocket of air trapped between the two, improving insulation. I reckon it could improve the total assembly u-value by around 10%. What I don’t know is whether the flaps would whip open as well, as when they are together the little feet create a cascade open and I can see that a second nearly airtight seal behind the first could create a lack of pressure shock to whip open the second unit.
Thankfully, these Naber units are easy to install and remove – you just twist them in and out of place. So I can experiment once the house is built. It also means if they ever get clogged with grease, or the plastic gets worn down, or anything else goes wrong with them, they are dead easy to remove and repair or replace.
All in all I think I’m very happy with this affordable solution to extracting cooking fumes without ruining passive house.
What’s next?
Obviously differential pressure sensor testing is the next big task, and as we’re handily getting through August it’s beginning to feel urgent. I’ll endeavour to get it done by the end of this weekend, though it may be a few days into next week for me to write everything up.
Still, forwards we proceed as everything I get done now is one less thing to do later. And I have been getting in a lot of extra time with the kids by doing Irish tourist day trips – for the most arduous of our many recent day trips I made Clara and Henry climb to Coumshingaun Lough which is 2 km along the Earth’s surface, but also 250 metres upwards a steep, slippy incline. The weather involved periodic bursts of heavy rain and howling winds, so they weren’t entirely happy by the time they got to the top even with views like this:

Me, I was very glad to have finally crossed that one off my list. It was well worth the climb and suffering in my opinion, it is just stunning up there. We’ve done most things within an hour’s drive from home, but we have a long way to go on the list of things within ninety minutes drive. Ireland really is amazing for that type of tourism – it’s so much more authentic than what Amsterdam has become, where its centre has become more like a theme park pastiche of itself than what I remember of it from the 1990s. Thankfully, if you walk about 45 minutes away from the centre real genuine true Amsterdam is still there as I remember it – despite even out there having a lot of foreign tourists milling around. But, like with the many foreign tourists also climbing with us to Coumshingaun Lough, in the outskirts of Amsterdam the tourists add rather than subtract from the place as they do in the centre of Amsterdam. I haven’t been to London in well over a decade now, I expect it to also suffer from overtourism, but I’ll find out next week.
Last post in the series on my house build I said I have these three projects remaining awaiting testing and writeup here:
- Differential pressure sensor testing.
- Thermally broken kitchen extractor testing.
- Radar human presence sensor testing.
Today’s post will be mainly about human presence sensors. I have begun the other two – I have already accidentally melted a part of the test assembly for the thermally broken kitchen extractor, and I have soldered up the breadboards for the differential pressure sensor testing. But before I get onto human presence sensors, I mentioned last post that we ended up purchasing a Fiido D11 2025 edition for Megan’s commute bike, so let’s do that first.
Fiido D11 bike (2025 edition)
You may find reading my post on choosing an electric bike useful to read first, particularly at the end where I compare all the currently available foldable ‘lightweight’ electric bicycles currently available for under the €1,500 Cycle to Work scheme Revenue budget limit. The D11 2025 edition is available for under €1,000 inc VAT delivered. The 2025 edition only launched in July, and we were one of the first to get one in the world.

Megan's Fiido D11 commute bike folded up in the hallway
I wouldn’t call this bike light at around 23 kg. It’s heavy and awkward to lift even when folded. But it does fit into the boot of our cars, which is useful. Ride quality is unsurprisingly rough with the twenty inch diameter tyres. Handling is like all folding bikes – not great – but it is acceptable, and the folding locks are both tight and secure with no give nor rattle. The 36v based electric motor is just about powerful enough, and you will need to help it going up steep hills. Its pedal torque sensor is the same model as on my T2 Longtail, and therefore you get the same oscillating power delivery which is irritating.
Those are all the middling points. In terms of strong positives, the battery life is indeed more than plenty – Megan only charges it once per week and she’d do about 18 km per day. So it certainly can do 80 km on a single charge. The tail light on it being mounted high under the saddle works very well. The electric motor does genuinely make commuting far more pleasant, especially on the steep hill up to home on the way back.
The biggest negative is without doubt the brakes. They’re cheap and they don’t work well – the stopping distance is lousy. I wish they’d fit traditional rim V-shaped brakes at this price point, as they’re simply better than cheap hydraulic brakes. So long as you don’t go fast, the poor stopping distance is acceptable, but I think Fiido missed a trick here as a better bike was possible for even less cost and weight – just fit rim brakes.
I haven’t tried this bike with the EU speed limits removed, but to be honest the power system is sufficiently weak it wouldn’t get much above 25 kph anyway on the flat. Add any wind and you definitely won’t be getting above 25 kph without you helping it.
Megan is pleased with the bike, and I suppose so am I for the money. I would have preferred the ADO Air 20 Pro which costs €1,499 everywhere in Europe except Ireland, where it costs €1,799. I think the ADO would be the better folding bike albeit for 50% more cost than the Fiido.
I just wish Fiido had put better brakes on the D11. I’m not asking for the monster brakes that the T2 Longtail has, but something less shit than on the D11 would be a big gain.
Incidentally, the T2 Longtail has been busy taking my children places during the summer so far. Here it is resting after taking us to a playground 20 km away, and at the summit of Bweengduff mountain:


It was an especially hot day that day for Ireland at 28 C, so being able to tootle along at a nice refreshing clip was greatly appreciated by both myself and the kids at the time.
Getting to the top of Bweengduff mountain it gave out and refused to do further work due to overheating a short push of the bicycle from the summit. In fairness, it took us nearly to the top. It also very much took us down at speed on gravel, I was being extra careful due to the kids on the back, but boy that bike is a surprisingly excellent gravel bike. The brakes had to be on almost continuously to keep us under 50 kph, and they were so hot at the bottom of the mountain that they were clacking from metal expansion. What a bike! I’m looking forward to taking the kids to other places on it when we get back from London.
Human presence detection sensors
I’ve mentioned these on and off throughout the past four years on here, but I don’t think I’ve done a dedicated post before this. Human presence detection sensor modules suitable for operation by an ESP32 or Raspberry Pi come in many implementation techniques:
Passive infrared (like burglar alarm sensors or flood light sensors) e.g. HC-SR501.
- Characteristics: Range 7m when new (but shrinks with age); 120x120 degree field of view.
- Pros: a few euro of cost; works outdoors and in the rain; widest field of view; can disambiguate humans (or rather, warm moving things).
- Cons: needs a third of a watt power to work; they need movement over a fair distance to activate; they can’t sense distance; they tend to reliably fail after a few years.
Ultrasonic e.g. HC-SR04
- Characteristics: Range 2-3m; 30x4 degree field of view.
- Pros: sub euro cost; can measure distance very accurately; lowest power requirements of any solution (0.075 watts).
- Cons: extremely limited useful field of view; can’t disambiguate humans; long term reliability is also an issue with the cheaper Chinese modules; limited range, well under three metres.
Video with AI analysis e.g. Dahua IP cameras
- Characteristics: Range 100m; 120x90 degree field of view.
- Pros: very flexible, also lets human check visually; works outdoors and in the rain; wide field of view; can disambiguate humans.
- Cons: hundreds of euro of cost; distance accuracy is poor without a second camera; needs 15 watts of power (by far the most of out any option here).
Laser Time of Flight (ToF) e.g. VL53L8CX
- Characteristics: Range 4m (bright white objects, much less with dark objects); 60x60 degree field of view.
- Pros: can detect multiple objects within 64 zones and whether they are in motion or stationary; needs about a quarter watt of power.
- Cons: Cost about €15 inc VAT each (these are sub-euro models like the VL53L0X which do simple distance calculation and nothing else over a limited field of view); don’t work well with dark or non-reflective surfaces; can’t disambiguate humans; the sensor itself outputs histograms, and the analysis of those must be done in software by the microcontroller, which isn’t possible for an ESP32 unless it is fitted with extra RAM.
Radar e.g. HLK-LD2450
- Characteristics: Range 6m; 120x120 degree field of view.
- Pros: a few euro of cost; can detect distance of multiple objects and whether they are in motion or stationary; works outdoors; can disambiguate humans; has onboard DSP to do all the analysis so your ESP32 doesn’t have to.
- Cons: limited distance and speed resolution; some radar frequencies don’t work well in rain; needs about half a watt of power.
From four years ago onwards I tested options one to four – at the time, the radar based solutions were very new and not much good. I set up a passive infrared sensor in my living room, it worked for about three years with range reducing over time until the sensor died which is par for the course. The lack of resolution, and the constant need to have humans moving over its low resolution to keep the sensor on, ruled it out as a bedroom human presence sensor.
The ultrasonic sensor was cute and great for short range very tight field use cases. But I’d be thinking more ‘is the door open?’ type use cases, not ‘is a human present?’.
The video I’ve already done a post about, and it’s my preferred solution for outdoors and the public areas of indoors as it saves on lots of wiring, and I’d be recording most of those areas anyway. It isn’t viable within bedrooms for obvious reasons.
The laser based time of flight sensors were until now my best solution to this problem. I tested the VL53L0X ToF sensor which is a simple very cheap distance sensor, and it was great. Nearly as accurate as an ultrasonic sensor, similar range, can also work with non-hard non-perpendicular surfaces. But it really is mainly an alternative for an ultrasonic sensor.
I also tested the VL53L1 ToF sensor. The latest firmware can see bright white objects up to eight metres away – if not a bright white object, four metres is more likely. The results for this sensor were impressive, it could locate and track multiple objects with location, speed and direction. It did chew up a fair bit of a Raspberry Pi Zero’s CPU because the software analysis is all done on the CPU using raw data from the sensor. And the maths needed are non-trivial. But I came away surprised just how much information you can calculate from what is backscattered laser light if you can throw enough maths at the problem.
This brings us finally to the radar sensors. As mentioned earlier, I hadn’t investigated these until now as they were expensive, novel, and at the time not very good. But the technology has matured, and Hi-Link which is the principal Chinese vendor of cheap radar sensors has both driven down cost and greatly improved accuracy. I can, for above five euro, get a very good radar sensor now.
Radar human presence sensor categories
Radar sensors come in categories based on what radio frequency they use to implement the radar. There are the following radar implementations available as modules for integration into DIY projects currently on the market at the time of writing. I put in bold any showstopper type gotchas about each.
- 5.8 Ghz Hi-Link & Leap, 3-20 dBm power range
- Characteristics: Range 6m; 140x140 degree field of view; 150 mm max resolution.
- Pros: Part of ISM frequencies, so no licence required.
- Cons: Poor, but some, building penetration; collides with Wifi 5 Ghz 802.11p.
- 10 Ghz Hi-Link, 2 dBm power range
- Cons: Similar frequency to satellite TV; low range; requires licence to use.
- 24 Ghz Hi-Link & Leap, 6-20 dBm power range
- Characteristics: Range 9m; 120x120 degree field of view; 22 mm max resolution.
- Pros: Part of ISM frequencies, so no licence required; no building penetration.
- Cons: Absorbed by water and water vapour, which reduces range to a few kilometres at most
(but also makes this frequency range especially sensitive to bags of water
).
- 60 Ghz Hi-Link & MicRadar, 6-12 dBm power range
- Characteristics: Range 6m; 100x100 degree field of view; 10 mm max resolution.
- Pros: Part of ISM frequencies, so no licence required.
- Cons: Strongly attenuated by oxygen in the atmosphere which strongly reduces range to a few metres, which means it is generally always limited to within a room; collides with ‘WiGig’ 60 Ghz Wifi standard.
- 77-80 Ghz Hi-Link, 10-13 dBm power range
- Characteristics: Range 15m; 100x80 degree field of view; 8 mm max resolution.
- Pros: No building penetration; very versatile, can be used for everything from medical scanning to high bandwidth satellite uplinks.
- Cons: Lots of stuff uses this range due to its excellent properties; requires licence to use.
For human presence detection within a room, you generally don’t want to see into other rooms, plus 5 Ghz Wifi tramples all over the 5.8 Ghz radar option. The ~80 Ghz radar is amazing, but needs a licence for use. That realistically leaves the 24 Ghz and 60 Ghz radar options. Of those, the 24 Ghz radar is more interesting for human presence detection because big bags of water absorb most of 24 Ghz, so to the sensor humans stick out as big black shapes easy to disambiguate with a simple filter. As radar penetrates clothing, it can easily pick out micro movements like your heart beating in a way laser based solutions cannot. This makes 24 Ghz radar based solutions ideally placed to detect stationary but present humans e.g. if they are asleep in a bed.
24 Ghz Hi-Link radar sensor models
Hi-Link alone has dozens of radar sensor modules with use cases for everything between smart toilets to water tank gauges. I ran through the full list choosing only those likely to be useful for human presence detection within a typically sized bedroom, and eliminating old and legacy models. This list naturally fell out into three models, one per year. All can measure distance, all provide a serial UART interface which an ESP32 or indeed anything else can use, and I think all provide a Bluetooth interface (more on that shortly):
- LD2410b (released 2023)
- Cost: €1 inc VAT
- Transmit power: 13 dBm (79 mA module consumption)
- People count max: 1
- Position: no
- Range max: 6 m
- Resolutions: 0.2 m, 0.75 m
- Field of view: 120x120 degrees
- Needs 5v power supply
- LD2412S (just released in 2025)
- Cost: €3 inc VAT
- Transmit power: 13 dBm (90 mA module consumption)
- People count max: 1
- Position: no
- Range max: 9 m
- Resolutions: 0.2 m, 0.5 m, 0.75 m
- Field of view: 150x150 degrees
- Needs 3.3v or 5v power supply
- LD2450 (released 2024)
- Cost: €4 inc VAT
- Transmit power: 12 dBm (120 mA module consumption)
- People count max: 3
- Position: yes
- Range max: 6 m
- Resolutions: 0.75 m
- Field of view: 120x70 degrees
- Needs 5v power supply
The HLK-LD2412 human presence detection radar sensor
Of these, the LD2412 looked the most interesting for detecting if a human is in a bedroom, so I picked up three of them off Aliexpress for a tenner delivered:


The top one is the LD2412 and the bottom the LD2412S – the latter is a v2 design according to the manufacturer, and the board layouts are indeed very similar. Something which Hi-Link has realised this year is that 5v powered boards are a pain, so they’ve added in the option of either or both 3.3v and 5v power options – onboard boost and buck converters will generate the missing voltage from the other as needed. This makes them far more convenient to integrate. They also dropped the default UART speed to 115200 which usually means you can skip bothering to wire in hardware flow control, another convenience. Finally, all three modules above have a Bluetooth transmitter thanks to their onboard DSP. It simply offers the serial communication over Bluetooth. And, to be clear, the Bluetooth aerial on these is lousy, plus there is zero security and nothing to prevent hijack, so I’d only use it as a temporary solution. But it certainly is very very convenient, and well done on Hi-Link for putting together such a DIY hobbyist friendly package for such a low cost (something which ST Microelectronics might want to think about for their ToF sensors).
So, does it work?
Testing the HLK-LD2412S human presence detection radar sensor using my laptop
As you saw, it correctly detects when a human is moving or stationary. It gives a fair approximation as to their distance given the 0.5 m resolution it is configured with – by measuring tape I’d say my legs were 2.55 m away from the sensor, and if you wait long enough it does seem to eventually realise this. If you move a little further away, it switches to 2.5 m, so I guess it might be a calibration thing. Also: this sensor is affected by bright light, and it was daylight outside and I hadn’t bothered to tell it to auto calibrate for light using its onboard light brightness sensor. In any case, the sensor definitely works as advertised.
You might notice mention of having set it to 0.5 m resolution, so I should explain that. The LD2412 has twelve ‘gates’. If you choose 0.75 m resolution, that is 9 m of range as 12 x 0.75 = 9; if 0.5 m resolution, that is 6 m of range; if 0.2 m resolution, that is 2.4 m of range. The 2.4 m range is just too short to reach my couch, it oscillates between seeing people stationary on the couch or not. It picks motion immediately even outside its maximum range, and of course it picks up stationary people within the 2.4 m range without issue. The 6 m range worked well for my 3 m wide room, as you saw in the video, but the granularity is coarse. Where things didn’t go well is the 9 m range, it really didn’t detect stationary people on the couch at all. My pet theory for this is that the wall behind the couch is reflecting radar back at the sensor, and if the sensor is trying to pick out humans up to six metres behind the wall, it gets overwhelmed. So the default setting of 0.75 m for this sensor would make it look useless in a 3 m room, which may explain some of the bad online reviews and commentary.
At the 6 metre range, I tried it with multiple people in the room – it reports the closest. I tried it from its side, and I think its 150 degree field of view is realistic. I tried to confuse it by being as still as possible by holding my breath, and I failed. It appears able to detect the micro movements of my heart no matter what I do. I am suitably impressed. If I leave the room, or go outside its range or its field of view, it realises within about one second, though its default setting is to wait for ten seconds before reporting absence. Consider me even more impressed – the signal processing mathematics to achieve this sort of accuracy and speed of reaction are non-trivial. All in a very easy to use package costing €3 inc VAT.
Why choose the LD2412 sensor when the LD2450 sensor looks better and for only one euro more? The LD2450 sensor which can detect and locate multiple people in an X-Y space would seem initially the better choice. However, online reports (and the manufacturer itself) say that stationary human detection greatly suffers as a result, with a reliable range of about two metres from the sensor. Basically the algorithms can either do stationary human detection well OR multiple human tracking well. If your use case is detecting how many people are in the room and where they are whilst moving, choose the LD2450. If you want to know if somebody is asleep in their bed, especially with a very wide field of view, choose the LD2412.
Which brings me to my final two things to mention about this sensor. The first is how to update its firmware – after all it runs its own DSP microcontroller on there, and they have greatly improved its firmware over time. So you really do want the latest firmware on there, and I can speak from testing experience on that. You update its firmware using Bluetooth from its mobile app. There are no alternatives. Its mobile app on Android seems incapable of actually updating the firmware as it always errors out, at least from the day I spent trying to make it work. Lots of others on the internet report the same. I was resigned to giving up, when it occurred to me that Apple Silicon Macbooks can now run iOS apps directly. So I gave it a go, and indeed the iOS app running on my Macbook worked seamlessly and updated the firmware without issue. In fact, that iOS app is what you’re seeing run in the video above, it was just easier for testing and videoing. So if you’re reading this trying to figure out how to update the firmware on these Hi-Link devices, now you know how: get an Apple Silicon device.
The second thing about this sensor is that individual gates can be configured for sensitivity if you wish. If you want to detect people at say 1.5 m and at 7.5 m only, and ignore all humans at all other distances from the sensor, that is very easy to configure. This means you can have a sensor detect if somebody is between the kitchen island and kitchen counter, and not trigger if they are anywhere else. This I think should be very useful indeed down the line. In short, I am won over by this type of sensor, from my testing I think it’s quite the game changer for what has been traditionally quite a tricky problem to solve well.
Finally, you can hide this sensor behind a few mm of ABS plastic without affecting it. This means bedroom human presence detection can be completely invisible. Nice!
What’s next?
I might get the thermally broken kitchen extractor testing done this coming weekend before we head off to London for the week. If not, then surely not long after our return.
Next comes the differential pressure sensor testing. That is surely doable in the three weeks of summer remaining before the WG14 standards meeting.
After I return from the WG14 standards meeting, the summer holidays for the kids will be over and I’ll be released from childcare. I guess it’ll be finally time to seriously start looking for work, though I may wait until the Monad cryptocurrency mainnet launches, as I did informally agree to remain available to them until then. Supposedly that will be some time in September, so only a few weeks more – and I surely could fill those weeks doing 3D services layout (and maybe a day out with the T2 Longtail on gravel tracks if the weather were nice one day).
The problem
Almost exactly three – yes, three – years ago I wrote here about my then recent purchase of the Dahua HFW5849T1-ASE-LED IP security camera. I was very impressed – for a few hundred euro, you can now get a 4k camera which can see in full colour in a level of dark humans can’t see in. I raised two of those cameras plus a 180 degree camera on the site shortly after getting the solar panels and fibre internet installed, which is an amazing two years ago now. Those cameras have been watching over the site ever since, alerting my phone if anybody strays onto the property using their basic on-camera AI. Each camera has a sdcard, and it continually records with about three and a half days of video history. The total power consumption for the site is 78 watts, much of which goes on those cameras (I know the 54v DC power supply draws about 50 watts, but that also goes on the PoE networking equipment and the fibre broadband).
This low power draw means I get continuous operation even with the Irish weather for ten months per year, with maybe 67-75% service during Dec-Jan depending on length of run of short overcast days. For the power budget, I cannot complain. However, if I did have more power budget:
The AI on the cameras runs on (at best) an internal resolution of about 720 x 400 by my best guess. This works fine when objects get within maybe twenty-five metres of the camera, but anything further out won’t trigger as there just isn’t enough resolution.
The AI on the cameras isn’t bad for what it is, but it also likes to think all black animals are cars. Black cats, black birds, anything black triggers it. This is annoying at 4am.
The 3.5 days of storage time is a touch limiting. You really want several weeks as a minimum.
Reusing decade old hardware
As I am me, I have a whole bunch of old to ancient spare computer parts lying around, so around this time last year I put together the least old of those old parts to see if they had any chance at all of running Blue Iris, which is a long standing reasonably priced software solution to IP security camera control and analysis. As it is a Windows program, I needed to run a dedicated Windows box in any case, but I didn’t really want to spend much money on this until after the house was raised. The base hardware specs of this ancient kit:
- Intel Pentium G3258 which was an ultra low budget dual core Haswell part able to reach 3.2 Ghz. Haswell is a 2013 era design, but it was the last truly improved new CPU architecture from Intel i.e. it doesn’t suck even today. One thing to note is that the G3258 as an ultra budget chip has AVX artificially disabled. This causes some AI software to barf at you, but a lot of software will work with just SSE surprisingly enough.
- 16Gb of dual channel DDR3-1333 RAM giving ~20 Gb/sec of memory bandwidth.
- ASRock H97M-ITX motherboard (the original use for this PC when new was within a 12v powered mini-ITX case).
- Sandisk SSD Plus 240 Gb SATA SSD from about year 2015. I remember picking it up super extra cheap in an Amazon sale and I didn’t have high hopes for its longevity, but it ended up proving me wrong.
I tested this last summer leaving it run for several months, and found that if I reduced the resolution from the cameras sufficiently, Blue Iris did work sufficiently okay that I felt confident in investing money into more of this solution. As the daylight hours began to shrink, I removed this additional power load and then, to be honest, it kinda got backburnered for a while.
Two things then changed:
I saw on a HackerNews post that the Chinese had started dumping their ten year old AI hardware onto Aliexpress for cheap as they cleared out parts they were retiring. Unlike previous AI acceleration hardware, the ten year old stuff (nVidia Pascal) isn’t too far from the modern hardware i.e. modern CUDA programs run just fine on Pascal, just slower. A cheap enterprise AI accelerator card would be game changing for realtime video analysis.
Thanks to recent economic uncertainty about the future, the price of high capacity enterprise hard drives cratered to firesale prices. I ended buying the only brand new part in this project – a Seagate Exos 28Tb enterprise hard drive – delivered for €400 inc VAT and delivery. Just a few months ago that drive cost nearly a grand. Madness.
I picked up an 8 Gb nVidia Tesla P4 card from Aliexpress for €125 inc VAT and delivery. It turned out to be brand new, never used, and it even came with its additional low profile bracket. This is a 2016 era card and it has 192 Gb/sec of memory bandwidth and can do about 5.7 TFLOPS in FP16 for under a 75 watt power budget. For the money, and for the power budget, this is a whole lot of AI acceleration – even brand new 2024 hardware would get about the same memory bandwidth and maybe twice the compute if constrained to a 75 watt power budget. And it would cost several times what this card did!
The nVidia Tesla P4 card – and indeed its whole generation of AI hardware which lacks tensor cores – isn’t well suited for running large language model AI (i.e. chatbots). But I ran a variety on 8b LLMs on it out of curiosity and it does about 18 tokens/sec until thermal throttling kicks in, whereupon you get about 12 tokens/sec. You could of course fit more cooling (you’ll see my ‘fan solution’ below), but ultimately this generation of GPU on its generation of CPU is going to be far slower at LLMs than even a recent CPU on its own. I’ll put this another way – my M3 Macbook Pro laptop handily beats the Tesla P4 for LLM performance and my Threadripper Pro workstation blows far past it. The latter has less memory bandwidth than my Macbook, but LLMs especially newer ones need more compute, and that is exactly what the Tesla P4 (relatively speaking) lacks.
All that said, while ten year old GPUs aren’t great for running LLMs, they absolutely rock image analysis which is the kind of task that generation of hardware was designed for. Identifying objects, tracking facially recognised people in crowds, 3D spatial reconstruction from multiple images – this generation of AI hardware absolutely aces those tasks as you will see later.
Finally, there was a little compatibility issue with the Seagate Exos drive and this ASRock motherboard – the motherboard doesn’t wait long enough for the hard drive to respond, and so on boot it sometimes doesn’t find the drive. I trial and errored BIOS options to slow down the boot enough that it now finds the drive 95% of the time, and if it doesn’t find it then a soft reboot fixes the issue as it avoids the drive doing a cold start. Just something to be borne in mind when pairing really new hard drives with ten year old motherboards.
The build
This is the oldest PC case I still have. It is from around 2008 I believe. It was once the TV PC for myself and Megan back a very long time ago – myself and Johanna had a TV PC in our St. Andrews house, and I think when we left I gave it away as I wanted to replace it with modern hardware, and this case was what enclosed that modern hardware (I distinctly remember with grimace the first motherboard in that new TV PC, it was a Gigabyte branded model with AMD CPU and it cost me enormous amounts of time due to quirks and I ended up junking it for an ASRock motherboard and Intel CPU out of frustration). The case, and especially its power supply which got extracted and used for other things, carried on.


In Canada, we bought Android TV pucks just before we came back to Ireland having not used a TV PC in Canada, so this case has certainly not been in use since 2011 or so. I have been keen to put it back into use as it is one of my most favourite cases – partially because it is especially well designed, it was ludicrously cheap and even came with a power supply for the money. But I really like how tacky and garish it is. It was the perfect looking TV PC with its piano shiny black plastic with red and gold plastic. In case you’re wondering why there is tape on the front, it’s because the hard drive light is so ultra bright it’s very annoying. So we taped it over with two layers to dull down the brightness. You might notice that with this coming back into use now I took the opportunity to fit a USB3 5.25” adapter, as the motherboard is new enough to supply USB3 and I might want to copy video or something large one day. The 5.25” insert cost something like €13, it seemed a wise upgrade for this case as absolutely nobody uses a CD-ROM drive anymore, and as you may notice it can also house a 3.5” hard drive which is exactly where I mounted the Exos hard drive (there are two dedicated 3.5” bays above, but they are horizontally mounted and I wanted this drive vertically mounted as it gets rather warm – see below).
The mini-ITX motherboard has only one PCIe slot and it’s far too small for the case. But no matter – this case has enough space to fit my 3D printed fan adapter, which is my custom solution to how to cool the AI accelerator card, because enterprise cards don’t cool themselves like consumer cards, they expect cooling to be supplied to them:

I got the design for the adapter off the internet, but I had to do a fair bit of customisation to get it to fit into the smaller original case I had in mind for this project. But eventually it was just easier to break out this much too large case, and then not sweat trying to get everything to find inside a small space. Had I bitten the bullet sooner, I could have saved myself several days of my free time … but no matter, it’s all built and working now.
At the end is a Noctua PWM fan so it doesn’t blast at full speed all the time. I chose a speed where it isn’t loud enough to be annoying, which isn’t fast enough to run LLMs without thermal throttling, but it is plenty fast enough to analyse video as we shall see.
Finally, I put in a watt meter to aid tracking power consumption of this specific PC:

That says 84.8 watts incidentally. I think the CPU + motherboard probably consumes about 30 watts and the AI accelerator about 48 watts when it’s in use. With the fan speed I choose, the hottest part of the AI accelerator sits at about 60 C, which seems fine to me.
From the perspective of the inverter, the whole site now uses 158 watts, which if it used 78 watts before, means that this AI PC takes 80 watts on average over time. That, as with last year, will limit how long I can leave this box running with the current number of solar panels – once the days begin to shorten, I’ll have to remove it once again.
(In case you’re wondering how the maths works there, the reason more load uses proportionately less power is because conversion efficiency is lousy at low loads, so as the load rises you get less of a load increase that you would expect)
Blue Iris
Blue Iris has a Windows based UI, but also a convenient web based UI so you don’t need to remote desktop in:


Blue Iris is extremely configurable, and it has taken me several days of twiddling before I became happy with the results. Unfortunately, Haswell era CPUs can only decode in hardware h.264 video up to 1080p. After that, it’s all software decoding. Hence three 4k resolution h.265 feeds @ 7 fps causes the CPU to peg to 100% and analysis begins to fall behind. The GPU barely breaks a sweat with 4k images, analysing each in about 120 milliseconds, and runs just above its lowest power state above idle at about 48 watts (absolutely idle is about 7 watts, incidentally, but as soon as the card gets connected to by any software power consumption jumps to 35 watts or so).
The cameras can emit a lower resolution substream for ‘free’, and Blue Iris can be told to use that substream for the AI inferencing whilst otherwise using the 4k stream for everything else e.g. storage to disc, browsing etc. Given that the Haswell CPU can’t hardware decode better than 1080p h.264, I chose exactly that for the substreams and three streams of that uses about 26% of CPU. Unusually (see below), I send them immediately to the GPU and do as little CPU processing as possible. The nVidia Tesla P4 takes about 45 milliseconds to process a 1080p image, and Blue Iris asks it to do so every second per camera. Therefore if this PC were newer hardware, this card could happily analyse twenty 1080p cameras which is good to hear, as we shall be eventually fitting eight external cameras and four internal cameras. If it could decode h.265 in hardware, maybe even eight 4k streams could be doable.
In Blue Iris terms, the current three camera setup runs at 34.5 MP/s which simply adds the bandwidths of all the cameras together. That would imply a maximum of ~150 MP/s if maxed out. I read online in forums that this old hardware should max out at around 800 MP/s albeit with AI disabled, however this CPU doesn’t have AVX and it has especially small CPU caches. Also, surely sending everything to AI immediately is expensive as it implies many more memory copies – plus I note that the AI backend is written in Python, and it eats 6% of CPU just by intermediating between the CUDA on the GPU and the main Blue Iris program.
You can, of course, tell Blue Iris to only invoke the AI if something in the picture changes. However, two of the cameras are on poles and the wind makes them wobble, so the motion detection is always being activated which means the AI is always getting called anyway. Turning off the motion detection prefilter therefore reduces overall CPU.
Storage
Blue Iris appears to write to the disc at about 0.9 Mb/sec per 4k h.265 stream. For a 28 Tb drive, of which 24 Tb is probably available for writing, that is 75 Gb/day/camera which means one camera will fill that drive in 325 days, two cameras in 162 days etc. It should take 3.5 months for the current three cameras to fill that drive, but about four weeks for twelve cameras. This is exactly why I splurged now for precisely a 28 Tb hard drive – four weeks of recordings I reckon is exactly what I’m looking for, and the first commercial release of HAMR technology hard drives is probably going to have been overengineered for durability. I guess I’ll find out.
HAMR drives generate a lot of heat when writing due to the laser assisted writing – when I was soak testing it, the write only stage generally took the drive up to a toasty 65 - 70 C whereas the read only stage kept the drive at 28 - 32 C or so. I didn’t have forced air on it, but the drive was open to the air. At 0.9 Mb/sec write speeds and in a case with at least some forced airflow, and the drive mounted vertically to aid heat being driven off of it, the drive sits at 43 C or so – I guess that laser remains turned on for long enough even at low rates of writing to generate a fair bit of heat. Heat, of course, equals additional power consumption and it is unfortunate that for my future house we shall be adding so much additional waste heat. Non-HAMR drives might only be +5 C for sustained writing, but non-HAMR capacities topped out at 18 Tb for Seagate so I guess the increased write power consumption is now here to stay.
How good is the AI?
The AI is Codeproject.AI which lets you configure which backend you prefer. After much testing, I settled on YOLOv8 though with a custom IP camera detection model loaded, as the default one generates far too many false positives e.g. finding that concrete blocks are trucks etc.
To date, with the custom model, I am impressed! It detects people at the very furthest extent the camera can see where in 1080p they are only maybe a dozen pixels high. It detects vans and cars and people which are obscured behind the cabin or shipping container. As a result, it triggers far more frequently than the on-camera AI does. But in the last few days of testing it, to date it hasn’t had any false positives except during sunrise (false negatives are, by definition, considerably harder for me to notice).
The sunrise false positives are for the middle camera only, and I think they’re due to how the light makes the complicated view look to the camera. I’m sure it’s fixable with a bit of tweaking the settings.
How do you get notified?
The camera built-in AI has an integration via its manufacturer’s Android app and a server somewhere in China. Blue Iris does also have an Android app and a cloud push server for an annual subscription, but internet feedback reckons it isn’t much good. Instead, they think wiring it into Pushover the best course of action, and there is a ‘quick start’ tutorial at https://ipcamtalk.com/threads/send-pushover-notifications-with-pictures-and-hyperlinks.58819/ which is nearly cut-and-paste easy.
In next to no time, the Pushover Android app was pinging me with a high resolution photo anytime absolutely anything at all involving a human or a vehicle occurs. I can’t complain about the accuracy nor push notification latency – indeed, I’m surprised how well it does given the downsampled 1080p input.
What’s next for this project?
Down the line, I will want to add facial recognition so the thing doesn’t go mad with alerts every time I or my family are on the site. Also, I’d like to add 3D spatial reconstruction – this is where some CUDA code takes several camera images of a scene from known vantage points, and from that reconstructs the 3D spatial location of objects. For this to work, you ideally need three cameras and no less than two cameras pointing at the same place from very different locations which I don’t currently have, so there isn’t much point in setting that up right now. Down the line however, I have deliberately designed the house camera layout so images overlap and the AI can reconstruct locations.
The reason we want the AI to know where people are is principally so lighting can be dynamically adjusted upwards and downwards based on whether humans are near a thing. So, ideally speaking, the outdoor lighting would all normally be very dim saving power and not disturbing nature. If a human – but not an animal – is close to a particular wall, the AI would brighten just that portion of the outdoor lighting. This wouldn’t just save on power, I think it would have an excellent burglar deterrence effect too because clearly something is aware of your presence.
You may remember that I originally planned to use Time of Flight sensors or Infrared sensors for this. But they’re a whole load more wiring work, and need a whole load more ESP32s to be placed around all of which then need more power, more ethernet wiring etc. As security cameras were going to be installed in any case, if they could be used to avoid all those sensors, that would be a big win. The concern was what the power consumption hit would be, and now that question has been answered.
Anyway, all that is well down the line, and I now have proven that a low power AI accelerator will do the job very nicely. So that’s another todo item ticked off for now, and another project which can be put into hibernation until the house gets built.
What’s next for this summer?
In terms of what’s next for my remaining summer, as you have probably noticed I have been making great progress at advancing my many projects and writing up my notes on them here. I have three projects awaiting testing and writeup here remaining:
- Differential pressure sensor testing.
- Thermally broken kitchen extractor testing.
- Radar human presence sensor testing.
The first I’ve mentioned here several times before. The second is to see if a Passive House grade of insulated kitchen extraction vent can be created – I’ll be empirically testing this using Megan’s hair dryer and a thermal camera. The third is a new type of sensor recently available on Aliexpress – unlike Time of Flight sensors which work on the basis of analysing the scattering of an infra red laser light, these sensors work on the basis of analysing the scattering of radio waves. Supposedly, they can tell you if (a) a human is present (b) if that human is standing, sitting or lying down and (c) they have a range of about five metres. If they really can tell human position accurately, they would solve my ‘bedroom problem’ because I can’t fit cameras inside bedrooms, so a sensor which can tell if somebody is in a bedroom, and whether they are sleeping or not, would be very handy.
We ended up purchasing a Fiido D11 2025 edition for Megan’s commute bike, so I’d expect a short post here on that at some point.
I’ve been and returned from my final ISO WG21 C++ standards meeting in Bulgaria, and I have cranked out four papers for the next ISO WG14 C standards meeting. So that’s all done.
The trips to Amsterdam and London have been planned and booked. This Monday I’ll even get cleared another unpleasant todo I’d been putting off, a colonscopy.
There are two things I have not made good progress upon so far:
- Losing weight (I remain at 84 kg despite substantially reducing my caloric intake and increasing frequency and duration of exercise).
- Complete the 3D services layout plan, which I ‘mysteriously’ keep finding excuses to not do because I dislike doing it so much.
I’m sure that as the low hanging more enjoyable fruit gets harvested, I’ll have ever fewer excuses to not get moving on the less enjoyable work. Here’s hoping!
There are only a few occasions that I can think of in my life where I have been singularly unsuccessful over multiple years of trying. Usually I am quite effective at anything I apply myself towards. But it turns out that I am no good at standardising C++. I still think that’s far more on the dysfunctionalities of WG21 than it is on me, but seeing the glacial progress of my house build … well, clearly there are some things where me applying myself does not yield timely results.
As mentioned a few posts ago, there has been forward progress in my house build in that the timber frame supplier (builder) has finally provided a set of design plans and those have been since signed off by my architect. So, to recount the overall timeline to date:
- 2020: We start looking for sites on which to build.
- 2021: We placed an offer on a site.
- 2022: Planning permission obtained (and final house design known).
- 2023: Chose a builder.
- Feb 2024: Lost the previous builder, had to go get a new builder and thus went back to the end of the queue.
- Aug 2024: First draft of structural engineering design based on the first draft of timber frame design.
- Nov 2024: Completed structural engineering design, began joist design.
- Mar 2025: Completed joist design, began first stage of builder’s design sign off.
- Jun 2025: First stage of builder’s design signed off. Many more stages left to go.
The reason that the builder’s design is not the architect’s design is because the timber frame, joists and the steel are both specific systems and the architect’s design is more generic, and not based around a specific supplier’s specific components. Therefore, new designs must be derived based on the architect’s design, and the architect’s design modified where necessary to match the constraints of the build technologies used. Here is the design as was signed off by the architect this month:
Builder's IFC 3D models: left is with timber, right is steel only



Ground floor: left is architect's design, middle is builder's design, right is structural engineer's design



First floor: left is architect's design, middle is builder's design, right is structural engineer's design
I don’t have anything really to say about these that hasn’t been said before. Many months have passed, very little material change has happened in the designs above. It’s basically exactly the same design as it was Spring 2024.
I have no idea what the builder will want to supply and install this. Whether we build soon or don’t build soon will hang on that final quotation.