Act I: the spoke that breaks

A 2,000 W hub motor is a hub twenty-one centimetres across, laced into a rim with short, thick spokes: 160 mm overall, 2.6 mm in diameter, thirty-six of them, crossed once. When one of them breaks, it is never a surprise for the wheel, only for the rider. This was my second wheel: the first had ended the same way, one spoke, then two, then a rim going out of true beyond recovery.

A spoke almost never breaks because it is too tight. It breaks because it is not tight enough: at every turn of the wheel, when it passes the bottom, the load slackens it, and a spoke that slackens and tightens thousands of times per kilometre ends in fatigue, most often at the elbow, in the flange hole. So the right answer is not to replace the broken spoke; it is to know the tension of the other thirty-five, and to bring them all to the same level, the right one.

The trouble is that nobody could give me that level. Equalising by ear, plucking the spokes, is an old method that works for equalising but says nothing about the absolute value: a whole wheel too tight rings just as nicely as a whole wheel too loose, and on e-bike forums, rims cracked by excess tension are as common as spokes broken for lack of it. I needed a measurement.

Act II: why not a shop tension meter

A classic bicycle tension meter, the 18-euro model as much as the 80-euro one, works by bending the spoke between two supports about sixty millimetres apart with a calibrated spring, and a table converts the deflection into tension. It works well on a 2 mm bicycle spoke 280 mm long, because that spoke, left to itself, hardly resists bending at all: what the device measures really is the tension that stiffens it.

On my 2.6 mm spoke, it is another story. The bending stiffness of a rod grows with the fourth power of its diameter: going from 2 to 2.6 mm nearly triples it. Over a 60 mm span, the share of tension in what the device reads drops below half; the rest is the spoke defending itself, tension or not. And the paper table of these devices stops before 2.6 mm anyway. I would have had a number, but not a measurement.

The solution comes down to two ideas. First, bend over as long a span as possible, because the share of tension grows with the span: over 125 mm instead of 60, it goes from 45 % to over 70 % for a free spoke. Second, replace the spring with a truly repeatable force. I had a 3 to 20 Nm click torque wrench in a drawer. A click is a known torque, the same every time, to within 4 %. With a lever, it is a known force.

Act III: the design, and its dead ends

The principle stayed the same from the first sketch to the welded tool: three contact points on the spoke, two on one side at the ends of the span, one in the middle on the other side, carried by an arm that the wrench rotates about a pivot. The wrench clicks, the arm has pushed the spoke with a fixed force, and the deflection it took depends on its tension.

What changed was every detail, and I worked them out on a parametric 3D model, with an AI assistant keeping the model, opening it in Blender and running the numbers at each iteration. A few dead ends are worth telling, because they are instructive.

The first version was 3D printed in plastic. The calculation killed it before printing: for 1.5 mm of deflection to measure on the spoke, the PLA arm itself bent by 2.5 mm. The whole load path went to steel.

The second bent the spoke out of the wheel plane, outwards, because it was easier to build. I refused it: a spoke works in the plane of the wheel when the motor pushes, and I wanted to measure it that way. For a round spoke the two are equivalent, but it was not natural, and the pivot would have landed somewhere impossible once the tool sat on a real wheel, with the neighbouring spokes passing 24 mm away.

The supports are bearings, not pins. The literature on tension meters is clear: friction of the spoke on its supports distorts the reading, and by a lot. Two skate bearings, 22 mm outside diameter, 8 mm bore, cost next to nothing and roll without friction. The third point is a plain fork, because it does not move.

The click releases the load. It jumped out at me while animating the mechanism in Blender: a click wrench takes about three degrees of play at the moment it trips, and the torque drops. The spoke only needs two degrees of the arm to spring back. Reading the arm’s position after the click would read nothing useful. Hence a retained-maximum reading: the depth rod of a caliper, pushed by the arm, stays where the arm brought it when the arm backs off. You read the maximum, the one at the click.

Act IV: the welded tool

Between the model and the workshop the tool changed again, as it always does when you have steel flats, a welder and a box of bolts at hand rather than the model’s exact inventory. The 3D model was then refitted to the real tool, dimension by dimension, photos in hand. Here is what exists.

The frame is a 25 mm square tube that sits above the spoke, 6 mm from it, and stays entirely clear of the neighbouring spokes. Only three elements reach down to spoke level: the fork at the hub end, a 3.5 mm slot hanging under the end of the tube, and the two bearings, each at the end of a vertical bolt. The first bearing, A, sits at the end of a bolt welded under the tube, 125 mm from the fork. The second, B, on the other side of the spoke, 60 mm from A, sits at the end of a bolt welded to the moving arm.

The moving arm is a 4 mm flat lying above the tube. It pivots on a bolt left loose, X, set in a 4 mm plate welded on the tube, 15 mm from A and 46 mm from B. A socket welded on the arm, 25 mm from A, takes the square drive of the torque wrench, whose handle points radially towards the rim. When the wrench pushes, the arm rotates about X and B presses on the spoke with the torque divided by 46 mm: 111 N at 5 Nm, 156 N at 7.

The caliper is slipped between the arm and the tube, beside the pivot plate, and its depth rod touches B’s bolt. It reads directly the displacement of B relative to the tube, that is, the deflection of the spoke relative to the chord joining its two fixed supports, A and the fork.

Act V: the first numbers, and a mechanics lesson

First surprise, and the one that taught me the most. On a free spoke, held in the air in the tool, I read 3.4 mm at 3 Nm, 4.6 mm at 5 Nm and 5.9 mm at 7 Nm. Three points perfectly aligned, 0.625 mm per Nm, but a line that does not pass through zero: there is 1.5 mm of reading before the spoke starts to resist. That is the assembly play, the 3.5 mm slot on a 2.6 mm spoke, the loose pivot, the bolts. It is constant, at least those three times, and it subtracts out. But it forbids reading a single measurement without having characterised it.

Second surprise: that slope was two and a half times lower than the calculation predicted for a free 2.6 mm spoke on two supports. I first looked for where the torque was going. It was going nowhere. The beam was wrong: a spoke you hold by the end between two fingers is no longer free, and above all, a spoke mounted in a wheel has its ends held, the elbow in the flange hole 20 mm from the fork, the nipple in the rim 15 mm from roller A. With ends held that close to the supports, the bending stiffness is four times that of a free beam. So the share of tension in what the tool reads falls back to about 40 % around 1,000 N. Less than hoped, but still very measurable.

On the mounted spoke, I read 3.8 mm at 7 Nm. Once the play is subtracted, 2.3 mm of elastic deflection remain, and the model converts them into about 850 N, between 640 and 1,140 depending on whether the play is really 1.2 or 1.8 mm. For a 2.6 mm spoke on a hub motor, the commonly targeted order of magnitude is 1,000 N. So that spoke is not far off, but the figure is still a calculation, not a measurement: the exact position of the supports and how firmly the elbow is held weigh 20 % on the result. To compare spokes with each other, the model is enough. For newtons, it will take a bench.

And the stress in the spoke, because the tool can bend what it measures. The free spoke took 6.7 mm of true deflection over 125 mm at 7 Nm without keeping any set, which corresponds to 1,300 MPa at the surface: the yield point of a drawn spoke, no higher. On a mounted, slack spoke, 7 Nm climbs to 1,500 MPa. The right setting is 5 Nm: between 800 and 1,100 MPa whatever the tension, 0.07 mm of reading per 100 N around 1,000 N, and the wrench in the part of its range where its 4 % is guaranteed. Those 4 % of torque read as 8 % of tension; it is the dominant uncertainty, and no lever reduces it. For equalising a wheel, it is enough.

Expected caliper reading at 5 Nm, including the 1.5 mm of play, for a mounted spoke:

The curve flattens towards high tensions: beyond 1,200 N the tool discriminates poorly. For my wheel, that is not the problem.

Act VI: what remains to be done

Everything above rests on a handful of readings. The next step is to make the tool talk properly, in this order.

1. Ten readings at 5 Nm on the same spoke, without touching the nipple, the slider reset to zero between each, the wrench handle always in the same direction. That is the real scatter of the tool, the one that matters.
2. Five readings at 3 Nm on the same spoke, to check that the 1.5 mm of play does not move.
3. A zero-tension control point, on the free spoke, holding only the tube this time.
4. A calibration bench: an extrusion, a spare spoke, a load scale, from 600 to 1,200 N. That is what will turn millimetres into newtons without going through the model.
5. Then the map of all thirty-six spokes, the search for the target tension, and the replacement of the broken spoke, noting exactly where it broke.

If you break spokes on a hub motor, remember this above all: the sound will not give you the level, neither will a classic bicycle tension meter on 12G, and a mounted spoke behaves differently from a free one. The rest is scrap steel, a click wrench and a caliper.

The 19 September version, closed, bikes loaded. Cordoba axle, 2.30 × 1.61 m body, 2 m drawbar with the lifting mast dismantled and laid on it. The one I finally chose is further down: it is 1.30 m lower.

The brief fits in one sentence

When we go climbing, surfing or hiking as a family, the T5 fills up fast. The idea: take everything bulky out of the cabin — kitchen, fridge, gear, bikes — and put it in a trailer designed for it, where everything has its place and opens without unpacking the rest.

I described it in one go, roughly like this: a Mini axle; on level zero, kitchen drawers on one side (sink and small stove), the fridge and its gas bottle on the other; on the level above, a large box for climbing gear, surfboards and walking poles, closed by a lid on boot hinges held open by gas struts; and on top, three slots for our three bikes, loaded by a removable ramp stowed under the trailer.

An AI (Claude) turned that sentence into a 3D model: a Python script that builds the trailer piece by piece in Blender, with every dimension at the top of the file. I never opened Blender to draw it. I looked at the pictures, corrected, clarified — and it was precisely when we moved from pictures to numbers that the project changed.

Three floors, one per use

The principle is a chest of drawers: heavy things at the bottom, bulky things in the middle, light and voluminous things on top.

The main dimensions of the chosen version (the labels on the image use a decimal comma). The floor is high (0.75 m) because the body sits above the wheels: that is what allows a body wider than the track.

The ground floor, kerb side, is the kitchen. A flap lifts up and becomes an awning. Below it, two low drawers slide out: one carries the sink and its tap, the other a two-burner stove. Their top is the worktop, 0.95 m off the ground, standard kitchen height. That is no accident: the height of these drawers is derived from the floor height, which depends on the axle. Change the axle, the worktop stays at 0.95 m. Above, two drawers for dishes and groceries; at the end, a column for two 20 L jerrycans, a 12 V pump and the battery.

Kitchen side, bikes in place. Everything opens without unloading the roof.

On the other side, fridge and gas. A 40 L three-way fridge (12 V, 230 V, gas) on a pull-out slide, so it opens from the top once out. At the front, a locker sealed from the inside and vented to the outside — high and low grilles on the door, a grille in the floor, because propane is heavier than air — for a 6 kg bottle. At the back, the folding table and chairs.

Fridge side. The bottle is separated from the rest by a bulkhead, with its own ventilation.

Above, the box. 2.26 m long inside: room to lay a 7‘0 surfboard, a crash pad, ropes, bags and poles. The lid pivots on three boot hinges and stays open at 82° on two gas struts.

The open box, without the bikes — and that is not a staging choice.

It was the first thing the model taught me, before any calculation: the bikes sit on the lid. As long as they’re there, the box doesn’t open. The kitchen and fridge do. It’s a constraint to live with (load the box before the bikes) or to design around (a fixed rack on posts and side hatches), but not something to discover in the car park at the crag.

Update, 21 September: constraint lifted. The bikes have left the lid, and the box opens with the bikes loaded — see The bikes come down from the roof.

The first draft looked good and proved nothing

The first version produced clean pictures in one evening. Mini axle, 2.30 × 1.45 m body, 1.35 m drawbar, axle placed “a bit behind the middle to get some weight on the ball”, a four-section telescopic ramp for the bikes. Everything looked plausible.

And that is exactly the problem: a clean render looks like a validation. Nothing in those pictures said how much the trailer weighs, what the axle can carry, or how it behaves at 130 km/h behind a van. So I asked what a trailer builder would ask: a proper weight distribution, and a drawbar long enough to manoeuvre easily with my long T5.

The calculation is a second script, independent of Blender. It takes every component — frame, drawbar, panels, drawers, fridge, water, gas, gear, bikes — with its estimated mass and position, and derives the centre of gravity and the load on the ball and on the axle, for five loading cases: empty; loaded without bikes; loaded with bikes; on the way back, water and food used up; and with e-bikes.

First result: the trailer weighs 416 kg empty in its lightest version (50×30 tube frame, 15 mm poplar plywood). Loaded with the bikes, 582 kg. The very first ballpark estimate, made before this calculation, said 260 to 400 kg empty: the bottom of that range was very optimistic.

The Mini axle failed the numbers

My axle is the rear suspension of a classic Mini: a subframe, two trailing arms, rubber cones for springs, 10-inch wheels. It’s compact and light. It’s also the rear axle of a 650 kg car, normally carrying 250 to 300 kg — and something like 450 kg at most.

Loaded with the bikes, the trailer puts 541 kg on its axle; 563 kg with e-bikes. That’s 20 to 25% over what the subframe is meant to carry, permanently, on the motorway. Even stripping out everything that can be lightened, you don’t get under the limit with a kitchen, a fridge, 40 L of water and three bikes.

I had two other options at hand or within reach: a Peugeot 205 or 206 rear axle, and the one from a Seat Cordoba 1.9D (first generation). The calculation puts them all through the same test:

Maximum loads are orders of magnitude; the actual “rear axle” figure is on the donor car’s manufacturer plate.

The same trailer on the four axles, generated by changing a single variable. The body widens by itself to cover the wheels. The Cordoba is drawn with separate springs sitting on the arms: that isn’t how the car does it (see the correction).

On paper, the Cordoba wins: the biggest load margin, 13-inch wheels that take potholes better and run their bearings cooler at 130, a wide track. And its suspension should work within its original range: the rear of a diesel Cordoba is designed for loads of the same order as the trailer’s (430 to 610 kg depending on the load). A bonus I hadn’t seen coming: on this kind of axle, the beam joining the two arms twists when one wheel rises and the other doesn’t — it acts as an anti-roll bar, exactly what you want with bikes perched up high.

Correction: the springs do take up room

Added on 19 September 2026, the day of publication.

The first version of this post said here that the Cordoba’s coil springs “don’t cost a single centimetre”: they would sit between the suspension arm and the underside of the frame, in the thirty-odd centimetres the tyre leaves free under the floor anyway. That’s what the render above shows, with its red springs.

Rereading it, something didn’t sit right: on the car, the spring rises up into the body, well above the wheel. A workshop guide for the Polo 6N, which shares its platform with the Cordoba 6K, confirms it. The spring wraps around the damper, the two form a single unit, and its top bolts into the boot, at the top of the wheel arch behind the trim. At the bottom, a horizontal eye bolts it to the beam, near the hub. The AI had reasoned about a separate spring sitting on the arm, as found on other axles of this type, without checking this particular car. And the clean render made the assumption look credible: exactly the trap described below.

The consequence: between the lower eye and the underside of the frame there are about 38 cm, and the unit is clearly longer. It would poke into level 0, right under the stove drawer on one side and the fridge on the other. Four ways out, not yet decided:

• separate spring and damper: keep the Cordoba’s beam and arms, sit the spring alone in a seat on the arm (bolted rather than welded, on a suspension part) and another under the frame, with a short damper mounted separately;
• turrets in level 0, rearranging the kitchen and the fridge side around the axle;
• raise the floor by the overhang: the simplest, but the bikes and the centre of gravity go up by the same amount, and crosswind is already the weak point;
• go back to the 205 axle, whose torsion bars sit inside the tube and whose dampers lie flat: no height problem at all, but a thin load margin with e-bikes.

To choose, I need three measurements on the axle: the length of the unit as fitted, the free length of the spring alone, and the height of the lower eye relative to the wheel centre.

Update, 21 September: the calculation has since reduced those three measurements to one. See The Cordoba, down to one dimension.

Holding the road behind the T5

The rule you hear everywhere: weight on the ball, or the trailer snakes. You still need to know how much. I aimed for 7% of the mass on the ball when fully loaded. The calculation then puts the axle 1.20 m from the back of the body — 5 cm ahead of the middle, where the first draft had put it 17 cm behind, by eye. Depending on the load, the nose weight stays between 5.8 and 7.6%, i.e. 31 to 45 kg, well below the 100 kg the T5’s tow bar accepts.

For snaking itself, the calculation uses a classic vehicle-dynamics model: car and trailer seen from above, joined by the ball, each with its mass, inertia and tyres that slip sideways. You look for the speed at which a small oscillation grows instead of dying out.

Result: above 400 km/h. In every loading case, on every axle, and even with the axle placed for zero or negative nose weight.

A result that comfortable makes me suspicious. A model that says “all good” whatever you give it may well be a model that computes nothing. So we tested it on a case whose answer is known: a 1.5 t caravan behind a 1.4 t saloon. The same model has it losing control at around 160 km/h with 5% nose weight, 110 km/h with 3%, 80 km/h with none — which matches what you read everywhere about caravans. So the model can predict instability; if it finds none here, it’s because the T5 weighs four times the trailer. The dog wags the tail, not the other way round.

The real risk is elsewhere, and much more mundane: crosswind. Three bikes nearly 3 m up, a 1.20 m high flank, a 1.40 m track. On the way back, with water and food used up, a 55 km/h crosswind gust is enough to unload the windward wheel when driving at 110 km/h; in a curve, about thirty. (Correction, 21 September: the first version said “about 100 km/h”. That figure came from a home-made model, and it only holds for a parked trailer. The story of this correction is told further down.) The rule follows: with strong wind forecast, drive slower, or the bikes travel in the T5.

A drawbar you can reverse without thinking

Reversing a short trailer is a test of nerves: it jackknifes before you understand why. What matters is the ratio of two lengths: the distance from the ball to the trailer axle, and from the T5’s rear axle to the ball (about 1.10 m on a long T5). The bigger the ratio, the slower the trailer reacts, and the more time you have to correct.

With a 2 m drawbar, the ball is 3.10 m from the axle: a ratio of 2.8. Going longer gains little (3.0 with a 2.20 m drawbar) and costs length (4.35 m overall, already 9.60 m for the whole rig with the T5).

Two calculation errors along the way were more instructive than the right answers. The first version announced that at full lock the trailer would sit at 164° to the T5 — in other words, overtaking it. A rotation in the wrong direction; once fixed, the angle drops to 51°. The second announced contact between trailer and T5 at 55°, whatever the drawbar length. Suspicious: if the length changes nothing, it isn’t what’s limiting. It was the coupling head itself, 25 cm from the ball — which in reality passes under the bumper, like on any trailer. With that point removed, the real limit showed up: how wide the V of the drawbar opens near the ball.

Hence the chosen shape: a single central beam for the first metre behind the ball, with the V opening only beyond it. First contact with the T5 then moves past 100° of articulation. At full lock, only 51 are used.

At full lock, steady state: 51° between T5 and trailer, with a good margin before any contact. The trailer cuts the corner about 1 m inside the path of the T5’s rear wheels.

A detail the model makes obvious and I wouldn’t have thought of: the trailer (1.61 m) is narrower than the T5 (1.90 m). Driving straight, you can’t see it in the mirrors. A wireless reversing camera, or two marker posts on the rear corners, are part of the project.

Hitched. The bikes stand a metre above the T5’s roof: worth remembering at car park height barriers.

Lifting three bikes to almost 2 m

Update, 21 September: this section describes a solution dropped two days later. I’m leaving it in, because the reasoning that kills the ramp still holds — and because the right answer was to stop lifting the bikes at all. See The bikes come down from the roof.

The ramp from my original idea died of simple trigonometry. The bikes sit at nearly 1.90 m; for a 25° slope, already steep for pushing a bike, you need a ramp over 4.40 m long — four telescopic sections, a prop in the middle so it doesn’t flex, and a 25 kg e-bike to push at arm’s length. Doable by two people with regular bikes, painful otherwise.

The alternative came from me, and it’s the one we kept: a removable mast, a jib that swivels at the top, a pulley at the end. The mast, two 1.50 m aluminium sections, slots into a sleeve welded onto the drawbar beam, just in front of the body. The jib, with a 1.45 m reach, covers all three rails plus a pick-up point on the ground beside the trailer. A hand winch on the mast, a cable over a pulley at the top then over the one at the end of the jib, and a spreader bar hooked to the bike’s saddle and stem so it goes up level.

The right-hand bike being lifted. Dismantled, the mast and jib lie on the drawbar (visible in the other views).

Two constraints came out of the model. Height first: for a bike sitting in its rail to pass under the pulley, spreader bar included, the mast has to reach 3.45 m. And loading order: middle bike first. Otherwise you’d have to lift it over another one, and no reasonable mast goes that high. Finally, something better written down than assumed: you don’t lift anything on an unhitched, poorly chocked trailer.

Update, 21 September: the Mini comes back as a pair, and the wind goes via the library

Two days after publication. Nothing is built, so everything can still move — and it did.

What about two Mini axles?

After the post went out, someone put to me an idea I had dismissed too quickly: since one Mini subframe isn’t enough, fit two, one behind the other, with 5 cm wheel spacers. The case took one line: double the load, much better road holding, much more resistance to crosswind.

Adding the variant to the model took one line of parameters, like the other axles. What remained was to put a number on each claim.

• Load: true, and better than expected. Each subframe carries 290 kg, or 145 kg per wheel — about what a Mini’s rear wheel carries on the road. So each rubber cone works where it was designed to work. The margin goes from −25% with a single subframe to +33%, e-bikes included.
• Road holding: true, for a precise reason. Two axles 80 cm apart resist the trailer rotating about a vertical axis (yaw) far more than one does: the restoring effect of the tyres is multiplied by 4.7. That is what settles a trailer after a gust or a passing lorry.
• Crosswind: a draw. Overturning depends on two things only, track width and centre-of-gravity height. The tandem gains because its 10-inch wheels allow a floor 11 cm lower, and loses as much because its track stays narrower than the Cordoba’s.
• “The load is doubled”: yes for the axle, no for the trailer. What caps the payload is the gross weight declared at approval: above 750 kg you need brakes and a different licence. The tandem buys margin and service life, not extra kilos to carry.

The twin Mini subframe variant. The rest of the model adapted by itself: 1.46 m wide body, floor at 0.64 m, bikes at 2.82 m instead of 2.93.

And it has a price. Tyre scrub, first: to pivot, a twin-axle trailer has to drag its tyres sideways. On full lock it takes 52 kg of side push at the tow ball. The T5 won’t notice; I will, the day I want to shift it by hand on a campsite pitch. Then a known flaw of this layout, which I found described by axle manufacturers: two independent suspensions don’t share the load by themselves. The height of the T5’s tow ball sets the trim — 5 cm off, and the front axle loses 51 kg while the rear takes on 39 — and over a bump a single axle takes almost everything. Manufacturers derate these axles by about 20% when fitting them in pairs; here each one works at 65% of its rating, so the rule is met. Finally, 43 kg more unladen weight, and five 10-inch tyres to find, a size that has become rare.

Wind: three objections, then the bridge method

The crosswind passage above was wrong. Not in its conclusion — the bikes on the roof remain the weak point — but in its numbers. The story of the correction taught me more than the correction itself.

The first calculation was a model hand-written by the AI: wind pushing on the trailer’s flank as on a panel. I balked three times.

“I’ve seen tall trailers with no suspension that don’t suffer from wind.” Checked: the same body without the bikes takes a much stronger gust. The problem isn’t the height of the body, it’s the bikes: perched at 2.30 m, they alone account for 41% of the effort trying to lay the trailer on its side. Along the way the model turned out to be too optimistic. It forgot that a moving trailer doesn’t get the wind from the side but from the front quarter, added to its own speed, and that a box taken at an angle is pushed much harder than a panel taken square-on.

“A bike isn’t a solid panel.” Correct. Counted part by part — tyres, rims, spokes, frame — a bike presents only 34% of its silhouette to the wind. And air passes through it: it suffers drag, not the wing effect the body suffers. The two downwind bikes are also sheltered by the first.

“You’re forgetting the T5 in front, clearing the way.” There I was surprised to be the one who thought of it. Answer: the T5 does shelter the trailer… in light wind. Its wake leaves with the wind, not along the road. At 110 km/h, the shelter is complete below 20 km/h of crosswind, half gone at 40, almost nil at 60. And the bikes stick out above its roof anyway.

Three corrections for three objections: we were groping. So I asked what I should have asked from the start — how do the people whose job this is do it? Ten minutes of searching were enough. The method exists, published and open access: Baker and Soper (2018), used to decide at what gust speed a bridge gets closed to lorries. It fits in three lines, it rests on coefficients measured in wind tunnels and at full scale, and it already contained my third objection: a trailer measured behind its lorry only gains about 10% of shelter.

Redone with that method, on the way home with bikes on the roof: a 55 km/h gust is enough to unload the windward wheel when driving at 110 km/h, 61 km/h when driving at 90. Trailer full, no bikes: 85. These are wind speeds at trailer height; forecasts give gusts measured 10 m up, and over open ground the wind is about a quarter weaker down at road level. The method ranks every vehicle by a “characteristic velocity”: with its bikes, my trailer is more vulnerable than an empty double-decker bus, the first vehicle to be stopped when the wind rises on the Queensferry Crossing in Scotland. The practical rule: from 80 km/h forecast gusts, slow to 90, or the bikes travel in the T5.

The home-made model gave 58 km/h instead of 55: the right order of magnitude, reached after three patches. One part of the calculation is still my own, and is flagged as such: the treatment of the bikes, for want of published measurements of bikes sitting on a roof.

When it lets go

What I really wanted to know wasn’t what the highway code says: it was where the real limits are. The calculation yields three, gathered on one chart.

The three ways of letting go, for the twin Mini subframe variant (chart labels in French: vent = wind, virage = cornering, louvoiement = snaking). The Cordoba gives the same curves within a few km/h. Click to enlarge.

• Wind. Full and without bikes, nothing lets go in normal weather: it would take 110 km/h forecast gusts to worry it at 130 km/h. With the bikes, the margin melts.
• Cornering. The trailer tips over at between 0.56 and 0.64 g of lateral acceleration, depending on the load. That is before the tyres slide on a dry road (0.8 g), but after on a wet one (0.5 g). In other words: in the dry, it goes over without having slid; in the wet, the outfit slides first. With the bikes, 0.58 g means 61 km/h on a slip road of 50 m radius.
• Snaking. No critical speed behind the T5, even with 120 kg badly placed right at the back. The green curve is the control case, a 1.5 t caravan behind a saloon of the same weight: it drops below zero at around 115 km/h.

The Cordoba, down to one dimension

That left the problem opened by the correction: the spring-and-damper unit rising towards the body. Looking at what sits at that spot in the trailer, the constraint first tightened: the stove drawer on one side and the fridge slide on the other sweep the floor right above it. Nothing may protrude, not even a bulge.

Then the calculation loosened it. Under the trailer’s load (290 kg per wheel), the original spring compresses and the unit is only about 41 cm long. Its head can then sit within the depth of the frame, 45 mm below the floor, on a plain drilled plate welded between two rails.

On one condition, and it is the only unknown left: that the unit’s lower eye sits less than 1.5 cm above the wheel centre. I assumed 3 cm below; it takes five minutes to measure on the car, before dismantling it. If the dimension turns out wrong, there are height-adjustable coilovers approved for this car.

The Cordoba mounting as the calculation now draws it: the coilover stops inside the frame, and two brackets drop down to reach the arm pivots.

The real fabrication work is elsewhere, and I hadn’t seen it. Because the body sits above the wheels, the frame is 67 cm off the ground while the axle’s arm pivots are at 33 cm. So it takes two 35 cm drop brackets, which see about 1.6 kN·m on a pothole taken fast: box sections in 5 mm plate, a brace running forward, and a tube between the two to carry side loads.

This mounting is still far simpler than the tandem: one axle, four fixing points, nothing to adjust, tyres you find everywhere, and a trailer you can still move by hand. The tandem has more margin and a lower floor. I haven’t decided.

Second update, 21 September: everything comes down

The same day, a few hours later. Two design questions did more for the trailer than all the morning’s calculation refinements.

Sinking the axle into the body

From the start, the body sat above the wheels. That is what let it be wider than the track, and also what perched the floor at 75 cm. Hence my question: why not do as the Seat itself does, or any van? Drop the floor between the wheels, let them rise into wheel arches inside the body, and build the drawers around them.

The floor can come down until it nearly brushes the beam joining the two wheels: 0.51 m instead of 0.75. Everything else follows as one block, 24 cm lower. And the two difficulties of the mounting, the ones from this morning’s update, vanish at a stroke:

• the 35 cm brackets that had to drop from the frame down to the arm pivots shrink to 10: the pivots bolt almost directly under the rails, as on the car;
• the head of the coilover no longer has to fit under a floor. It rises into the wheel arch, exactly as it does in the Seat’s boot. The famous dimension to measure no longer decides anything: it merely sets the height of the wheel arch.

The price is joinery and frame work. Two wheel arches of 73 × 36 cm, 20 cm high, take about a hundred litres out of 2,400. Each side flap gets a notch at the wheel. And the frame is no longer a rectangle: the wheel is in the way of the outer rails, so two rails run inboard of the wheels, and cross-members carry the sides ahead of and behind them.

The layout reorganises itself around a simple rule: whatever needs little height goes above the wheel, whatever needs a lot goes in front or behind. The stove drawer is 22 cm high. It was already level with the axle; it stays there, sitting on the wheel arch. The sink gains a deep drawer, with room for a grey-water can beneath. The fridge leaves the axle line for the rear — and since everything has dropped, its lid goes from 1.27 m to 1.03 m: you can finally reach into it.

Kitchen side. The stove drawer sits on the wheel arch; the sink and the water column, either side, go down to the new floor.

Fridge side. The fridge has moved to the rear; above the wheel, whatever stows flat.

On the road: the centre of gravity drops by 21 cm, cornering rollover goes from 0.58 to 0.71 g, and the limiting gust at 110 km/h from 55 to 66 km/h.

The idea doesn’t combine with the morning’s. With two Mini axles, the wheel arches would be 1.45 m long, 63% of each side: there would be almost no low drawers left.

The bikes come down from the roof

Second question: why insist on lifting three bikes to nearly 2 m? They could sit on a carrier behind the trailer. Or two behind and one in front, on the drawbar.

For wind, it’s no contest. Set crosswise a metre off the ground, the bikes are hit end-on by a crosswind, and they are no longer perched: they hardly count in overturning any more. But it is the nose weight that separates the locations, and there the calculation didn’t say what I expected.

In the middle, nose weight for each location: one dot per loading case, between the 4% and 10% bounds (chart labels in French). Click to enlarge.

• Three bikes at the rear: 40 to 60 kg a metre and a half behind the axle. Depending on whether the trailer is full or empty, with or without bikes, nose weight ranges from 3 to 10% of the mass. Too little on the way home with e-bikes, too much when driving without bikes. It is exactly what caravanners hold against rear bike racks.
• Three bikes on the drawbar: the opposite flaw. The ball unloads as soon as you drive without bikes.
• Two behind, one in front: the front bike balances the rear ones. Nose weight stays between 5 and 8% in every case, as well-behaved as with the bikes on the roof. The heaviest goes in front.

Snaking doesn’t move. Three bikes right at the back raise the trailer’s rotational inertia by 17%, and behind a T5 four times heavier that changes nothing. Behind a saloon it would be another story.

The carrier I’ll build myself, and it is restfully simple: a platform, and a clamp sliding on a rail along the trailer’s centreline. Set the bikes crosswise, push the clamp in until the frames are pressed against bumpers fixed to the body, pin it, padlock it — the clamp doubles as an anti-theft device — then strap the wheels. The model brought out two details. The handlebars have to be turned a quarter turn. And even with the cranks vertical, the pedal sticks out 14 cm: so the bumpers stand 15 cm off the body, otherwise the pedal touches before the frame does.

The rear carrier. The clamp slides on the drilled rail, on the centreline; orange pin and padlock on the slider; orange straps on the wheels; lights and plate repeated behind the bikes.

The same principle on the drawbar, for the heaviest bike. On full lock it stays well clear of the T5.

What this changes in use matters more than the numbers. The mast, jib and winch of the section Lifting three bikes to almost 2 m no longer exist: a bike is loaded at waist height. And the model’s first lesson — the bikes sit on the lid, as long as they’re there the box doesn’t open — falls too.

The box opens with the bikes loaded.

The chosen version

This time I’ve decided: Cordoba axle, lowered body, two bikes behind and one on the drawbar.

Hitched. The whole outfit passes under the T5’s roofline.

At 0.79 g, the rollover threshold meets the grip limit of the tyres on a dry road: the trailer would slide before tipping. And at 1.63 m, the whole outfit passes under the T5’s roof, hence under the same car-park barriers it does.

The price: 74 cm more length, lights and a plate to repeat behind the bikes, bikes exposed to road spray, and a frame more complicated to weld than a rectangle.

Body over the wheels versus lowered body, for the Cordoba and for the two Mini axles (chart labels in French). Click to enlarge.

What I take away

A render is not a check. The first pictures were convincing and rested on an axle 20% overloaded. What moved the project forward wasn’t the 3D model, it was the question “how much does it weigh, and where”.

Distrust a result that’s too comfortable. “Stable above 400 km/h” could have been a bug. The only way to know was to run the same calculation on a case with a known answer. Same reflex as with dimensions that add up: consistency isn’t proof.

Check against the real part. The spring mistake came neither from a calculation nor from a render, but from a generalisation (“on this kind of axle, the spring sits on the arm”) never checked against the actual car. Remembering the car was enough to spot it, and a workshop guide confirmed it.

An absurd error is good news. 164° of articulation, you spot it immediately. The dangerous errors are the ones that give a plausible number — like those 55° that didn’t depend on drawbar length, which only that detail gave away.

Parametrise everything. Switching axles took one line: the body widened, the floor rose, the kitchen drawers got shorter to keep the worktop at 0.95 m, and the calculation moved the axle. On paper, that would have been a week of erasing.

Look for the published method before writing your own. (Added 21 September.) The wind calculation was corrected three times before I asked what the literature said. The answer fitted in three lines and rested on measurements; the home-made model, on stacked assumptions. An AI writes a plausible physical model in thirty seconds, and that is precisely the danger: nothing pushes it to go and check whether one already exists.

A field objection is worth a code review. I can’t compute a lateral lift force. But “I’ve seen tall trailers that don’t suffer from wind”, “a bike isn’t a panel”, “there’s a van in front”: each of those remarks found a real flaw. Make them, and insist they be checked by calculation rather than answered with an argument.

The lever was the architecture, not the calculation. (Added on the evening of 21 September.) A morning spent refining the wind model moved the result by a few km/h. Two design questions — why is the body so high, why are the bikes on the roof — took it from 55 to 91. The AI was diligently optimising the project I had given it; it never questioned it. That was my job, and it took me two days.

What’s left to do

• Measure two dimensions on the Cordoba, car standing on its wheels: the height of the axle beam (it sets the 43 cm under the frame, hence everything else) and that of the coilover’s lower eye (it sets the height of the wheel arch). While there, record the position of the arm pivots and the drilling pattern of their brackets.
• Design the frame for real: two rails inboard of the wheels, cross-members carrying the sides, a tube bridge over each wheel, and sealing of the wheel arches.
• Try the drawbar bike for real: it has to coexist with the jockey wheel and the gas locker door.
• Read the maximum rear axle load off the Cordoba’s manufacturer plate, and check the bushes and bearings.
• Weigh it. The masses in the calculation are estimates. The finished trailer will go on a scale, nose and axle separately, and the axle can still slide a few centimetres along its rails before the final weld.
• Paperwork (French rules). Loaded, the trailer will exceed 500 kg gross weight: it will need its own registration, hence an individual type approval (RTI) from the DREAL for a home-built trailer. Staying under 750 kg means no mandatory brakes and a standard B licence. To be confirmed, along with the towing capacity and gross train weight on the T5’s registration.
• Build light. Every kilo saved on the body is a kilo of margin on the axle and a bit more stability in a crosswind.

Frequently asked questions

Can you use a Mini axle for a trailer?

Yes, for a small light trailer: it’s compact, low, and the 10-inch wheels allow a low floor. But it’s the rear axle of a 650 kg car, designed for something like 450 kg at most. A fitted-out trailer (kitchen, fridge, water, bikes) easily puts more than 500 kg on its axle.

How much nose weight should a trailer have?

Between 5 and 10% of the trailer’s mass, never less than 4% and never more than the car’s tow bar accepts (often 75 to 100 kg). Here, 7% fully loaded, about 44 kg. You get it by placing the axle, not by adding ballast.

Does a coil-spring axle take up more room?

It depends how it’s mounted. A separate spring sitting on the arm fits under the frame when the body sits above the wheels. A combined spring-and-damper unit, as on the Seat Cordoba 6K or VW Polo 6N, rises above the wheel: you have to make room for it in the body, raise the floor, or replace it with a separate spring and damper. Check before concluding, though: under load the spring compresses, and on my trailer the original unit ends up fitting within the depth of the frame, give or take one dimension.

How long should a drawbar be for easy reversing?

What matters is the ratio between the trailer’s ball-to-axle distance and the car’s rear-axle-to-ball distance. Above 2.5, reversing becomes comfortable; here, 2.8 with a 2 m drawbar. Shape matters as much as length: a single central beam near the ball keeps the drawbar’s V from touching the car in tight turns.

Can a light trailer snake behind a van?

Very unlikely if the van is much heavier: the calculation finds no instability below 400 km/h with a 2.4 t T5 and a 0.6 t trailer. The practical risk is crosswind, and above all whatever you perch on the roof.

At what wind speed can a trailer blow over?

It depends on its mass, its track, its height and the speed you drive at. The reference method is Baker and Soper (2018), used for traffic restrictions on bridges. For my 0.6 t trailer: an 85 km/h crosswind gust at 110 km/h with nothing on the roof, 55 km/h with three bikes. Those are wind speeds at trailer height; forecast gusts, measured 10 m up, are about 40% stronger.

Are two axles better than one on a small trailer?

They carry more and hold their line better: the tyres resist yaw nearly five times as much. In exchange, the trailer scrubs its tyres when manoeuvring and can no longer be moved by hand, it weighs more unladen, and if the two axles are independent (rubber suspension), the tow-ball height sets how the load is shared: it has to be towed dead level.

A short glossary

Bogie, tandem — Two closely spaced axles fitted one behind the other under the same trailer.

Coilover (spring-and-damper unit) — A damper with the spring fitted around it; the two go on and come off as one piece. Its head bolts into the car’s body.

Nose weight — The vertical load the trailer puts on the tow ball. Too low or negative, it lightens the back of the car and encourages snaking.

Snaking — Side-to-side oscillation of the trailer which, above a critical speed, grows instead of dying out.

Tyre scrub — Forced sideways sliding of the tyres when a twin-axle trailer turns: its two axles cannot follow the same circle.

Twist beam — An axle where the two trailing arms are joined by a cross-member that twists when the wheels don’t move together; it acts as an anti-roll bar.

Yaw — Rotation of a vehicle about a vertical axis: the nose goes left, the tail goes right.

RTI — Réception à titre isolé: French individual type approval, by the regional authority (DREAL), of a vehicle built or modified as a one-off.

Drawbar — The front part of the trailer, from the chassis to the coupling head.

Track — The distance between the centres of the two wheels on one axle.

References and local copies

• The complete, regenerable model: Blender and Python scripts, remorque.blend, detailed calculation (comments and file names in French) — remorque-famille.zip
• The calculation on its own, readable online (in French): CALCULS.md
• The charts, as vector files (labels in French): limites.svg, architecture.svg, velos.svg
• Baker & Soper (2018), The calculation of the overturning wind speed of large road vehicles at exposed sites (open access) — the wind calculation method, and the measurement of a trailer behind its lorry
• Mechanical Elements: rubber torsion axles fitted in pairs — why they don’t share the load
• Autodoc guide: replacing the rear suspension strut on a VW Polo 6N1 — the source for the spring correction
• The previous post — another part designed in dialogue with an AI, and the trap of dimensions that add up

The first-contribution problem

Everyone gives the same advice: “find an issue tagged good first issue”. It’s good advice and it doesn’t work very well, for a simple reason — those tasks are either trivial enough to teach you nothing, or already taken by someone faster.

What works better, I think, is to start from what you have that others don’t. In my case: an old phone I’d decided to run Linux on, and therefore physical hardware on which to run code other people write blind.

That’s a rarer advantage than it sounds. Plenty of developers work on drivers for hardware they don’t own, relying on datasheets and user reports. Whoever has the device plugged in on their desk can answer questions nobody else can settle.

The thread: a well-scoped task

The postmarketOS project keeps a per-device task list. For mine, an umbrella issue titled “Camera TODOs” listed a dozen items, all ticked except one:

imx355 driver (front camera) is missing features for libcamera, makes the later complain (e.g. when running cam -l)

Clear scope, reproducible symptom, one command to see it. Exactly what you look for.

I ran the command on the phone. It complained, as advertised. I opened the libcamera repository to write the fix.

And the entry was already there.

First lesson: an open issue isn’t necessarily open

Support for that sensor had been added on 17 July 2026, by a Raspberry Pi engineer. The version installed on my phone dated from 10 July.

Seven days apart. The warning I was seeing wasn’t a gap in the project, it was a lag between the released version and the repository.

That’s an easy confusion to make, and it deserves a reflex: before writing any code, check the problem still exists upstream, not just on your own machine. It takes two requests.

F="src/libcamera/sensor/camera_sensor_properties.cpp"
for ref in v0.7.2 master; do
  echo -n "$ref: "
  curl -s ".../repository/files/$(urlencode $F)/raw?ref=$ref" | grep -c '"imx355"'
done
# v0.7.2: 0
# master: 1

Two tasks out of three had evaporated. I could have stopped there feeling I’d wasted my evening. Except that reading the freshly added entry, something was off.

Second lesson: review doesn’t see tables

The entry mapped two test patterns to numeric values. But the sensor’s kernel driver defines those values in the opposite order. “Solid colour” and “colour bars” were swapped.

I checked three times, by independent routes:

And I actively looked for the context in which the author would have been right: his company maintains its own kernel, sometimes with different drivers. I checked — same order in both trees. The error was real, on his own hardware too.

What makes this interesting isn’t the error. It’s that the commit had been reviewed by four people, including the project maintainer, and carried a “tested” tag from a fifth.

How do five competent people miss two swapped values?

Because there’s no logic to review. It’s a correspondence between two documents that don’t live in the same repository: a table on one side, an array of strings in the kernel on the other. To check it you must open both files side by side, or have the device to hand. And “tested” here meant the camera works, I point it at a scene and get an image — which is true, and never exercises test patterns, which are a diagnostic tool.

The rest of the entry was right. Pixel size, sensor delays: everything exercised day to day was correct. Only the part nobody runs was wrong.

That’s where owning the device becomes a decisive advantage. Not because I’m better, but because I was the only one who could put the question to the hardware.

What a two-line patch has to contain

The patch is two lines. Its commit message is thirty, deliberately.

A reviewer should have nothing to go and look up. So I put in the kernel driver’s table quoted verbatim, the output of the command querying my phone, the concrete consequence in one sentence — asking for a solid colour produces colour bars, and vice versa — and the consistency argument with the two correctly described sensors.

And I pre-empted the question that was coming: “are the other entries wrong too?” No, and I checked driver by driver: two other sensors do use the reverse order, because their drivers define it that way. One sentence in the message saves a three-day round trip.

Fixes: a1db25dabaee ("libcamera: camera_sensor: Add Sony IMX355 sensor properties")

git rev-parse --short=12 <reference>

The real work, and the value you can’t prove

Something genuinely missing remained: the phone’s other sensor appeared nowhere. Not in the library, not in the official kernel — its driver was written at a chip maker eight years ago and never sent upstream.

I took the values from the device and from the driver’s source. Three follow rigorously. The fourth doesn’t: it’s a parameter you read in a datasheet, and datasheets for these sensors aren’t public.

I tried to back it up. I found a configuration file, on my own phone, declaring exactly the value I’d assumed. Excellent news for about three minutes — until I checked whether it was independent. It wasn’t: all ten equivalent files in the project declare the same value, including for sensors from three different manufacturers. That wasn’t ten concurring measurements, it was one default copied ten times.

So I wrote it as it stands in the commit message: this value follows what’s documented for sensors in the same family. Not “per the datasheet”, no phrasing that would suggest a measurement. A reviewer with the documentation will correct it in one message, and that’s fine.

Dressing up an uncertainty is the most efficient way to lose a project’s trust on your very first patch.

The prediction I got wrong

Reading the code, I’d worked out what the sensor’s absence caused: without it, the library no longer converts the camera’s gain. It writes a setting number where it should write an amplification factor, and reads the number back as if it were the factor. The auto-exposure loop is wrong in both directions.

From that I made a prediction: after the fix, low-light photos should be better. I set up a clean protocol — phone propped and never moved, objective luminance and noise measurements, a before series and an after series.

Result: 39.2% luminance before, 38.1% after. Nothing.

The explanation is arithmetic, and I had flagged it as a risk before running the test — without drawing the consequence, which was the mistake.

The error is only huge at high gain. My test scene had a saturated white area: auto-exposure had light to spare, stayed near zero gain, and at that point both formulas give the same result.

The patch is still correct, and it works — I verified that differently. After installation, the library emits no warning at all for that sensor, while the phone’s other sensor, unpatched, still emits every one of them. A clean negative control.

But I didn’t demonstrate a visible improvement, so I won’t write that I did. The “tested” tag I’ll attach will say the sensor is now recognised. Not that the images are better.

It’s a distinction that sounds pedantic and isn’t. A correct piece of reasoning about a mechanism says nothing about its magnitude under test conditions. I had the mechanism; I didn’t have the magnitude.

The find that was on no list

Throughout all this, the camera app kept freezing. A nuisance, which I worked around by relaunching.

Then I instrumented it, for lack of anything better. And it turned out that a single line, emitted once at initialisation, explained everything:

Importing input DMABuf failed, falling back to upload

Image processing runs on the graphics processor. Normally the raw frame reaches it without a copy, through shared memory. Here the import fails — and the library switches to copy mode: twelve megapixels transferred to the GPU on every frame. The memory bus saturates, the display can no longer get bandwidth for its own operations, and the pipeline ends up strangled.

It isn’t a crash. It’s a suffocation, which explains why it left no usable trace.

And here’s what gives that line its value. It comes from a patch added by the package maintainer, who had deliberately restored it after the upstream project removed it. His rationale:

failing imports majorly impact performance and indicate actionable issues in the V4L2 or GPU drivers.

So the maintainer had planted the detector, stating in writing that its firing warrants investigation. It fired on my phone. Nobody had reported it.

I haven’t proved causation yet — the correlation is clear, the mechanism coherent, and a simple test would settle it. But it is by far the most useful thing I found that morning, and it was on no task list.

What I take away, for next time

What you bring isn’t talent, it’s a position. I wasn’t better than anyone. I had the device plugged in and five competent reviewers didn’t. That’s all, and it’s enough.

Check the problem still exists before writing. Two tasks out of three had evaporated, fixed upstream but not yet released. Two requests would have said so immediately.

A confirming source is only useful if it’s independent. Ten documents copying the same default are worth no more than one.

Separate what’s demonstrated from what’s inferred — in a commit message as in conversation. I had a correct mechanism and a wrong prediction; stating one without the other would have been a polite lie.

And instrument what annoys you. The app freezing was a nuisance I’d been working around for hours. It was when I stopped working around it that I found the one thing nobody else was looking for.

It really is a ball of string: you pull on a two-line thread, and three things you never asked for come out with it.

The starting point: three views, seven dimensions, and the original part next to them. This photo is everything the AI will ever have of this suction cup.

The problem isn’t drawing, it’s understanding each other

I had a rubber suction cup to remake and a freshly calibrated printer. The modelling itself isn’t the point: a suction cup is a disc, a cylinder, a stud and a bore. Any CAD program does it in ten minutes — provided you know what you’re drawing.

The point is that I wanted an AI to draw it. Not out of convenience: because I wanted to see where it breaks. An AI writing code has the shortest possible feedback loop — the code runs or it doesn’t. An AI drawing a mechanical part has no feedback loop: it cannot see the object, cannot measure anything, and its result only becomes wrong at the moment the part comes off the printer and won’t go into its socket. Everything in between is conversation.

So I made a sketch. Three views, dimensioned, tidy: what you’re taught in technical drawing. And that’s where it gets interesting, because that sketch is correct — and it wasn’t enough.

Six questions asked on my own photo

The AI’s first move, and it was the right one: don’t guess. It took my photo, dropped six numbered red markers on it, and sent the image back with its six questions attached to precise spots on the drawing.

The six ambiguities, marked on the sketch itself. Annotating the image rather than describing in words: the only thing in this whole story that worked first time.

I already knew that method: it comes from the previous post, where describing a measuring gesture in prose blocked me twice in a row, and where annotating my own photo unblocked it in a single send. It works both ways. When the AI doesn’t understand my drawing, it has to show me where it doesn’t understand, not ask me to “please clarify the dimensions”.

And yet. I answered all six, one line each. “It’s a section view of the same part, it shows the thickness of the cup.” “That’s the hole, underneath the cup.” “3 mm across and 4 mm deep.” “It’s blind.” Six exact, unambiguous answers. After which the geometry was still wrong.

What a sketch lacks isn’t dimensions

Here’s the knot. My sketch carried every dimension needed. What it didn’t carry is what each dimension attaches to — and that is precisely what a freehand drawing fails to convey, whereas a proper dimensioned drawing conveys it through the position of the extension lines.

An example. I had written “6.5 mm” with a vertical arrow to the right of my section. Obvious to me: the height of the shaft. Just as obvious to the AI: the overall height, since the arrow runs from one end of the drawing to the other. Both readings hold up on a photo taken at an angle, where the arrow overshoots slightly.

Same with the hole and the stud, both roughly 3-and-a-bit millimetres, at opposite ends of the part. I wrote “3” on one and “3.5” on the other knowing which was which. Nothing on the paper said so.

What works: make it show, not say

After the sixth exchange, a change of method: instead of asking a seventh question, the AI modelled the part with its assumptions, rendered it, and sent it over — with an explicit colour code on the dimensioned section: red for the dimensions that came from me, cyan for the ones it had invented.

I looked at the render for three seconds and wrote: “from the top of the stud to the edge of the lip, the cup is 10.5 mm. 2 mm of stud, 6.5 mm of shaft, 2 mm of cup body.”

Same part, same dimensions, two readings. Left, what the AI had understood; right, what I had drawn. No question would have produced that sentence — the wrong drawing produced it.

That’s the interesting reversal. An open question (“what does the 6.5 measure?”) asks me to rebuild the context mentally, recover what I had in mind three days earlier, and formulate an answer into the void. A wrong render puts the geometry in front of me, and my eye corrects faster than my memory. The correction costs nothing any more: I can see the shaft is squashed, so I know what to say.

There’s a condition for this to work, and it isn’t trivial: the AI has to flag what it invents. A clean render, with no distinction between what came from me and what it filled in, would have had me approving a part containing five values pulled out of thin air. The cyan on the section is the admission of ignorance made visible. It is what turns the render into a measuring instrument rather than an illustration.

The trap of the sum that adds up

This is the part I find most instructive, and it’s worth pausing on.

When the AI produced its second version — the one with the shaft, still wrong — it explained that it had finally managed to place the last orphan dimension from my sketch, the infamous 3.5. Its demonstration: the cup body is 1.0, the shaft 3.5, the stud 2.0, total 6.5, exactly the overall height on the drawing. Every dimension closed on the others. It wrote, and it was sincere: “your five dimensions close on each other, which is a good sign for my reading.”

Except it was wrong. The 6.5 wasn’t the overall height, the 3.5 wasn’t the shaft height, and the reconstructed part looked like nothing on earth. The correct reading gives 2 + 6.5 + 2 = 10.5, and the 3.5 is the bore diameter — a dimension with nothing to do with a stack of heights.

A sum that adds up is not proof. With seven dimensions and a part of revolution, there are enough degrees of freedom for wrong combinations to close by chance. Arithmetic consistency is weak evidence, and it’s exactly the kind of weak evidence an AI presents with confidence because it looks like a verification. It is reasoning with the shape of a proof and none of its force.

What settled it wasn’t a calculation: it was that the drawn part didn’t look like the part on the table. The only judge here is the object.

When a word is the blocker, colour it in

One last blocker, of a different kind. For a suction cup to hold, its underside must not be flat: it rises slightly towards the centre. For want of a better word I call that the “hollow”. You press, the trapped air escapes past the lip; you let go, the rubber tries to resume its shape, pressure drops in the cavity, and atmospheric pressure holds the part down. That’s the entire mechanism.

Except my part also has a blind hole in the middle. So when someone said “hollow”, I answered: “what do you call the hollow? in the middle of the cup there’s a hole 3.5 mm across and 4 mm deep, is that the recess at the centre?”

Rephrasing would have got nowhere — the word was already taken. What worked fits in one image:

The hollow is the blue. The hole is the white one, at the opposite end. Colouring in the volume you’re talking about settles in one image what three paragraphs would not.

The general lesson: when an exchange stalls on a word, it isn’t a vocabulary problem but a referent problem. Don’t define the word better — point at the thing. In geometry, pointing is done with colour.

One detail that matters: on its first sections, the AI drew the bore as a white rectangle overshooting below the part and into the hollow, “so you can see it clearly”. I told it so — that view was less clear, because an overshooting outline suggests geometry that doesn’t exist, and it overshot precisely into the area we were trying to discuss. A technical diagram doesn’t improve by exaggerating lines; it improves by framing the relevant area and colouring the volumes.

The part

The finished part: Ø19.5 cup, 2 body, Ø9 × 6.5 shaft, Ø3 × 2 centring stud, Ø3.5 × 4 blind bore. 10.5 overall.

The model is a 120-line Python script using manifold3d, a solid geometry library. The part being a body of revolution, everything fits in a (radius, height) profile that gets swept:

def profil(n=80):
    """Closed (r, z) contour of the half-section, counter-clockwise."""
    p = []
    r = np.linspace(0, R_INT, n)                    # underside: parabolic concavity
    p += [(x, CREUX * (1 - (x / R_INT) ** 2)) for x in r]
    p += [(R_EXT, 0.0), (R_EXT, E_LEVRE)]           # lip: flat seat then flank
    r = np.linspace(R_EXT, R_FUT, n)                # top of the body, slightly domed
    t = (r - R_FUT) / (R_EXT - R_FUT)
    p += [(x, E_LEVRE + (Z_FUT - E_LEVRE) * (1 - u) ** BOMBE) for x, u in zip(r, t)]
    p += [(R_FUT, Z_TET), (R_TETON, Z_TET), (R_TETON, H), (0.0, H)]
    return p

m = Manifold.revolve(CrossSection([profil()]), 128) - trou

What makes the exercise workable isn’t the library: it’s that every dimension is a constant at the top of the file, each commented with where it came from — sketch, deduction, or assumption. Changing a value and regenerating the STL takes ten seconds. Over five round trips, that’s the difference between a conversation and a chore.

Drawing for TPU isn’t drawing a suction cup

The spool that started all this. The label says 20 to 40 mm/s — while noting, a little higher up, that it targets direct-drive printers.

A real suction cup is silicone or soft PVC, around 40 to 60 Shore A. The most common TPU, the one I have, is 95A: roughly the hardness of a trolley wheel. That isn’t a settings detail, it’s a design constraint.

A thick 95A lip won’t conform to the micro-defects of the surface: it will sit on three high points and leak between them. So the lip has to be thin, 0.6 to 0.8 mm, thin enough to flex — at the cost of fragility. And it gets worse: a fused-filament part is a stack of welded beads, and between two beads there remain micro-channels. On a cosmetic part nobody notices. On a part whose job is to hold a vacuum, they’re leaks. Hence thin layers, a high temperature and a slight excess of material — not for strength, but to weld the layers to each other.

That’s the kind of trade-off a dialogue with an AI surfaces well, provided you give it the material before the geometry. Had I asked for “a suction cup” without saying more, I’d have got a 2 mm lip: correct in moulded rubber, useless here.

TPU on a remote-extruder printer: the worst case

Then it has to be printed, and that’s where my machine speaks up. On a FLSun QQ-S, the motor pushing the filament isn’t on the head: it’s on the frame, and the filament travels about 700 mm through a guide tube before reaching the nozzle. That’s a Bowden setup. With rigid filament it works: the filament behaves like a rod being pushed. With flexible filament it behaves like a spring — you push at one end, nothing comes out the other, then it all comes out at once.

Three consequences, and they show up in the slicing profile:

• Retraction. My PLA profile retracts 5 mm. On TPU, 5 mm slackens the filament enough that it can coil at the tube entry and jam — that’s the failure mode of flexibles in Bowden. Down to 2 mm, at reduced speed.
• Speed. The label says 20 to 40 mm/s, assuming a direct extruder. In Bowden, 15 to 25.
• Acceleration. On a fast delta, jolts get absorbed by the elasticity of the filament rather than by the nozzle: material goes missing in the corners. Brought down from 1500 to 800 mm/s², restored at end of print.

What I take from it

An AI that draws has no feedback loop. It can’t see the part, can’t measure anything, and its mistake only becomes visible at print time. The whole job is to build that feedback loop by hand — and the render is it.

Showing beats asking. An open question asks me to rebuild context; a wrong drawing puts the geometry in front of me and my eye corrects on its own. Six questions didn’t converge; two renders did.

The AI must flag what it invents. The red/cyan code — your dimensions, my assumptions — is what turns a pretty render into a measuring instrument. Without it I’d have approved five values from nowhere.

Arithmetic consistency is not verification. My dimensions closed perfectly on a wrong part. An AI presents that kind of evidence with the confidence of a proof, because it has the shape of one. The only judge is the object on the table.

When a word blocks, point at the thing. No rephrasing: an image where you colour in the volume you mean.

Material comes before geometry. “A suction cup” and “a suction cup in 95A TPU printed by fused deposition” are not the same part, and you don’t get the second by tweaking the settings of the first.

And parameterisation makes it all bearable. Five successive versions, ten seconds each. Had every correction meant reworking a CAD model, I’d have given up at the second render and drawn the part myself — which, frankly, would have been perfectly reasonable.

Where things stand

To reproduce

What you need: the original part, calipers, something to sketch on, and a Python environment with manifold3d, numpy and matplotlib. No CAD program.

The sketch. Three views beat one perspective. But above all: write next to each dimension what it measures, in words. “6.5 = shaft height”, not “6.5”. It’s ugly on a proper drawing; it’s what saves you five round trips here.

The loop. At every iteration, demand three outputs: the STL, a 3D view (does it look like the object?) and a dimensioned section (are the dimensions in the right places?). The section finds the errors; the 3D view finds the absurdities.

The colour code. Explicitly ask that dimensions taken from your sketch and those invented by the AI be distinguished on screen. It’s the highest-yield point in the whole method.

The drawing rules that emerged, for a readable technical diagram: every shape stops at its real geometry, never an outline overshooting “so you can see it”; text outside the part, never on top of it; frame on the area under discussion — a 1 mm hollow is invisible at the scale of a 20 mm part; and colour volumes rather than thickening lines.

The files: the model ventouse.py and the STL it produces; the slicing profile qqs-tpu.ini (PrusaSlicer on the command line, 260 mm delta, 0.4 nozzle); and esp32-supermini-tray.py, an earlier part made with the same toolchain, to compare a prismatic geometry with a revolved one.

The TPU profile in short, if you print flexibles in Bowden: 2 mm retraction at 25 mm/s, perimeters 15–20 mm/s, acceleration 800, nozzle 225–230, bed 45–50, fan 40–60 %, a first layer less squashed than usual (flexibles push back instead of spreading), and a glue stick on the glass as a release agent — TPU sticks well enough to pull out a chip.

Frequently asked questions

Can you really do CAD by talking to an AI, with no software?

For a simple, well-defined part, yes, and the result is parametric, versionable and commented — three things a CAD file does badly. For a part whose shape you don’t yet know, no: the dialogue costs more than the sketch. The tipping point is roughly where you can describe the part in one sentence.

Why wasn’t my dimensioned sketch enough?

Because a freehand sketch carries the dimensions but not their attachments. On a proper drawing, the position of the extension lines says what a dimension refers to; freehand, on a photo taken at an angle, that information disappears. Writing out what each dimension measures restores it.

Can an AI invent dimensions without saying so?

It necessarily does — a part has more dimensions than a sketch carries. The question is whether it flags them. Insist that invented values be marked in the render and commented in the code; it’s checkable at a glance, and it changes everything.

Is 95A TPU suitable for a suction cup?

It’s considerably harder than the silicone of a real cup (40–60 Shore A). It can work on a very smooth surface with a thin lip and thin layers, but don’t expect the grip of a moulded part. A softer TPU, 85A, would suit the job better — and be far harder to print in Bowden.

Do you need a direct extruder for TPU?

Not for 95A; in practice yes for 85A and softer. In Bowden, what matters most isn’t tube length but the extruder: a dual drive grips the filament on both sides, where a single wheel lets it escape. A 1.9 mm bore tube completes it nicely.

Why not mount the extruder on a delta’s head?

Because moving mass is the critical parameter there, and it penalises all three axes at once. Doubling the effector’s mass drops the resonant frequency by a factor of √2; below 25 Hz, software compensation starts rounding off detail. See the panel in the Bowden section.

How long did the whole thing take?

About an hour of conversation, five versions of the model. Most of that time went into clearing six sketch ambiguities — not into drawing.

Small glossary

Bowden (setup) — The motor pushing the filament is fixed to the frame, and the filament reaches the nozzle through a guide tube. Lightens the moving head, but introduces elasticity into the push.

Direct drive — The opposite: the motor sits on the head. Better control of the material, heavier head.

Effector — On a delta printer, the moving part carrying the nozzle, suspended from the three pairs of arms.

manifold3d — A solid geometry library guaranteeing always-valid meshes; you describe the part in Python through boolean operations and revolutions.

Pressure advance — Software compensation for the lag between the extrusion command and material actually coming out, caused by filament compressibility. Higher the softer the setup.

Retraction — Pulling the filament back during non-extruding moves, to avoid stringing. Long in Bowden, very short in direct.

Shore A — Hardness scale for elastomers. Suction-cup silicone is 40–60, a door seal 70, common printing TPU 95, a trolley wheel 98.

STL — A file format describing a surface as a triangle mesh. What the slicer expects.

Slicer — The software turning an STL into nozzle paths. Here PrusaSlicer, driven from the command line by a profile file.

TPU — Thermoplastic polyurethane: the most common flexible filament.

References and local copies

• The model and its outputs: ventouse.py, ventouse.stl
• The TPU slicing profile: qqs-tpu.ini
• A prismatic part made with the same toolchain: esp32-supermini-tray.py
• manifold3d — the solid geometry library used here
• Klipper documentation — measuring resonances — on the 25 Hz threshold and the mass/stiffness trade-off
• The previous post — calibrating the same machine, where the annotated-photo method was born

The back of the device. “Model G020F” — the European variant. Beside it, the CE mark and the crossed-out bin, that pictogram meaning “do not dispose of with household waste”. It took seven years for that symbol to stop being a formality and become the subject.

What “end of support” actually means

The Pixel 3a came out in May 2019. It was the sensible one of its generation: a remarkable camera for €400, a headphone jack the flagships had already dropped, an unassuming Snapdragon 670 processor. Google updated it until 5 May 2022. The last build installed on this one is numbered SP2A.220505.008 — Android 12, May 2022 security patch.

Nothing since. Not because the hardware failed: it works perfectly. Because a company decided a period had elapsed.

“The device is no longer supported” is a sentence you read without thinking. Let’s translate it. The processor, the screen, the cameras, the modem, the battery — all still work. What stops is a service: someone, somewhere, stops compiling software for this particular combination of chips. The phone doesn’t become faulty, it becomes orphaned. And because the software it runs cannot be modified by its owner, orphaned means doomed.

Except this one was a Pixel. And Pixels have a rare property: Google, unlike almost all its competitors, lets the owner unlock the bootloader — the small program that decides which operating system is allowed to start. That permission, which I’ll come back to, is what separates a recoverable device from a brick.

Three ways to put Linux on a phone, and only one that counts here

An Android phone already runs a Linux kernel. But an Android kernel is an old version of the official kernel, to which the chip maker has added thousands of changes it never publishes upstream. That code lives only as long as the product does. Which is the whole difference between the three options on the table:

Ubuntu Touch is objectively the better choice for using this phone: calls, SMS, 4G, Bluetooth, NFC, both cameras, the fingerprint reader — it all works. But it gets there by reusing Android 9 binary drivers. That is, by embalming 2019. Nothing fixed there benefits anyone else, and the day that base rots, there’ll be nothing to do about it.

postmarketOS takes the opposite road: run the official Linux kernel, the one everyone uses, on this chip. It’s harder, things are missing, and that’s precisely the point — what gets written there flows into the kernel the whole world will be running in ten years. A group of developers works on this specific processor under the name sdm670-mainline.

So the choice was simple, provided I accepted what it implies: this phone will not be my phone. It’s a test bench.

Unlocking, and the factory-reset trap

The device arrived factory-reset, which seemed like a simplification. It wasn’t.

To unlock the bootloader you must enable a setting called OEM unlocking in Android. That setting stays greyed out until the phone has reached the network at least once: Google checks the device isn’t reported stolen. So you have to boot the phone, walk through the setup wizard, connect Wi-Fi — and only then enable the option. On a device you’re about to wipe entirely, it’s an absurd but mandatory detour.

Second trap, nastier: the key combination to enter fastboot mode — the bootloader’s maintenance mode — is Volume Down + Power, but only from a completely powered-off phone. On a running device, that same combination takes a screenshot. You press, nothing expected happens, you try again, you start doubting your hardware. You must power off, wait two seconds, hold Volume Down first, then press Power.

The rest is one command, plus a red warning on screen to confirm with the physical buttons:

fastboot flashing unlock

The fastboot screen after the operation. “Device state: unlocked” in red: the phone will now boot a system that Google hasn’t signed. Note “sargo MP1.0 (ROW)” — sargo is the Pixel 3a’s codename, ROW confirms the international variant.

The phone wipes everything and reboots. From there, it doesn’t really belong to Google any more.

Building the system: half an hour of questions

On the computer side, postmarketOS is built with a tool called pmbootstrap, available in most distributions’ repositories. It doesn’t download a ready-made image: it assembles the system for your exact device, in an isolated environment, asking you about twenty questions along the way.

Most call for the default. Three deserve thought, and I settled all three on the same principle: stick to what the maintainers test.

That principle is worth spelling out, because it’s counter-intuitive. When you install a system for yourself, you pick what you prefer. When you install it to contribute, every departure from the majority choice is one more variable that will make your bug reports useless. If I report an audio problem on a stack nobody else runs, the maintainer can neither reproduce it nor compare it. My report becomes noise.

So I took pulseaudio over the more modern pipewire, wpa_supplicant over iwd, the Phosh desktop over the very tempting sxmo, and — reluctantly — systemd. On that last point, postmarketOS is one of the few places where OpenRC remains a first-class citizen; my instinct wasn’t fringe at all. But four of the fifteen open bugs for this device are reported under Phosh with systemd, and journalctl remains the handiest way to extract a clean trace.

Two answers deserve a warning.

Don’t enable disk encryption. The option is there, it’s tempting, and on this phone it makes the device unbootable: an open bug describes a system that doesn’t detect keyboard input at boot. You end up with a machine asking for a passphrase you cannot type.

Keep the locale in English. Counter-intuitive for a francophone blog, but error messages and logs will come out in English, hence directly pasteable into a report and comparable with everyone else’s. It in no way prevents an AZERTY keyboard.

Channel          edge          # where bugs get reported and fixes land
Vendor           google
Device           sargo
UI               phosh
Audio backend    pulseaudio    # default
WiFi backend     wpa_supplicant # default
usb-moded        developer     # USB networking ALWAYS on — the safety line
Service manager  default       # systemd for Phosh
Locale           en_US

libcamera-tools,v4l-utils,evtest,tmux,vim,strace,usbutils

curl -s -o idx.tar.gz \
  "https://dl-cdn.alpinelinux.org/alpine/edge/community/aarch64/APKINDEX.tar.gz"
tar xzf idx.tar.gz -O APKINDEX | grep '^P:' | sed 's/^P://' > packages.txt
grep -qx "libcamera-tools" packages.txt && echo present

Half an hour later the system was built. It just had to be written to the phone. That’s where the evening derailed.

An hour blaming the wrong culprit

The phone was in fastboot mode, plugged in, recognised. The write command would start — and hang. Indefinitely. Without a single error message, on standard output or on standard error. A sleeping process, forever.

What made it disorienting was that the device seemed perfectly present:

$ fastboot devices
058AY1WZGT     fastboot

It answered. It was there. And yet every write hung.

I formed four theories. All four were wrong, and ruling them out took an hour. They’re worth listing, because they’re exactly the ones anyone would form.

A permissions problem. The classic: the USB node belongs to root, the user has no write access. Checked — the file carried an access control list explicitly granting my account. Ruled out by measurement, not by assumption.

A bad cable or port. That’s the next reflex, and the most common answer on forums. Except the kernel logs were impeccably clean: high-speed enumeration, no error, no reset, no spurious disconnect. A damaged cable leaves traces; there were none.

A USB controller problem. A serious lead: Pixels are USB 2.0 only, and modern controllers are known to be temperamental with certain bootloaders. The usual advice is “plug into a USB 2.0 port”. Two measurements ruled it out: the phone was already negotiating at 480 megabits, so already USB 2.0, and the machine’s motherboard (an Intel Raptor Lake) no longer has a legacy companion controller — everything goes through the same block. “Switch to a USB 2.0 port” was meaningless.

A software regression. pmbootstrap runs its own copy of fastboot, version 37, whereas my system had version 35. So I bypassed the tool and flashed directly with the system’s binary. It hung in exactly the same way. Theory dead.

Four leads, four dead ends. And one detail that should have alerted me far sooner: on every fresh entry into fastboot mode, the first command went through — in thirteen milliseconds — and every one after it hung.

That fact had been in front of me from the start. It took me an hour to listen to it, because I kept questioning the device instead of questioning the system.

The answer was sitting in a file

Fastboot mode is a conversation: the computer asks, the bootloader answers. I eventually looked not at what the phone was answering, but at what the Linux kernel thought of it. That information lives in /sys, a virtual filesystem where the kernel exposes its internal state as readable files.

$ cat /sys/bus/usb/devices/1-9/power/control
auto
$ cat /sys/bus/usb/devices/1-9/power/autosuspend_delay_ms
2000
$ cat /sys/bus/usb/devices/1-9/power/runtime_status
suspended

Asleep.

To save power, the kernel suspends USB devices after an idle delay — here, two seconds. That’s normal and desirable behaviour for most devices, which know how to wake when spoken to again. The Pixel bootloader doesn’t. Once asleep, it never answers again.

Everything falls into place at once:

The fix is a three-line rule telling the kernel never to suspend Google devices:

# /etc/udev/rules.d/52-fastboot-no-autosuspend.rules
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", \
    TEST=="power/control", ATTR{power/control}="on"

Except it changed nothing. And the reason it failed is the most interesting part of the story.

The second culprit, hiding behind the first

My rule was in fact correct — udev’s own test tool confirmed it was being evaluated and applied. But after each plug-in, the setting fell back to auto.

Someone was coming along behind me. That someone was TLP, a power manager widespread on Linux laptops, which applies its own USB autosuspend settings after udev and therefore silently overwrites yours. Plenty of people install it once for battery life and then forget about it entirely.

TLP has an option meant precisely for this:

# /etc/tlp.conf
USB_EXCLUDE_PHONE=1
USB_DENYLIST="18d1:4ee0 18d1:4ee1 18d1:4ee2 18d1:4ee3 18d1:4ee7"

This time the setting held. One detail worth knowing: applying the fix does not unstick an already-sleeping device. The bootloader’s USB state only recovers on re-enumeration. So you fix it, then leave and re-enter fastboot mode.

And to maximise the odds, I grouped the three writes into a single invocation rather than three successive processes:

fastboot flash vbmeta   vbmeta.img \
         flash boot     boot.img \
         flash userdata google-sargo.img

Sending 'vbmeta_b' (4 KB)                   OKAY [  0.120s]
Writing 'vbmeta_b'                          OKAY [  0.071s]
Sending 'boot_b' (28008 KB)                 OKAY [  0.747s]
Writing 'boot_b'                            OKAY [  0.194s]
Sending sparse 'userdata' 1/9 (258751 KB)   OKAY [  6.306s]
...
Finished. Total time: 94.883s

Ninety-five seconds. After an hour of deadlock.

lsusb | grep 18d1

cat /sys/bus/usb/devices/<port>/power/runtime_status

sudo readlink /proc/<pid>/root        # is it running in a chroot?
sudo ls -l /proc/<pid>/fd | grep usb  # did it open the device?

What booted

Twenty seconds after the reboot, the machine saw a network interface appear. The phone was handing out addresses itself.

$ ssh sam@172.16.42.1
$ uname -r
7.1.3-sdm670
$ df -h /
/dev/loop0p2   47.9G   2.2G   43.2G   5% /

Kernel 7.1.3. On a phone whose manufacturer stopped caring in May 2022, with an Android kernel frozen at 4.9. The filesystem had grown by itself on first boot to fill the available 48 gigabytes.

First boot. The screen has been cracked for a long time; the device itself has just got four years younger.

The quick settings panel. Wi-Fi, Bluetooth, battery at 94%. And in the notifications, the “USB Developer mode” selector — exactly the profile chosen at install time, the one that keeps USB networking permanently on. The clock reads “Thursday, January 1, 4:12 AM”: the hardware clock hasn’t been set yet, nobody has told it what day it is.

The camera, or how a well-written tool hands you the work

All that remained was to check what I’d come for. On postmarketOS, cameras go through libcamera, a free library replacing Android’s proprietary stack. A known bug reports that this phone’s front sensor driver is incomplete, and that cam -l — which lists cameras — complains about it.

Complain it did. But far better than I’d hoped:

ERROR V4L2 'imx355 4-001a': Unable to get rectangle 2 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 1 on pad 0/0
ERROR V4L2 'imx355 4-001a': Unable to get rectangle 0 on pad 0/0
 WARN  'imx355 4-001a': Failed to retrieve the sensor crop rectangle
 WARN  'imx355 4-001a': The sensor kernel driver needs to be fixed
 WARN  See Documentation/sensor_driver_requirements.rst

There’s something delightful about software that literally tells you “the sensor kernel driver needs to be fixed” and hands you the reference to the document explaining how. It is the exact opposite of error 4202 on a vacuum cleaner.

Concretely: the driver can’t answer when asked for the real dimensions of its pixel array. libcamera then invents defaults and works on approximate geometry.

But the output also revealed this, which I wasn’t expecting:

WARN 'imx363': No static properties available — Please consider updating the database
WARN 'imx355': No static properties available
WARN IPASoft: Failed to create camera sensor helper for imx355 / imx363

This second problem isn’t in the kernel. It’s two data tables inside libcamera itself, where the Pixel 3a’s sensors are missing — while dozens of others are already there, providing a template to copy. Pure data, no algorithms.

Update, a few hours later. Going to write that patch, I found half of it had just been done: the front sensor, the imx355, was added upstream after the 0.7.2 release this phone runs. The warning above is therefore a version artefact, not a gap — an update will settle it. The rear sensor, the imx363, is still absent from the whole repository, and its driver isn’t even in the official kernel: it was written at Intel, never sent upstream, and postmarketOS loads it as a module.

And comparing the fresh imx355 entry against what the driver actually exposes on the device, something is off: it maps “colour bars” to value 1 and “solid colour” to value 2, where the driver does exactly the reverse. Two other sensors with an identical menu, the imx258 and the imx471, are described correctly right beside it. So that’s two patches instead of one — and the easier one is the patch nobody was expecting.

In other words: the first patch to write isn’t the one I came for. It took powering on the real hardware to notice. That’s a fairly general lesson — you can read bug reports for days without seeing what a running machine tells you in three seconds.

Why this isn’t just a hobby

The very morning this phone booted, the account balade.nomade posted a reel (local copy of the caption and comment thread) summarising what’s currently in play in Brussels. It ends on a question I think is well put:

Are you ready to scan your ID card in order to use Instagram?

The tone is activist, so I checked the three claims. Two hold up solidly, the third deserves a caveat — and the comment thread added a fourth, more relevant to this post than the other three.

Chat Control. Accurate. The EU regulation known as CSAR remains stuck in trilogue, with negotiations resuming in late September 2026 under the Irish Council presidency. On 9 July 2026, the European Parliament voted 314 to 276 to strip out the mechanism — short of the 360 votes needed to block the Council’s position. The derogation permitting “voluntary” message scanning was therefore extended to 2028. Client-side scanning was removed from the latest draft, but the Council’s own legal service, in an opinion dated 10 June 2026, considers that voluntary scanning still amounts to a generalised search of communications, incompatible with Article 7 of the Charter of Fundamental Rights.

The end of anonymity. Accurate, with a development the reel doesn’t mention: the French law of 21 July 2026 banning social media for under-fifteens was struck down on 14 August by the Conseil constitutionnel (decision no. 2026-911 DC) as a disproportionate infringement of freedom of expression and privacy. It will not take effect as drafted. But the underlying movement continues elsewhere: the European Commission announced on 15 April 2026 that its age-verification solution was ready for deployment, and the European digital identity wallet is due in member states by year’s end.

Metadata. Here I’ll add a caveat. The EDPB did adopt new anonymisation guidelines on 7 July 2026, open for consultation until 30 October, replacing the 2014 reference opinion. But it’s a technical clarification, not a fist on the table. And recent case law points the other way: the Court of Justice of the European Union, in September 2025, adopted a relative approach — the same pseudonymised data can be anonymous to a party with no means of re-identification, and personal to another.

The fourth point, the one that’s really about this post

In the comments, someone flags that Google is changing its app installation policy and worries this will “put GrapheneOS in danger”. The author’s reply rightly corrects the fear, and the facts bear them out.

Since August 2025, Google has required that every app installed on a certified Android device come from a verified developer — including when you install an APK file by hand, outside any store. The first user-visible restrictions land on 30 September 2026 in Brazil, Indonesia, Singapore and Thailand, before a global rollout in 2027. Installing an app from an unverified developer will go through a roundabout flow with a mandatory twenty-four-hour waiting period. And to become verified, a developer must open an account, pay twenty-five dollars and supply government-issued identity documents.

Reread the reel’s question, and swap the user for the developer. It’s the same gesture: an identity document as a condition of access. One side to read, the other to write.

The commenter was wrong on one point, though, and it’s the one that matters. The requirement applies to certified devices — those shipping Google’s services under licence. GrapheneOS doesn’t ship them: it falls outside the perimeter. So the restriction doesn’t endanger de-Googled systems, it makes their existence more necessary.

Installing your own software, that fight

This is what exasperates me most, and it predates all of this news. On Android as on iOS, installing software you compiled yourself, or pulled from a Git repository, is an obstacle course.

On Android you have to allow an unknown source, click past three warnings, and soon dig through the developer options and then wait twenty-four hours. On iOS it’s worse: an app you compile and sign with a free Apple account stops working after seven days and must be reinstalled from a computer. For it to survive, you pay ninety-nine euros a year. The European Digital Markets Act cracked the door open in 2024 — alternative marketplaces, distribution from your own website — but only within the Union, and on Apple’s terms.

The justification is always the same: security. It deserves to be taken seriously, and therefore examined.

If openness caused insecurity, we’d see it. Linux lets you install anything from anywhere — a repository, an archive, code you compiled by hand — and it isn’t a security disaster: it’s the system running most of the planet’s servers, under permanent attack. Windows, conversely, long had the most permissive model and the worst reputation. If the theory held, Android and iOS would be the safest systems ever built. What we observe is roughly the opposite of what it predicts.

So what protects isn’t closure, it’s a verifiable chain of trust: signed repositories, identified maintainers, source code anyone can read, reproducible builds. Security comes from transparency, not from permission. And that chain already exists on Android: F-Droid has for years distributed free software built from public sources, with no toll and no identity document.

Meanwhile, the official store lets things through. In 2026, a malware family named NoVoice was found in more than fifty Play Store apps, totalling at least 2.3 million downloads — with root access and surviving a factory reset. The year before, the SlopAds campaign: 224 apps, 38 million downloads. And Google banned 80,000 developer accounts in 2025, under a regime that already requires identity verification to publish on the Play Store.

That figure settles the argument. Developer verification already exists where it’s meant to protect, and eighty thousand accounts still have to be banned every year. Extending it to manual installation won’t stop the industrial campaigns — they come through the front door, and it’s documented. It will stop the lone developer publishing their code to a Git repository.

The risk itself is real: someone installing a file received by text message does indeed get caught. But that argues for a clear warning, not an entrance fee. You protect someone by telling them what they’re doing; you don’t protect them by charging the person who writes.

And there’s one criterion that settles the question. To operate an alternative marketplace in the European Union, Apple requires, as of 1 October 2026, that you be publicly traded, or venture-funded, or have passed a financial audit, or total one million annual installs. Not one of those criteria measures the security of anything. They are criteria of size.

I’m willing to grant good faith on the principle. I have more trouble when the same company locks the door and holds the till.

What that changes for an old phone

The common thread is technical, and it’s what connects this news to a 2019 Pixel.

Client-side scanning means inspecting messages on the device, before encryption. Such a mechanism isn’t implemented in an app: it’s implemented in the system. That’s the decisive shift. As long as the guarantee rested on the protocol, it could be audited from outside. Once it rests on the device, the only question that matters becomes: who decides what this device does?

On a phone whose system cannot be replaced, the answer is: the manufacturer. And through it, whoever legislates on the manufacturer. That’s not a scandal, it’s a perfectly ordinary chain of decision — but at no point does it pass through the owner.

Both existing escape hatches — GrapheneOS, postmarketOS — rest on exactly the same thing: a bootloader you’re allowed to unlock. The same checkbox in the developer options that opened this evening. The entire practical way out, for Android, has so far hung on one manufacturer’s goodwill about one setting. GrapheneOS runs on Pixels only; it will take Motorola’s 2027 flagships for that to stop being true.

And I should say what this post does not demonstrate. postmarketOS on a Pixel 3a is not a privacy solution. The modem remains a black box, an autonomous processor running proprietary software the system has no access to. This particular device isn’t usable day to day, as I said from the outset. For real-world use, the serious answer is the one the reel puts in a hashtag: GrapheneOS.

What this post does demonstrate is more modest, and enough: the capability exists, it’s within one evening’s reach, and it gets exercised. A capability never exercised eventually disappears without anyone noticing — not by prohibition, simply because one day no device offers it any more and nobody will have asked for it.

What about your phone?

That was the first question I was asked, and it’s the right one. Here’s what answers it — the figures come from the pmaports repository as of 5 September 2026 and from Ubuntu Touch’s own site, not from a list copied off somewhere.

First, a warning about vocabulary. postmarketOS sorts its devices into three tiers, and they mean something:

• community — broadly works, with identified gaps. 39 devices, of which only fourteen are phones.
• testing — anything from “it boots, in some sense” to “almost everything works”. 149 devices. That’s where most of the world’s handsets sit, and where the work is.
• downstream — original Android kernel, very limited functionality. 20 devices, not recommended.

No device currently sits above community. That’s an honest measure of where the ecosystem stands.

The fourteen phones in community

Two surprises there. The Xiaomi Poco F1 and the OnePlus 6 / 6T are excellent candidates: powerful for their age, very common second-hand, and ported for years. And the original PinePhone, designed for Linux, sits in testing — it’s the Pro successor that made community.

The rest of the tier isn’t phones: a dozen ARM Chromebooks, the Lenovo ThinkPad X13s, the PineNote, the Odroid XU4, the RockPro64. If you’re after a small ARM Linux computer rather than a phone, that’s a badly underrated route.

In testing, the 149 devices break down mostly across Samsung (30), Xiaomi (18), Sony, OnePlus, LG and Google (5 each), and Fairphone (4). So there’s a good chance your phone is in there — with work left to do on it, which is precisely the point.

If you want a phone that works, not a test bench

That’s a different need, with different answers. Ubuntu Touch lists 111 supported devices, with a per-device functionality score. The best served:

The Fairphone 4 is the balance point in all this: it’s in postmarketOS community and at 97.3% on Ubuntu Touch, and it’s the most repairable phone on the market besides. If someone asked me what to buy to do this seriously, that would be it — or the Fairphone 5 if the goal is mainly to use the thing.

And if you want to stay on Android while getting out from under Google, GrapheneOS remains the soundest answer — but only on Pixel 6 and later, with seven years of guaranteed updates on the Pixel 8, 9 and 10. The Motorola partnership announced in August 2026 should end that exclusivity in 2027; the official device list, today, is still Pixel-only.

How to check for yours

Look up your device’s codename — not its marketing name — on the postmarketOS wiki and on devices.ubuntu-touch.io. The codename takes one command, with the device plugged in over USB:

adb shell getprop ro.product.device

On mine it answers sargo. And two preconditions apply to everyone, whatever the list says: the bootloader must be unlockable, which rules out most devices sold by US carriers; and the operation wipes everything.

What I take away

The technical part is almost incidental. Three things stay with me.

The trap is nowhere. USB autosuspend is mentioned in no installation guide. Someone who hits it sees a command hang without a message, tries another cable, another port, and concludes their hardware is at fault. They give up. The fix is two lines and applies to every Pixel. That’s what I’ll write first — before any code, before the camera. One evening lost by me can spare a great many others, and it’s probably the highest-yield contribution in the whole story.

I looked in the wrong place for an hour. Not for lack of method, but because I kept questioning the device — retry the command, change a parameter, try again — instead of questioning the system driving the device. The answer was in a nine-character text file. Whenever a tool goes silent instead of failing, stop relaunching it and go read the state of the layer beneath.

And then there’s the substance. This phone has a crossed-out wheelie bin moulded into its back, the pictogram meaning don’t throw it out with the rubbish. The symbol has been there since 2019, mandatory, decorative. Tonight it became accurate: the device didn’t go to the skip, it runs, and it runs a newer kernel than plenty of machines still in service.

This isn’t a technical feat — far more capable people did the hard work of porting a modern kernel to this chip. All I did was follow their tracks and walk into a trap they hadn’t documented. But it is a demonstration: end of support is not a property of the hardware. It’s a decision. And when the manufacturer leaves the door open — as Google does on Pixels, to its credit — that decision can be taken up by someone else.

A second-hand Pixel 3a goes for a few tens of euros. There are millions of them in drawers.

Next up: the camera.

The bench on day three. Everything that served as a judge: the caliper, an old inch micrometer, the 20 mm cube, the first-layer frames, the thickness squares numbered in marker, and behind, the seven-pillar part of the extended calibration.

An “always a bit disappointing” machine

I have an FLSun QQ-S delta printer, bought in January 2020. A delta is that triangular-tower printer where the nozzle hangs from three articulated arms that ride up and down three columns; there are no separate X, Y and Z axes as on a Cartesian printer — the nozzle position is the result of a calculation from the height of the three carriages. It is fast, quiet, elegant, and far more sensitive to geometry errors than a straight-axis machine: an arm one millimetre too long or a column one degree off does not give a simple error but a bowl, a dome or a three-lobed clover that varies across the whole bed.

Rarely used, this machine had always been a bit disappointing. Not catastrophic: parts came out. But the walls lacked strength, dimensions were off by a few tenths, the first layer never stuck everywhere, and above all no setting had a clear effect. I had ended up printing with a bigger nozzle “so it would go faster”, replaced the belts after destroying a set by over-tensioning, and parked the machine next to a Bambu Lab that simply prints right without being asked.

That comparison is what launched the investigation. Not “how do I tune my slicer”, but what exactly does this machine have, and what can be recovered. This post tells three days, 4 to 6 September 2026, carried out with an AI (Claude) that drives the printer, writes the tools and reads the manuals, while I hold the caliper, the sheet of paper and the camera. It also tells a fine methodological mistake, hers and mine, because that is what happens when you search for real.

The setup

The original firmware was going to be replaced by Klipper. Klipper is a 3D printer firmware in two parts: a tiny program on the printer’s board that only drives motors and heaters in real time, and a host program on a computer next to it that does everything else — kinematics, calibrations, macros. You lose the printer’s touch screen (Klipper cannot drive it), you gain calibration tools that exist nowhere else, especially for deltas.

What Klipper brings, concretely, compared with the original Repetier — or a Marlin:

• Offloaded computation. A classic firmware does all the delta kinematics on the board’s small microcontroller, with the approximations that imposes; Klipper does it on the host computer, in floating point, and only sends the board precomputed step times. On a delta, where every move is a square root per column, that shows in movement precision and achievable speed.
• Calibration tools: DELTA_CALIBRATE, which derives the full geometry from seven points, with or without a probe; the extended arm calibration; the bed mesh; and TUNING_TOWER, which varies a parameter with height during a print, to settle in one part what would take ten tries.
• Pressure advance and input shaper, compensation for the pressure in the bowden and for vibrations, which the original firmware lacks and which account for most of the quality gap with a modern machine.
• A plain-text configuration, readable, commentable, versionable, where every value has a provenance; and a local socket through which everything can be driven from a script.

What it does not bring: it does not raise the hotend’s flow ceiling, it does not replace wrong mechanics, and it needs a computer next to the printer.

The host, for now, is my laptop plugged in over USB; a Raspberry Pi will take over. No web interface yet: Klipper exposes a local socket you send commands to, and the AI wrote in an hour what was needed to avoid typing G-code by hand: a client to send a command and read the answer, a print-monitoring script, and above all calib.py, a keyboard driver where one key is one gesture — h to home, s to start the delta calibration, m for the bed grid, d/u to lower or raise the nozzle by 0.1 mm, [/] to adjust the first layer while it prints.

The stance from the start is the same as on the Bambu: we measure, we don’t guess. Every value written into the configuration comes from a measurement on the machine, and every correction is followed by a control part.

Mechanics first: the belts

Before touching the firmware, a quick audit of what moves. The belts on this machine have a history: a first set destroyed by over-tensioning (“I had read you should never tension them, and that’s what happened to me”), back when “no setting had any effect”. That sentence, in hindsight, was the signature of a mechanical problem and not a slicer one, and it is what justifies starting there.

The AI first proposed the method you read everywhere: pluck the belt, measure the note with a guitar app, aim for a frequency. Three rounds later, I cut it short: “it’s not a string, if I tension it enough to ring it’ll break everything”. She checked, and I was right: on this machine the free span is 65 cm, the target frequency would be under 30 Hz, where apps drop an octave (I was reading 70 Hz without ever landing on the same value twice). Above all, a Hackaday article reminds us that print quality barely changes with frankly loose belts, as long as the axis does not lag the motor; whereas over-tensioning breaks motor shafts (a NEMA 17 takes 28 N of radial load). There is no trade-off to find: no benefit to tightening, a risk to tightening.

The method kept is the one I have used for years: slacken frankly, then re-tension just to the threshold where the belt starts to vibrate softly instead of flapping. You approach from below, so over-tensioning is impossible; the threshold is exactly the lower limit of no-play; the same gesture on the three columns equalises by construction. The six pulleys spun freely. Audit closed. We will see later that this re-tensioning, done at the wrong moment, still cost dearly.

What the machine had inside

Before flashing, the original firmware’s memory had to be read: the values it used are the starting point of the Klipper configuration, and once flashed, they can no longer be read. First surprise, plugging in the USB: it is not Marlin. Everything you read about the QQ-S assumes Marlin, and the AI had prepared the Marlin commands (M503 to read the configuration, M665/M666 for the delta geometry). The machine’s answer: Unknown command. The firmware announces itself as FIRMWARE_NAME:Robin and it is Repetier, which dumps its memory with M205. First lesson, not the last: verify before asserting.

The dump — 970 m of filament and 233 machine hours — delivered two things.

First the real values: arms 278.6 mm (the reference Klipper config says 280), delta radius 140.8 (the reference says 130 — ten millimetres apart, enough for a monstrous dome had we taken the reference), height 376.03, 100 steps/mm on the columns and 367 steps/mm on the extruder (remember that figure).

Then an observation that already explained a lot: every per-column correction term was at zero. Delta radius A/B/C, diagonal correction A/B/C, all zero. This machine had never been finely calibrated as a delta — or had been at the factory and lost it in a firmware update, which resets the EEPROM: that is my hypothesis, and the EEPROM keeps no history to settle it. Either way, its geometry errors, whatever they were, had been intact for years, and the extruder steps probably came from the same reset.

Klipper, and motors with no strength left

The flash itself is uneventful: Klipper compiled for the STM32F103 of the MKS Robin Mini board, with a 28 KB bootloader, an 8 MHz crystal and the USART3 serial port; the binary passed through Klipper’s small update_mks_robin.py script that scrambles it into the format the MKS bootloader expects; copied to a 4 GB SD card in FAT32, printer off when inserting. A beep, “complete” in green, and Klipper answers Klipper state: Ready.

And then the first homing failed. No trigger on stepper_b after full movement: a carriage did not reach its switch. The second homing too, on another column. The motors growled, climbed at 5 mm/s, stalled at 25, and came back down “limply”.

What followed is a lesson rather than a story. The AI ran through hypotheses — step pulse duration, microstepping mode, belts, a current potentiometer that does not exist on this board —, each tested, each dismissed, and each test made the conversation longer without adding information. It is a behaviour worth knowing when working with an AI: the more its context window fills with failed attempts, the more it slides towards the next attempt instead of returning to the facts. What stopped it fits in one sentence, a hard constraint: “before the flash, everything worked perfectly”. The day before, under Repetier, the same mechanics worked; the hardware was out of the question by construction, and the only valid question became: what did the old firmware do that the new one does not?

She then did what she should have done first: read this board’s pin file in the Marlin sources, pins_MKS_ROBIN_MINI.h, and look for everything the old firmware initialised at boot. And there:

MOTOR_CURRENT_PWM_XY_PIN  PA6
MOTOR_CURRENT_PWM_Z_PIN   PA7
MOTOR_CURRENT_PWM_E_PIN   PB0
MOTOR_CURRENT_PWM_RANGE   1500
DEFAULT_PWM_MOTOR_CURRENT { 800, 800, 800 }

On the Robin Mini, the reference voltage that sets the motor current is not set by a potentiometer: it is generated by the microcontroller, as a PWM signal on three pins. Repetier set them at boot. Klipper left them floating — near-zero reference, tiny torque, drift over the minutes (“it moves better than at the start”). And the official Klipper configuration for this printer, printer-flsun-qqs-2020.cfg, does not contain these lines (as I write). Anyone following that config on a Robin Mini has under-powered motors.

The fix is three configuration blocks: one hardware PWM output per pin, 800 on a scale of 1500, at 1 kHz, Marlin’s default value. Immediate homing, three columns triggered, normal speed. “Perfect movement!“

[output_pin motor_current_ab]
pin: PA6
pwm: True
hardware_pwm: True
cycle_time: 0.001
scale: 1500
value: 800

[output_pin motor_current_c]
pin: PA7
# same

[output_pin motor_current_e]
pin: PB0
# same

Calibrating a delta without a probe

The machine’s probe was not around. That does not matter: Klipper’s documentation recommends manual calibration on a delta anyway, because a probe mounted beside the nozzle introduces its own error when the effector tilts. The method is the sheet of paper: DELTA_CALIBRATE METHOD=manual sends the nozzle 2 mm above seven points of the bed, one in the centre and six in a circle; at each point you lower the nozzle in 1 mm steps, then 0.1, then by bisection, until a 0.1 mm sheet of paper just drags between nozzle and glass; you accept, the nozzle goes to the next point. Seven points, a quarter of an hour. Klipper then computes the parameters that put those seven points in a plane.

The calibrate_size.stl part shipped with Klipper, for the extended calibration of the arms. It will be printed but not used: we will see why.

The first result, on the afternoon of 4 September: delta radius 141.18 (the EEPROM said 140.8), and above all column A at 211.02° and column B at 330.45°, instead of the nominal 210° and 330°. One degree on A. That is huge for a delta, and it was the defect “no setting corrected”: a wrong column angle twists parts and warps the bed into a clover, and no slicer setting, no bed grid, catches up with that.

Right after, the bed mesh: BED_MESH_CALIBRATE METHOD=manual, same paper gesture on 13 points, to correct what the glass has that isn’t flat. Range 0.51 mm, dominated by the two edges of the Y axis. Saved, loaded at the start of every print. Cold calibration done.

Note this detail: the grid was measured cold, and I re-tensioned the belts between the delta calibration and its verification. We will come back to it.

The extruder was lying by 11.5%

The simplest test in the world, and I had never done it in six years: a marker line on the filament 120 mm from the extruder inlet, ask the machine to feed 100, measure what is left. Expected: 20 mm. Measured: 31.5 mm. The machine had pushed 88.5 mm for 100 requested.

The EEPROM’s 367 steps/mm, faithfully carried into Klipper (rotation_distance 8.719), were wrong by 11.5%. Corrected to 7.716, cross-checked on a second test: 20.0 mm left, “perfect!”.

Measure what that means: every layer this machine ever laid down was missing a tenth of its material. Weak walls, open seams, uneven tops, poor layer adhesion — everything I blamed on “the delta” or “the PETG”. And no slicer setting compensates for an error you don’t know about: you can push flow to 110% at random, you don’t know why, and it doesn’t hold from one filament to the next.

With the column angles and the motor current, that makes three factory defects — from the factory or from a firmware update that reset everything, the machine will not say which — never seen.

PID, wet PETG and the first print

The temperature controls (PID) recalibrate in ten minutes, but the nozzle’s tripped Klipper’s thermal protection: heater extruder not heating at expected rate. The curve showed a perfectly healthy heat-up (27 → 234 °C in 95 s), then an unusual inertia between the block and its thermistor that makes the protection believe heating has stopped. No disabling: a widened window in [verify_heater extruder], documented in the config.

Then the first part, in PETG, the one that had been living on the machine for ages. The cube came out… like this:

The first cube, in PETG. It crackled in the nozzle while printing: the spool was saturated with water. The walls are foam.

That is not the printer: it is the filament. PETG is hygroscopic, and a spool left in the open for years crackles in the nozzle (the water flashes to steam) and comes out foamy. A good part of this machine’s “disappointing reliability” was that. A new spool of PLA for the whole calibration; the PETG will go through the filament dryer.

In PLA, Klipper’s square.stl (a frame with a one-millimetre wall, five millimetres high, six minutes): wall 1.00 mm, height 5.00. And the first control cube: Z 20.00 · X 20.40 · Y 20.45. The height is perfect — the columns are good. The 2% excess in XY, we will settle at the end.

square.stl: Klipper’s first-layer and flow test. Wall 1.00 mm, spot on.

The foot of a frame, very close: the small lip overflowing at the base says the first layer is a little too squished. This is the test used to set the first-layer offset, in 0.05 mm steps, while printing.

Pressure advance

Last setting before tackling the bed: pressure advance. On a bowden machine (the extruder motor is on the frame, a long tube brings the filament to the nozzle), the pressure in the tube takes time to rise and fall; without compensation, corners bulge and line ends ooze. Klipper compensates by pushing a little more before accelerations and pulling back before decelerations, with a single parameter. You measure it with a test tower where the parameter grows with height (TUNING_TOWER), and look by eye for the height where corners are sharpest.

The square_tower.stl tower: at the bottom, not enough compensation, corners bulge; at the top, too much, they hollow. The best corner is at 19 mm.

Best corner at 19 mm, 0.020 per millimetre: pressure advance 0.38, in the expected range for a bowden. Saved.

The spiral, or how to see your first layer

To judge levelling, I needed better than the sheet of paper: I remembered a spiral object you print to see the first layer at a glance. Rather than look for a file sliced for another machine, the AI generated the G-code directly: a single continuous line, an Archimedean spiral, from the centre out to a 120 mm radius, one turn every 2.5 mm, a single 0.2 layer. Twelve minutes. Where the nozzle is too close, the bead is squashed, flat, translucent; where it is too far, it is round, narrow, poorly stuck. On a round bed, it is the most readable test there is.

The first spiral. Three bright lobes 120° apart: the signature of a delta geometry, not of a warped bed.

The first spiral showed a three-lobed clover. A warped glass does not make a clover; a badly calibrated delta does. And yet the calibration had just been done. The right conclusion would have been: the geometry isn’t right yet, redo the calibration. We took the other path.

The false trail: two days correcting the grid

My request was reasonable: “a print with a predetermined thickness would be more relevant than the paper test”. The AI built the method: print a one-layer square on each of the 13 grid points, measure their thickness, and correct each grid point by its deviation from the mean. A square thicker than the others = the nozzle was higher there = the bed is lower there than the grid believes = lower the point. She wrote the script (fix-mesh.py) that homes, places the nozzle 100 mm above each square to identify it (“how do I tell which is which?” — the logo is not a reference), records the measurements, rewrites the grid. My micrometer being graduated in inches, you enter thousandths (13t).

Pass 1: thirteen 20 mm squares, one layer, one per grid point.

The micrometer, graduated in inches: one sleeve mark is 25 thousandths, the thimble gives the units. 13 thou = 0.33 mm.

The instrument itself: a Lufkin Rule Co. from Saginaw, Michigan, No. 1941. Older than me, and still measuring to a thousandth of an inch. Between its anvils, one layer of PLA.

It worked. Pass 1: thickness range 0.30 mm. Pass 2: 0.084 mm. The next spiral was clearly better, the clover fading. Then we moved to a finer grid, 7×7 (29 points, 40 mm pitch instead of 55), because the remaining defects seemed to fall between the points. Pass 3, pass 4, reduced gain to avoid oscillating. And on every spiral, the same zones came back, attenuated but in the same place.

Spiral 3, annotated by me: red = too close (scraped), blue = too far (not stuck). Five patches, no clear clover any more.

Spiral 4, after the 7×7 grid: two red zones instead of five, the blue still at the same corner.

7×7 grid, 29 squares of 10 mm. Two squares on the left are torn: too close. The micrometer, though, measured them “thick”.

That is when I said what had to be said: “to me the error is very repeatable on the last three spirals. We have gaps in the same zones and the corrections have improved things but they don’t really fix the root of the problem.” Three correction passes should have been enough. Something independent of the setting was resisting.

Spiral 5: red, almost no filament; pink, slight lack; blue, not stuck. The same zones, again.

Two macro shots settled it. In the blue zone, the bead is round, narrow, laid down without being pressed, and the transition is gradual over 25 mm towards the edge: the nozzle moves away steadily going outwards. In the red zone, the beads are wide, flat, translucent, squashed to a film — you can see the bed’s dots through them. Too close, really.

Blue zone: round bead, not pressed, wavy and knotted where it caught. Too far.

Red zone: squashed, translucent beads, the bed shows through. Too close, no argument.

And here is the contradiction: in those red zones, the squares measured a normal thickness. The explanation, once you see it: a square printed too close grows a raised lip around its edge, and the micrometer’s anvils, six millimetres across, land on that lip. It reads “thick” exactly where it is squashed. The squares method was biased in precisely the direction that prevented convergence. Two of the AI’s conclusions built on those measurements (“the nozzle is 0.4 mm from the glass on average”, “the global zero must come down”) fell with it.

The root question remained: why such repeatable zones? My lead was the belts. The AI wrote a repeatability test (key R: same point, five approaches along different paths, sheet of paper): repeatable to 0.1 mm whatever the path. Belts and play out of the question. But that test gave something else: at those points, the paper dragged at Z = +0.2 and +0.6 mm — the machine believed the bed was half a millimetre lower than it is. And the grid itself carried a 0.65 mm front-to-back slope that nothing justifies on a calibrated delta.

The cause was in day one’s sequence. The delta calibration had been done cold; between that calibration and its verification, I had re-tensioned the belts; the verification had shown an offset, and the AI had applied +0.4 mm uniformly to the three endstops. But the re-tensioning had shifted the three columns unequally. The residue, a tilted slope, went into the grid, and a delta grid never makes a slope flat: it leaves lobes, which four passes of micrometer squares chased without catching.

The arrival: redo everything hot, with paper

Bed at 60 °C, nozzle cold, grid cleared. Manual DELTA_CALIBRATE, seven points with paper, fifteen minutes. The verdict is in the endstops:

The angles barely moved (A 211.02 → 210.93, B 330.45 → 330.33), the radius neither (141.18 → 141.29). The geometry held. What was wrong were the endstops, unequally: 0.38 mm between A and B. Exactly the slope the grid carried.

Save, home, then the paper grid on the 29 points, half an hour. Centre flat to ±0.1 mm over an 80 mm radius; the front edge dips 0.6 mm at 120 mm from the centre — that is the glass itself, or the delta at the end of its reach, and this time it is measured directly and the grid knows it. Then the spiral:

Spiral 6, the first with a consistent geometry and grid, both measured hot. Uniform from edge to edge, front edge included.

The bead, under the loupe: regular, same width from turn to turn, stuck everywhere.

Six spirals, and the good one was the one where we stopped correcting and recalibrated, in thirty-five minutes, with a single method.

One last trap remained, from the same family: the first-layer offset, +0.07 mm, had been set on day one on the cold zero. On the new, hot zero, the control cube did not stick. A new zero means re-setting the first-layer offset, never carrying the old one over. Test frame, live adjustment in 0.05 steps: −0.10 barely sticks, −0.20 sticks with a 0.3 mm lip at the foot; saved at −0.15.

The control cube restarted with the old first-layer offset: it did not stick. The zero had changed, the offset had not.

And the cube, at last: 20.3 × 20.4 × 20.00, a 0.1 mm lip per side. On day one it was 20.40 × 20.45 × 20.00. The XY excess did not move with the geometry, because it is not geometry: the seven-pillar part, measured with the caliper, gave a pillar spacing of 65.0 ± 0.4 mm on a nominal 65, i.e. a scale correct to 0.5%; an arm error would have given +1.3 mm there. What remains is a constant excess of bead width — bulging corners, a 1.07 wall for 1.00 — and that is settled in slicing as on any machine: extrusion multiplier 0.95, XY compensation −0.1 mm, elephant-foot compensation 0.1 mm, in a production profile separate from the raw test profile. The long, delicate extended arm calibration was not necessary. Control cube with that profile: 20.0 × 20.1 × 20.0.

What I take away

Calibrate in the state you print in. Hot. A machine calibrated cold describes a bed that no longer exists when the PLA arrives.

One measurement method, from start to finish. Paper for the geometry, paper for the grid, the test frame for the first layer. Every change of method introduced a bias nobody saw.

Geometry first, grid second, never the reverse. A grid that fails to converge in two passes is not short of points: it is compensating an error that is not its own. And any belt re-tensioning puts the geometry back in play — redo s then m, no shortcut.

When two measurements disagree, go and look. The loupe on the bead settled in one minute what four micrometer passes had not. A measurement is not a truth, it is an instrument with blind spots.

The AI over-engineers when it misunderstands. The grid-correction script with micrometer squares was clever, well made, persistent, with resume and corrections — and it was optimising a bad idea. I am the one who said “it’s repeatable, it’s not the setting”, and the macro shot is what settled it. On the other hand, she found in one reading what six years of forums had not: the PWM motor current, the extruder off by 11.5%, the calibration never done.

“It worked before” is data. Twice in this story, my judgement about my machine was worth more than a method read elsewhere: on belt tension, on homing. And twice, the AI ended up verifying it and proving me right, with sources. That is the right split: she reads fast, she does not measure in my place.

Where things stand

To reproduce

Hardware: a 2020 FLSun QQ-S (MKS Robin Mini board) — the approach applies to any delta, the pins do not; a Linux computer with a USB port; an SD card ≤ 8 GB in FAT32; a sheet of 80 g paper; a caliper; a dry spool of PLA. No probe, no accelerometer.

Before flashing, read the original firmware’s memory (on Repetier: M205; on Marlin: M503) and keep the dump. Note in particular the arm length, the delta radius, the height, and the extruder’s steps/mm.

Firmware: Klipper, make menuconfig → STM32F103, 28 KiB bootloader, 8 MHz crystal, USART3 (PB11/PB10), 250000 baud; then scripts/update_mks_robin.py out/klipper.bin Robin_mini.bin; the file at the root of the SD card, printer off when inserting, power on, wait for “complete”. The bootloader renames the file to .CUR. The build-firmware.sh script does all of it.

Configuration: printer.cfg, with its real values and comments. The three [output_pin motor_current_*] blocks are indispensable on a Robin Mini. The SAVE_CONFIG block at the end of the file holds the calibration results; to start from scratch, delete it and put the EEPROM values back into [stepper_a/b/c] and [printer].

Tools: start-klipper.sh (start the host), send-gcode.sh and klippy-client.py (send a command), calib.py (keyboard driver for calibrations), watch-print.py (print monitoring), make-spiral.py (the spiral). The command-line PrusaSlicer profiles are in slicer/: qqs-pla.ini raw for tests, qqs-pla-prod.ini for parts.

In order, hot (bed at printing temperature, nozzle cold for the paper):

Three rules, if you go for it: hot, a single measurement method, and any mechanical intervention (belts, arms, bed) sends you back to step 2. If a grid does not converge in two passes, do not add points: redo the geometry.

Reading the spiral: red = too close (flat, translucent, scraped bead), blue = too far (round, poorly stuck bead). A three-lobed clover = geometry; local patches = bed or grid; an edge dipping gradually = the glass or the delta at the end of its reach. When in doubt, the loupe.

Frequently asked questions

Do you need a probe to calibrate a delta under Klipper?

No. Klipper’s documentation recommends manual paper calibration on deltas, because a probe offset from the nozzle introduces its own error when the effector tilts. Seven points for the geometry, thirteen to twenty-nine for the grid, half an hour in all.

My motors growl and homing fails after switching to Klipper on an MKS Robin Mini. Why?

Because the motor current is set by PWM from the microcontroller (pins PA6, PA7, PB0) and the official Klipper config for the QQ-S does not do it. Three [output_pin] blocks in hardware PWM, value 800 out of 1500, fix the problem. See Klipper, and motors with no strength left.

Is my FLSun QQ-S running Marlin?

Not the 2020 QQ-S: it runs Repetier (FIRMWARE_NAME:Robin). M503, M665, M666, M900 answer Unknown command; M205 reads the memory. Marlin tutorials do not apply.

My bed grid does not converge, even after several passes. Do I need more points?

Almost never. A grid that does not converge is usually compensating a geometry error (unequal endstops, column angle) or a calibration done cold. Redo DELTA_CALIBRATE hot, then the grid, with the same measurement method.

How do I know whether my extruder pushes the right amount?

A mark on the filament 120 mm from the extruder inlet, M83 then G1 E100 F60, measure what is left: 20 mm expected. Here 31.5 were left: 11.5% under-extrusion since forever. New rotation_distance = old × extruded / 100.

Is the micrometer thickness-squares method any good?

It is biased where the nozzle is too close: the squashed square grows a raised lip around its edge, and the micrometer reads it “thick”. If you insist, 20 mm squares measured at the centre, anvils away from the edge. The spiral and the paper are more reliable.

Should a delta’s belts be tensioned to a precise frequency?

No. The frequency depends on the span length, the mass and the composition of the belt; the same note does not mean the same tension from one machine to another, and on a QQ-S the span is too long to measure. Slacken, then re-tension to the threshold where the belt vibrates softly instead of flapping, on the three columns. And redo the delta calibration afterwards.

The cube is 20.3 instead of 20.00 in XY: should I calibrate the arms?

Not if the excess is constant. Check on a larger part (Klipper’s seven-pillar part, 65 mm spacing): if the scale is right, the excess comes from bead width and is corrected in the slicer (extrusion multiplier, XY compensation). Arm calibration corrects a scale error, not a constant excess.

What did the AI do exactly, and what did the human do?

Claude read the EEPROM and the board’s pin file, compiled and prepared the firmware, wrote the configuration and all the scripts, generated the spiral, ran the calibrations and wrote this post with me. She was wrong about the firmware (Marlin), about the cause of the homing failure (several hours), about belt tension, and about the squares method. I held the sheet of paper, the caliper, the micrometer and the camera; I read the spirals; I said “it worked before”, “it’s not a string” and “it’s repeatable, it’s not the setting”. All three times, that was the right lead.

Short glossary

• Delta: a printer where the nozzle is carried by three articulated arms on three vertical carriages; the position is computed, not measured axis by axis.
• Effector: the central part carrying the nozzle, at the end of the arms.
• Arms (arm_length), delta radius (delta_radius), column angle, endstop (position_endstop): the geometry parameters; see the box “what each setting corrects”.
• Homing: sending the carriages up to their switches, to know their position.
• Bed mesh: a map of bed heights, measured at a few points, that the firmware interpolates to correct the nozzle continuously.
• Paper test: lowering the nozzle until a 0.1 mm sheet just drags; Z = 0 is then 0.1 mm above the glass.
• First-layer offset: a small Z shift applied at the start of each print to adjust how much the first layer is squished.
• Rotation distance: under Klipper, the distance travelled (or filament pushed) per motor turn; replaces steps/mm.
• Pressure advance: compensation for pressure in the bowden tube, which cleans up corners.
• PID: the temperature control; recalibrated with PID_CALIBRATE.
• Bowden: a layout where the extruder motor is on the frame and pushes the filament through a long tube to the nozzle; light for the effector, but elastic.
• Thou: a thousandth of an inch, 0.0254 mm. Old micrometers are graduated that way.
• Lip / elephant foot: a bulge at the base of a part, sign of an over-squished first layer.
• PWM: a square wave whose width is modulated; used here to manufacture a reference voltage for the motor current.
• EEPROM: the original firmware’s memory where it keeps its settings.

References and local copies

So that this post stays useful once links have vanished, the project files are hosted here.

• Klipper documentation: Delta Calibrate · Bed Mesh · Bed Level · Manual Level · Pressure Advance · Resonance Compensation · Config Reference. The test parts (square.stl, square_tower.stl, calibrate_size.stl, ringing_tower.stl) are in the repository’s docs/prints/.
• Reference Klipper config for the QQ-S 2020 — printer-flsun-qqs-2020.cfg (without the motor current outputs, as of 6 September 2026).
• MKS Robin Mini pinout in Marlin — pins_MKS_ROBIN_MINI.h (source of the PWM current pins).
• Hackaday, “Don’t Tune Your 3D Printer To Middle ‘C’ After All” — on belt tension by frequency (site search).
• PrusaSlicer 2.8.1, the last version with a Linux AppImage — releases. Run from the command line without a display (env -u DISPLAY); it adds its own heating commands unless it finds real M104/M140 in the start G-code.
• The project files: printer.cfg · calib.py · klippy-client.py · send-gcode.sh · start-klipper.sh · watch-print.py · build-firmware.sh · make-spiral.py · slicer/ profiles · README-flsun.md (the machine’s state and the repository’s user guide, in French).
• For the record, the false trail: fix-mesh.py, mesh-to-7.py, first_layer_29.stl, and analyze-delta.py for the extended arm calibration, should it ever become necessary.

Photos and measurements: mine. Firmware, configuration, scripts and writing: with Claude. This post is also available as raw Markdown.

The pack’s board, once the sleeve is opened. The two small pads marked “DA” and “CL”, on the right, are all we need. The big ones in the center, C+ and C−, are the ones we don’t touch.

A cloud switched off, then a button that dies

My robot vacuum is a Neato D800. A good robot: a spinning LIDAR (a small laser radar that rotates on top and measures the distance to the walls), a map of the house, no-go lines you draw in the app, €600 at the time. In 2023, Neato Robotics shut down. Vorwerk, the parent company, kept the servers running for a while — the “cloud”, meaning the remote computers without which the app, the maps and the scheduling don’t work — then announced on October 6, 2025 (local copy) that this cloud was going dark. “Your Neato robot will continue to function manually. Simply press the button once to launch a full house run.” A €600 robot demoted to a one-button vacuum, by press release.

And then, a few months later, the button itself stopped responding. Red light, error 4202, “battery discharged”. The app, in its dying breaths, specified that the battery’s charge counter had been exceeded and that it needed replacing. Original battery: €90, when you can find one. Compatible: €30 to €50, with the well-documented risk on the forums that the robot rejects it.

This post tells how we went from “dead robot, dead battery” to a battery that explains by itself what’s wrong — without buying anything, with three wires and a microcontroller that costs the price of a coffee. It also tells of a false hope, because that’s what happens when you investigate for real. It pauses on what this investigation would have cost me three years ago, before an AI could read a 250-page manual on my behalf, and on the remarkable little chip that manages this battery. And it explains why this story leaves me with a bitter taste about the way we build objects.

First reflex: the cells

A robot battery is a housing containing several cells — lithium accumulators in the 18650 format (18 mm in diameter, 65 mm long, the look of an oversized AA) — wired in series and managed by a small circuit board. A “discharged” battery that won’t recharge is classically a case of dead cells. So I did what every tinkerer does: opened the pack, desoldered the four cells, soldered in four salvaged cells in their place — mismatched, which will matter later —, closed it back up.

Result: still error 4202.

Multimeter in hand (the instrument that measures voltage, i.e. electrical “pressure”, in volts), though, everything was perfect. 4.1 V on every cell, which is a full lithium cell; 16.4 V across the pack; 16.4 V at the output connector, meaning the protection circuit — the electronic switch that can isolate the cells in case of danger — was letting current through. The thermistor (a resistor whose value changes with temperature, which the robot reads to monitor the battery) showed 6 kΩ, a normal value for a warm room. The robot was holding a battery charged to 95% and in good health, and it was displaying “battery discharged”.

That’s the moment you understand the problem isn’t the battery. It’s what the battery says about itself.

The battery has a brain

The packs in the latest-generation Neatos (D8, D9, D10, D800) are “smart batteries”: next to the cells, the small board carries a fuel gauge, a chip — an integrated circuit, a tiny sliver of silicon holding a specialized computer — from Texas Instruments, the bq40z50-R2. It’s the gauge that measures the current, adds up what goes in and what goes out, derives the state of charge from that, cuts out in case of overvoltage or overheating — and it’s the gauge that talks to the robot, over a serial bus: two wires carrying digital messages, one wire for the data and one for the clock that paces the conversation. The protocol (the language spoken on those wires) is called SMBus, an industrial cousin of the I²C that every Arduino tinkerer knows. An extra blue wire in the pack’s connector carries this conversation up to the robot.

The robot doesn’t measure the battery’s voltage. It asks the gauge: “how charged are you?”, “what charging current do you want?”, “what voltage?”, “how many cycles have you done?”. And it obeys whatever the gauge answers. If the gauge says “0%” or “don’t charge me”, the robot displays “battery discharged”, whatever the electrical reality three centimeters away.

This architecture isn’t absurd: a gauge inside the pack knows the cells’ history, handles their balancing (keeping all four cells at the same level of charge, failing which the weakest wears out first), and protects effectively against thermal runaway (the chain reaction that sets a mistreated lithium cell on fire). But it has a consequence: replacing the cells does not reset the gauge. The cycle counter, the learned capacity, the error flags (yes/no boxes the chip ticks when it detects a problem) — all of that lives in the chip’s memory, not in the cells. You replace the heart, the brain keeps its memories.

On the forums, the trail usually ends there. The chips in the D3–D7 packs are from an obscure manufacturer and locked; for the bq40z50 “you need an EV2400 and bqStudio” — Texas Instruments’ official adapter, €150, and its Windows software — and nobody really knows which data the robot checks. End of story, buy a battery.

Three wires and a two-euro ESP32

Except that the bq40z50 is a publicly documented chip. Texas Instruments publishes its Technical Reference Manual — the reference manual, 250 pages describing every register, every command, every memory address (local copy of the PDF, 1.6 MB). And SMBus, any microcontroller — a complete computer on a chip, a few euros, the kind found on an Arduino board — can speak as soon as it has two I²C pins.

I have a drawer full of ESP32-C3 “Super Mini” boards: a board the size of a postage stamp, two euros apiece, that plugs into USB and programs like an Arduino.

On the pack’s board, two test pads — contact points deliberately left by the manufacturer to hook up its end-of-line test equipment — are silkscreened DA and CL: data and clock, the two SMBus wires. One wire on DA, one on CL, one on the cells’ minus, and on the other end the GPIO 4, GPIO 5 (GPIO: a microcontroller’s numbered input/output pins) and GND (ground, the shared “zero volt”) pins of the ESP32. No component to add, no power supply to provide: the gauge is powered by its cells and the ESP32 by its USB.

On the software side, two hundred lines of Arduino, written with an AI (Claude) that read the manual on my behalf: we read the standard registers (voltage, current, state of charge, cycle count, per-cell voltages), then the internal status registers — safety status, permanent failures, state of the charge and discharge transistors —, then we copy out the flash memory. Nothing is written without an explicit order. We listen.

What the chip said

First readout, on the serial monitor:

Voltage            : 16386 mV
RSOC               : 97 %
RemainingCapacity  : 2343 mAh
FullChargeCapacity : 2437 mAh
DesignCapacity     : 2500 mAh
CycleCount         : 1547
ChargingCurrent    : 0 mA
ChargingVoltage    : 0 mV
Cellules           : 4094 / 4097 / 4100 / 4095 mV
ManufacturerName   : BLUEWAY-
DeviceName         : bq40z50-
ManufactureDate    : 2022-01-09
OperationStatus    : PRES DSG CHG SEC0  -> sécurité : FULL ACCESS
SafetyStatus       : (aucun flag)
PFStatus           : (aucun flag)

To read this: mV and mA are millivolts and milliamps (thousandths of a volt and of an amp); mAh, milliamp-hours, measure a quantity of stored energy — 2,437 mAh is enough to supply 2.4 A for one hour; RSOC is the displayed battery percentage; FullChargeCapacity is what the gauge thinks it can store today, DesignCapacity what the pack stored when new.

Three things jump out.

The gauge is in great shape. No safety fault, no permanent failure, charge and discharge transistors conducting (the transistors, or FETs, are the electronic switches through which the gauge allows or cuts charging and discharging), state of charge estimated at 97% — consistent with 4.1 V per cell. It isn’t “discharged”, and it knows it.

It isn’t even locked. The security level is FULL ACCESS: the chip’s most permissive mode, the one TI recommends leaving before shipping from the factory. No password to crack, no key to guess. The entire memory is readable and writable. The pack manufacturer delivered the house with the keys in the door.

And yet it tells the robot not to charge it. ChargingCurrent = 0 mA, ChargingVoltage = 0 mV. Those are the two registers a smart charger reads to know what to do. At zero, they mean: “don’t send any current”.

And the counter: 1,547 cycles. A cycle, for a gauge, is a cumulative discharge equivalent to one full battery — two half-discharges make one cycle. For a battery manufactured in January 2022, that’s one cycle per day for four years — plausible for a robot that runs daily. It’s also the number the app had held against me.

Seventeen thousand lines of manual, and a false hope

The question becomes: why is the gauge refusing to charge? The TI manual precisely lists the cases in which ChargingVoltage() drops to zero: charge transistor cut by a protection, temperature out of range, permanent failure, pack declared “removed”, charger overvoltage detected. We checked them all, register by register. None was active. Temperature 26 °C, temperature region “recommended”, voltage region “high”, all green.

We also explored a seductive lead: the bq40z50 has a cycle-count degradation feature, which deliberately reduces the charging voltage and current as the pack ages — planned obsolescence in the literal sense, enabled by a configuration bit. We read that bit in the flash memory. It was zero. Neato hadn’t enabled it. The charging table said 4.2 V per cell and 1.5 A across all temperature ranges. On paper, the gauge should have been announcing 16.8 V and 1,500 mA. It was announcing 0 and 0.

Before going further, we did what you must always do before touching a memory you won’t be able to buy back: a full backup. 8 KB, 256 blocks of 32 bytes (a byte is eight bits, the smallest unit of memory), read one by one and stored in a file (here it is, if yours is the same pack). If a write goes wrong, everything can be put back.

Then we tried the dumbest thing in the world. The manual documents a command 0x0041 : Reset — a chip reset: its RAM (the working memory, wiped at every restart) is rebuilt from flash, nothing is written. The equivalent of “have you tried turning it off and on again?”. One letter r sent over the serial monitor, three seconds of waiting:

>>> Envoi MAC 0x0041 Reset
ChargingCurrent    : 1500 mA
ChargingVoltage    : 16800 mV
RSOC               : 97 %
FET DSG ON, FET CHG ON, PF inactif

Victory, we thought. Pack reassembled, robot placed on its base: no more error, it charges, it announces it’s ready. I wrote a first version of this post that very evening, with a triumphant conclusion about the cycle counter the robot “had never cared about”.

The next morning, red light, error 4202.

The symptom that vanishes when you look at it

Pack hooked back up to the ESP32. ChargingCurrent : 0 mA, again. Reset: 1,500 mA. And this time, instead of crying victory, we let it run and watched the clock.

At 3 seconds: 1,500 mA. At 20 seconds: 1,500 mA. At 31 seconds: 0 mA — and in the same readout, a flag that wasn’t there ten seconds earlier: SLEEP. Two attempts, two full readouts compared line by line: between 20 and 31 seconds, the only thing that changes is that flag.

The gauge falls asleep. As soon as almost no current is flowing (less than 10 mA, a threshold set in its configuration), it goes into standby to spare its cells, and in that state it announces “charging current: 0”. The reset never fixed anything: it woke it up for thirty seconds. On the bench, with an ESP32 that draws nothing, it went right back to sleep. Inside the robot, which pulls a few hundred milliamps, it stays awake and announces 1,500 mA. The “don’t charge me” was never the problem. It was a laboratory mirage.

The next morning’s laboratory: a couch, the pack under kapton (the yellow adhesive tape that insulates and withstands heat), the ESP32 at the end of three wires, and a terminal comparing readouts ten seconds apart.

It’s a lesson I already knew and still had to relearn: when a symptom disappears at the moment you observe it, it’s probably the observation that made it disappear. You have to watch what comes back, not what goes away.

The counter

That left the original suspect, the one the app had named: 1,547 cycles. The gauge itself couldn’t care less — cycle degradation is disabled, we checked. But the robot reads that number (CycleCount, command 0x17), and an embedded piece of software (a firmware: the program burned into the robot) that displays “charge counter exceeded” necessarily has a threshold somewhere.

The counter is a plain two-byte value in flash, at address 0x4340. In Full Access, you write it the way you read it: a block command, the address, two bytes. We wrote zero.

>>> CycleCount SBS avant = 1547 ; écriture DF 0x4340 = 0
>>> relecture 0x4340 : 00 00  (OK)
>>> CycleCount SBS après écriture = 0

Immediate, no reset, no safety flag raised. A brand-new battery, in the eyes of anyone who only looks at that number.

The twist

September 1, evening: red light. Error 4202. The robot had lasted one day.

Third time the same script plays out: touch the pack, plug it back in, the robot runs again, and the next day it stops. Resetting the gauge had “worked” for an evening; zeroing the counter, for a day and a few cycles. Looked at closely, those two “victories” share one thing that isn’t the fix: each time, the pack was unplugged and plugged back in. The robot reboots, forgets its “battery discharged” state, tries again — and runs into the same cause, which we hadn’t found.

This time, before any reset, the pack went onto the ESP32 as it was. Cycle count: still 0. No active protection, no permanent failure, gauge in perfect health — the same reassuring readout as the first evening. Except we had learned to distrust reassuring readouts, and we went to read a region of the flash we had never decoded: the lifetime data (Lifetimes), the logbook the gauge keeps about itself since it left the factory — extreme voltages seen by each cell, how many times each protection has tripped, and at which cycle the last one happened.

Compared with the August 29 backup, it said this:

                              Aug 29       Sep 1
COV (cell over-voltage)       6            246   (+240 in three days)
Lifetime max V, cell 4        4213 mV      4293 mV   (COV threshold: 4225)
Valid charge terminations     21813        21813 (none since the re-celling)
Cells at rest                 —            3986 / 3986 / 3995 / 3939 mV

Two hundred and forty trips of the over-voltage protection in three days, all on cell 4 — and not a single charge run to completion. The original pack had seen six in four years.

The explanation fits in one picture. Four cells in series are four buckets filled through the same hose: if one is smaller, it overflows first. Cell 4 of my salvaged set has less capacity than the other three — at rest it sits lowest (3.94 V against 3.99), and on charge it is the first to cross 4.225 V. The gauge then does its job: it opens the charge transistor, waits for the cell to drop back to 4.1 V, closes it again, opens it a second later. Two hundred and forty times. The robot’s charger, meanwhile, sees a charge that never terminates; after a while its firmware draws the only conclusion it knows: “battery discharged”, 4202.

The cycle counter had nothing to do with it — or not everything. For the original pack we will never know: I changed two things at once. Its lifetime data, though, shows 67 under-voltage events, the last one at cycle 1547; the 41 mΩ cell sagging in the middle of a vacuuming run is at least as good an explanation as the counter. Error 4202 is a catch-all.

The new attempt. The clean solution is to run the four salvaged cells through the tester, as with the originals, and rebuild a pack from the four best-matched cells among the eight. In the meantime, the gauge allows a stopgap with no soldering iron, still through the three wires — and that is what we did the same evening:

• charging voltage lowered from 4200 to 4100 mV per cell: the pack stops at 16.4 V instead of 16.8; cell 4 stays below the over-voltage threshold, at a cost of about 10% runtime;
• reference capacity brought down to 2100 mAh (it had stayed at 2500, the new pack’s figure), the cells’ chemical capacity aligned with it;
• gauge put back into learning mode: its learned values (chemical capacity, resistance table) dated from the 2022 cells; one bit tells it to relearn everything over the next cycles.

Reset: the gauge reports 16,400 mV and 1500 mA, an estimated full-charge capacity of 1792 mAh, no fault. Pack closed up, robot on its dock. This time, no victory lap: we wait a few days, then reopen the gauge’s logbook. If the over-voltage counter still reads 246, that was it.

Where things stand

And then there’s the epilogue I hadn’t seen coming. The four original cells, the ones I had desoldered at the start because “the battery was dead”, were lying around on the bench. For good measure, I measured them: 3.6 V each. None is below the threshold where a lithium cell condemns itself. So I ran them through a capacity tester — a Liitokala Lii-500, a thirty-euro charger-analyser, in “NOR TEST” mode: it charges the cell fully, then discharges it at constant current while counting the milliamp-hours that come out, then recharges it. That’s the only honest way to know what a cell is worth: empty it with a stopwatch running.

The verdict, on cells rated 2,500 mAh when new:

The tester also gives each cell’s internal resistance — the electrical “friction” of the chemistry, in milliohms (mΩ): the higher it is, the more the voltage collapses when the robot draws current, and the more the cell heats up instead of delivering. Three cells sit between 16 and 19 mΩ, which is good for 18650s of that age. The fourth is at 41 mΩ: more than double. That’s the pack’s weak link — the one that sags first mid-vacuum, drags the others toward the cutoff threshold and therefore shortens the runtime far more than its 1,819 mAh would suggest.

But none of them is dead. After something like 1,547 cycles, these cells still deliver three quarters of their original capacity: a normal loss, the one you expect from a lithium cell reaching the end of its advertised life. In practice, the runtime would have gone from a full hour and a half to a little over an hour. A slightly less enduring vacuum — not a dead one.

That’s where the story finds its point. The pack that set all this off wasn’t faulty: it was 25% worn, and something — a counter, or more likely its 41 mΩ cell sagging mid-run — decided that was the end. The recelling I did on first reflex probably wasn’t necessary, and done with salvaged cells that were never measured, it added a problem of its own (see The twist); at least it leaves me four working original cells, measured and documented, ready to serve as spares the day the salvaged ones give out.

What it would have cost me three years ago

Let’s be honest about the step I climbed without seeing it.

Three years ago, this story would have ended at the paragraph “First reflex: the cells”. Cells replaced, error still there, multimeter unequivocal: the battery is good. And then? Then, a dead end. I would have searched the forums, found the same threads as everyone else — “you need an EV2400 and bqStudio”, “the chip is locked”, “buy a battery” — and I would have either bought, or put the robot in a closet waiting for a courage that never comes.

Because the rest of the process, which fits here in a few paragraphs, represents work I couldn’t have delivered in a tinkerer’s evenings. Let’s lay it out:

1. Identify the chip and find its manual: easy.
2. Read the manual: 250 pages, 17,000 lines of dense technical English, written for battery engineers who already know the vocabulary. It’s not about skimming it: you have to find the three tables that say when the charging current drops to zero, the flash write procedure, the map of the 400 configuration addresses, the meaning of every bit in a dozen status registers.
3. Learn SMBus at the protocol level (the block read, the block write, command 0x44 and its echo, address auto-increment) and write a program that speaks it without error.
4. Interpret a readout of forty flags and 8 KB of raw bytes, cross-referencing them with the manual.
5. Design the experiments: the reset, then — after the false hope — the idea of comparing two full readouts ten seconds apart to isolate the line that changes.
6. Write to the flash without breaking anything.

For a competent developer who isn’t a battery engineer, that’s several weeks of evenings, with a real risk of giving up at step 2 — and that’s exactly where the forum threads stop. It’s not that it’s hard in the intellectual sense; it’s that it’s long, and nothing guarantees, at the outset, that those weeks lead anywhere.

With Claude, steps 2 through 6 took two evenings and a morning. The AI absorbed the manual in a few seconds, wrote the sketch in one pass, decoded the registers as they came in, suggested the reset, then — when the reset lied — suggested doing it again while recording everything, and found the SLEEP flag in the comparison. What I kept for myself: the soldering iron, the multimeter, the photos, the decisions (“we don’t touch Qmax, we let it learn”), and above all the doubt: it’s the overnight test in the real robot that disproved the victory, not one more readout.

Two caveats, so as not to turn this into a fairy tale. First, the AI co-signed the false hope: it had the same wrong conclusion as I did the first evening, because we had the same incomplete data. It reads fast, it doesn’t measure on my behalf. Second, it found an error in the manual itself (the sleep mode that zeroes the current while the doc says otherwise) only because we measured the opposite; without the ESP32 hooked up, it would have defended the doc.

But the shift is real, and it seems important to me for repair in general: a body of knowledge that was locked inside a 250-page manual, and therefore reserved to professionals, becomes accessible to someone who can hold a soldering iron and ask a question. Manufacturers count, without saying so, on nobody reading the manual. That assumption just fell.

Focus: the bq40z50, the chip that manages your battery

Since we spent two days with it, let’s introduce it. The bq40z50-R2 is what Texas Instruments calls a battery pack manager: a single chip, the size of a fingernail (32-pin QFN package, the contacts are underneath the package), that does everything a lithium pack of 1 to 4 cells in series needs done. It’s found in a large share of laptop batteries from the past ten years, in power tools, robots, drones, medical batteries.

What it does

• Gauging: it measures the current through a sense resistor (a shunt, a few milliohms) and the voltage of each cell, and derives the state of charge with an in-house algorithm, Impedance Track: instead of merely counting what goes in and out (which drifts over time), it learns the cells’ real chemical capacity (Qmax) and their internal resistance at every cycle, and corrects continuously. That’s what gives recent laptops their precise percentages.
• Protecting: it integrates the AFE (analog front-end: the analog part that monitors voltages and currents in real time, independently of the software) and directly drives the charge and discharge transistors. Per-cell overvoltage and undervoltage, overcurrent in charge and in discharge, short circuit, overheating and undertemperature, each with its thresholds, its delays and its recovery conditions.
• Condemning itself: a second family of protections, the permanent failures (PF), cuts the pack off for good — if need be by blowing an irreversible chemical fuse — in case of an open cell, uncorrectable imbalance, a burnt transistor or too many repeated overvoltages.
• Balancing: during charging, it slightly discharges the cells that are ahead so that all of them reach full together.
• Remembering: cycle counter, extreme temperatures and voltages seen over its lifetime (lifetime data), and a black box that records the last safety events before a permanent failure — enough to perform an autopsy on a dead pack.
• Talking: SMBus, the whole SBS standard, plus the manufacturer’s commands. And authenticating: a cryptographic mechanism (SHA-1 with a secret key) lets the device verify that the pack is genuine. That’s what blocks compatible batteries on some devices.

Its strengths

• Complete and documented. Everything is in a single package, and the manual describes everything: that’s what made this investigation possible. Many competing chips are documented under NDA, or not at all.
• Precise. Impedance Track remains the benchmark in consumer gauging; the estimation error drops to 1% on a well-configured pack.
• Safe by construction. The AFE protects even if the software crashes; permanent failures are non-negotiable.
• Ubiquitous. Tens of millions of units in laptop packs: boards, configuration files and field reports abound.
• Openable. The official bqStudio software and the EV2400 adapter exist, but as we’ve seen, a two-euro microcontroller is enough to read, and often to write.

Its weaknesses

• Complex to configure. Over 400 parameters in flash. Getting Impedance Track to work properly requires a golden image built in a lab: identification of the cell chemistry, calibration, a full learning cycle. A poorly configured DIY pack gauges poorly, and the learning we chose takes several cycles.
• Security depends on the pack manufacturer. TI supplies the locks; it’s the assembler who chooses to close them. The Neato pack was shipped in Full Access. A brand-name laptop battery, on the other hand, is almost always sealed, and without the keys you only read the standard registers.
• Security, conversely, can be a wall. SHA-1 authentication and sealing are precisely what makes some packs unrepairable: a permanent failure on a sealed pack is a trash can, whatever the state of the cells.
• No more than 4 cells in series. For an e-bike (10 to 13 cells in series) you need its big brother, the bq40z80 (up to 7 in series), or another architecture.
• Hard to wire yourself. The QFN package is soldered with a reflow oven or hot air, not an iron; TI’s development boards cost around a hundred euros. In practice, DIY goes through salvaged boards.

What you can do with it, beyond the Neato

• Diagnose a laptop battery before throwing it away. A “dead” Dell, HP or Lenovo pack very often contains a bq40z50 (or a cousin: bq30z55, bq40z80) and six cells, three of which are fine. The ESP32 and this post’s sketch read the state of health, the counter, the faults, and tell you whether it’s the cells or the chip. On a sealed pack you read less, but you read.
• Rearm a pack after recelling. Exactly this post: counter, possibly permanent failure (PFStatus is cleared by command, in Full Access or with the key), then a learning cycle.
• Build a “smart battery” for your own projects. A salvaged BMS board with its bq40z50, four new 18650 cells, and you get a 14.4 V pack that protects itself, balances itself and announces its percentage: for a DIY robot, a field radio, a backup UPS for a home server, a work light.
• Monitor a battery remotely. The ESP32 has Wi-Fi: the same sketch can publish voltage, current, temperature and state of charge over MQTT (a lightweight messaging protocol, the home-automation standard) to Home Assistant or a database. A pack that warns before it gives out.
• Learn. The bq40z50 is a complete course in lithium battery management, with a free manual and a chip you can find in the trash. Everything an electric car’s BMS does, it does in miniature, and it lets you watch it work.

One reservation: all of this assumes an open (unsealed) pack, or one whose keys you have. Laptop manufacturers seal; manufacturers of packs for robots, tools and toys often forget. Check before you dive in — it’s the first readout, and it costs nothing.

What this says

I don’t believe anyone, at Neato or at its battery supplier, decided this robot would die in 2026. I believe something worse: nobody decided it would live.

Look at the layers.

The cloud. The robot was designed to do nothing without a server. When the server goes off, only the button remains. On the D3 through D7, a community managed to hook an ESP32 onto the motherboard’s serial port and give the robots back their autonomy (vacuula/fang, OpenNeato). On the D8 through D10, that port is password-locked. One generation later, the door was locked shut. Not for the user’s safety — for nothing, apparently, except so they wouldn’t touch it.

The authenticated battery. The robot verifies the pack’s identity. The forums are full of D5s bricked after a compatible battery was inserted. The manufacturer calls that security; it’s also, very concretely, a toll booth on the number one wear part.

The counter. 1,547 cycles, and an app that says “needs replacing”. Not because the battery would be unusable — the gauge itself reported it at 97% charged, and the original cells, measured since, still deliver 73 to 77% of their new capacity — but because a number crossed a threshold nobody shows you. The robot was taken out of service over a quarter less runtime.

And the absence of a path. A perfectly documented chip, left in full access, whose counter resets in a single command. No path, anywhere in the product, leads to that command. The diagnosis delivered to the user is “battery discharged”, which is false, and the proposed solution is “buy”, which is expensive.

Obsolescence, here, isn’t a time bomb programmed by a cynical engineer. It’s a sum of non-decisions: nobody budgeted a “reset the battery” feature, nobody wrote the honest error message, nobody left a port open. Each choice is justifiable on its own. Their sum manufactures €600 of waste with a charged battery inside.

The good news is that the same non-decisions leave cracks. The chip wasn’t locked. The pack manufacturer left its test pads in place. TI publishes its manual. And a two-euro microcontroller, plus an AI willing to read 17,000 lines of documentation without complaining, are enough to slip through.

From February 18, 2027, Article 11 of the European battery regulation (local excerpt) will require that portable batteries in appliances be “readily removable and replaceable by the end-user”. That’s progress. But this story shows that “replaceable” isn’t enough: my battery was replaceable, and replacement was precisely what I was being sold as the only way out. What we should demand is that objects tell the truth about their condition, and that they leave a path to correct it. A “reset the battery” button in an app costs an afternoon of development. Silence costs one battery per customer.

How to reproduce it

Hardware: an ESP32-C3 Super Mini (or any ESP32/Arduino with I²C), three wires, a soldering iron, possibly two 4.7 kΩ resistors. The pack must be opened at its circuit board — the sleeve is glued, a box cutter splits it without forcing.

Safety: the cells stay connected throughout the operation. No metal tool near the C+ and C− pads, which carry 16 V and several tens of amps of possible short-circuit current. No bracelet, no ring. The DA and CL pads, on the other hand, sit at 3.3 V and risk nothing.

The other side of the board: we don’t touch it, but it shows the manufacturer provided far more test points than the two we care about.

Wiring:

Software: bq40z50-reader.cpp and platformio.ini (PlatformIO is the tool that compiles and uploads the program; Arduino framework, target esp32-c3-devkitm-1). Serial monitor at 115200 baud. The essential registers, at SMBus address 0x0B:

In order: (1) connect, read, check that DeviceType answers 0x4500 and that the security level is Full Access — otherwise you’ll need the manufacturer’s keys, and this post doesn’t have them; (2) back up the flash (the sketch does it at startup) and put the file somewhere safe; (3) read PFStatus and SafetyStatus — a permanent failure is another story; (4) read the lifetime data (0x4380…) and compare it with the backup after a few days in the robot: a COV or CUV counter that climbs points to a cell, not to a counter; (5) only then, type c — and wait several days before concluding.

Three rules, if you go for it: read first, back everything up next, write only last. A gauge in Full Access lets itself be destroyed just as readily as repaired.

Frequently asked questions

What does error 4202 mean on a Neato?

It’s the “battery discharged” error on the D8, D9, D10 and D800. The app (when it worked) specified that the battery’s charge counter had been exceeded and that it needed replacing. It appears even with cells in perfect condition: what triggers it is what the pack’s chip tells the robot — in particular, from what we observed, a cycle counter that’s too high.

Does replacing the pack’s cells fix error 4202?

Not on its own. The cycle counter and the state of health live in the pack’s bq40z50 chip, not in the cells. After recelling, the error persisted for me with cells at 4.1 V.

Do you need an EV2300/EV2400 and bqStudio to talk to the gauge?

No. An ESP32 (or an Arduino) with two I²C pins, three wires and the TI manual are enough: the chip is documented, and on the Neato packs I’ve seen it’s left in Full Access, with no password. bqStudio is more comfortable, not necessary.

Does an off-the-shelf compatible battery solve the problem?

Sometimes, and sometimes the robot rejects it — the forums document D5s bricked after a compatible pack was inserted. Before buying, it costs one evening to check that the original battery hasn’t simply crossed a cycle threshold.

Is it dangerous?

The DA and CL lines sit at 3.3 V and are risk-free. The danger is elsewhere: the C+/C− and B+/B− pads at 16 V, capable of tens of amps in a short circuit. A single metal tool at a time, no jewelry, and touch nothing but DA, CL and the minus.

Why does the gauge report 0 mA of charging current?

Because it’s asleep. As soon as the current drops below 10 mA for about thirty seconds, it enters sleep mode and sets ChargingCurrent and ChargingVoltage to zero. Inside the robot, which draws current continuously, it stays awake. It’s not a fault, and a reset doesn’t “fix” anything: it wakes it up for thirty seconds.

Does this work on a D3, D4, D5, D6 or D7?

The packs of those generations use a different, locked chip, and community research hasn’t gotten anywhere. On the other hand, their serial port is open, and vacuula/fang or OpenNeato give those robots back their autonomy without the cloud.

Can the bq40z50 chip from an old battery be reused in another project?

Yes, if the pack isn’t sealed or if you have its keys. A salvaged BMS board with its cells replaced makes a 1S to 4S smart battery for a robot, a radio or a DIY UPS; an ESP32 hooked onto it can publish its status over MQTT to your home automation. See the section “Focus: the bq40z50”.

What exactly did the AI do, and what did the human do?

Claude read the 250-page manual, wrote the readout program, decoded the registers, suggested the reset and then the comparison experiment that revealed the sleep mode, and wrote this post with me. I soldered, measured, photographed, decided not to touch Qmax, and let the robot spend a night on its base — which disproved the first conclusion, its own as much as mine.

Is the robot repaired?

Not for certain yet. Resetting the counter (August 30) bought it one day, then error 4202 returned: the real cause was a weaker salvaged cell tripping the over-voltage protection on every charge. Fix applied on September 1 (charging voltage 4100 mV per cell, gauge relearning), under observation. Still not a single part bought. See Where things stand.

A short glossary

• Cell: the elementary accumulator, here in the 18650 format (18 mm × 65 mm). A pack assembles several of them.
• BMS (battery management system): the pack’s circuit board, which protects, balances and gauges the cells. Here, it’s built around the bq40z50.
• Gauge (gas gauge): the chip that counts what goes in and out of the battery and derives the state of charge from it.
• Chip / integrated circuit: a computer or a complete circuit etched onto a few millimeters of silicon.
• Microcontroller: a small complete computer on a chip, programmable; the ESP32-C3 is one.
• Serial bus / SMBus / I²C: two wires (data and clock) over which chips exchange digital messages; SMBus is the variant used by batteries.
• Address, register, command: a chip’s number on the bus, a memory slot that can be read, the number that designates it. 0x…: a number written in hexadecimal.
• Bit, byte: the elementary slot (0 or 1) and the group of eight; a flag is a bit that signals a state.
• Firmware: the program burned into a device. Flash: the memory that survives power-off; RAM: the working memory, wiped on restart.
• Cycle: a cumulative discharge equivalent to 90% of the capacity (adjustable threshold). The counter only ever adds up.
• RSOC: relative state of charge, the “battery percentage”; FCC: full charge capacity, as estimated by the gauge; Qmax: the cells’ learned chemical capacity; mAh: milliamp-hour, unit of stored energy.
• Internal resistance: a cell’s electrical “friction”, in milliohms (mΩ). The higher it is, the more the voltage drops under load and the more the cell heats up; it rises with age and betrays a tired cell before its capacity collapses.
• FET / transistor: the electronic switch through which the gauge allows or cuts charging and discharging.
• Pull-up: a resistor that holds a bus line at 3.3 V when nobody is talking.
• PF (Permanent Failure): a fault the gauge deems unrecoverable; it condemns itself and nothing clears it. There were none.
• COV / CUV (Cell Over-/Under-Voltage): per-cell over-voltage and under-voltage protections. The gauge cuts the charge (COV) or the discharge (CUV), resumes when the voltage is back in range, and counts every trip in its lifetime data.
• Impedance Track: TI’s algorithm that learns the cells’ capacity and resistance to gauge precisely.
• Full Access / Unsealed / Sealed: the chip’s three access levels, from most open to most closed.

References and local copies

So that this post stays useful once the links have vanished, the documents cited are hosted here, along with their original source.

• TI bq40z50-R2 Technical Reference Manual, SLUUBK0B (June 2017, rev. October 2018) — source · local copy (PDF, 1.6 MB).
• Map of the Neato pack’s data flash, decoded — bq40z50-df-map-neato.md · raw backup from August 29, 2026 — bq40z50-df-backup-neato-blueway-20260829.txt.
• The sketch and its configuration — bq40z50-reader.cpp · platformio.ini.
• Neato Robotics, “Announcement – 6th Oct 2025” (end of cloud services) — source · text copy.
• Regulation (EU) 2023/1542 on batteries, Article 11 (applicable from February 18, 2027) — EUR-Lex source · local excerpt.
• vacuula/fang (ESP32 firmware freeing the Neato D3–D7 from the cloud) — source · README as of August 30, 2026.
• renjfk/OpenNeato — source · README as of August 30, 2026.
• laptopu.ro thread on the Neato packs’ chips (Full Access via bqStudio) — source (no copy: the site refuses archiving).

Photos and measurements: mine. Manual reading, code and writing: with Claude. This post is also available as raw Markdown.

The first post told the story of building the tool and ended on its most uncomfortable lesson: the model does not predict what the fire will do, it predicts what it would do if nobody stood in its way. The gap between the two—a factor of 1.7 on the day the fire ran free, a factor of 12 on the day the crews held the front—is the firefighting effort itself, and the model did not represent it at all.

This post tells four stories: what the fire has done since, what the model learned by trying to represent the crews, what the real fight owes to an army nobody budgets for—residents and farmers—and what this model allows one to say—carefully—about a political question I was asked: if the program of L’Avenir en commun (“A Shared Future,” the platform of La France insoumise) had been in force for two presidential terms, what would it have changed on an episode like this one?

How you grade a model on the past—three terms that will come up all the way through. The hindcast (retrospective replay): you place yourself at a past instant, give the model only what was known at that moment, simulate forward, and compare against what actually happened. The area bias: the ratio of predicted burned area to observed burned area—a bias of 7.5 means the model burns seven and a half times too much. The AUC: draw at random one cell that burned and one that did not; the AUC is the probability that the model gave the higher score to the first. At 0.95, it is rarely wrong about the where—even when it is badly wrong about the how much.

Six days, forty-five thousand hectares

The facts first, because they set the scale. The main fire did not start at Biscarrosse: it started on July 22 at Saumos, in Gironde, from a brush-clearing worksite—1,400 hectares (ha) by that same evening. The Biscarrosse fire, a van in flames, followed the next day. From there, the days are counted in tens of thousands of hectares:

• July 24—19,000 ha in Gironde, 110,000 people evacuated, including the Cap Ferret peninsula by land and by sea;
• July 25—more than 32,000 ha, 167,000 evacuees, first drop of fire retardant—a product that does not evaporate like water but coats the vegetation to make it nonflammable—by a French Air Force A400M;
• July 26—42,000 ha, five towns at the gates of Bordeaux evacuated via FR-Alert (France’s cell-broadcast emergency alert system): roughly 220,000 people displaced in total, one of the largest peacetime evacuations in French history;
• July 27–28—a lull, firebreaks widened by bulldozer, the fire “contained but not fixed,” then “stabilized”… and a new heat wave announced by Météo-France (the national weather service).

Click on the figures to open them full size.

At the last tally I could source: 42,000 ha in Gironde, 3,500 in the Landes, 88 firefighters injured, more than 2,750 firefighters and nearly 3,000 gendarmes and soldiers deployed, European reinforcements (Croatian Canadairs, Portuguese Air Tractors, Czech and Slovak heavy helicopters), a Reaper drone for thermal mapping. EDF stated that the Blayais nuclear plant, some fifty kilometers from the flames, is not under threat—so the question that launched this whole project has, for now, a reassuring answer. The CEA’s Laser Mégajoule facility, for its part, saw firebreaks dug in a hurry around its site.

📡 On the tool side: the map at kokusho.ss2i.ca is still tracking both fires. This morning, the model moved the Cazaux air base to heightened watch against the secondary fire—the observed front is 7.3 km away and a third of the no-suppression scenarios reach the 6 km zone within 48 hours. In fairness: no press source documents any threat to Cazaux; this is a model output, and a counterfactual one. That is exactly the distinction this post is going to spend its time drawing.

What worked in the model

Since the first post, the model has passed two tests and gone up a level.

First test: the fuel-exhaustion hypothesis. The over-prediction of July 25 (a factor of 12) had a rival explanation to the firefighting effort: maybe the fire was simply boxed in between the ocean, the lakes and its own scar, with nothing left to burn. The test is simple and I recommend it to every modeler: look at where the model burns its excess hectares. The verdict is unambiguous—94% of the predicted area falls on intact pine forest that the real fire never touched. The fuel was there. The fire did not take it. What stopped it was indeed the firefighting effort, and it had to be modeled.

Second test: two attempts at a suppression model, two instructive failures. The first drew lots, cell by cell, on whether the crews held: they would have needed to win 93% of the skirmishes; they were winning 15%. The second held entire stretches of track—some thirty kilometers held… which the fire calmly went around. The lesson deserves to be written in bold: you do not contain a wildfire by holding a lot of line, you contain it by holding a closed loop, anchored on barriers the fire will not cross. Containment is a problem of topology, not of local physics.

The level gained: modeling the incident commander’s reasoning. Finding the best closed loop around a fire, leaning as much as possible on water, already-burned ground and existing roads, is a problem mathematics knows how to solve exactly, and the idea can be told without an equation. Every path leading from the fire to the outside must cross the line of defense—otherwise the loop is not closed, and the fire will find the hole. Looking for the best loop therefore means looking for the cheapest-to-hold set of cells that cuts every path: this is what is called a minimum cut. A classic theorem—Ford and Fulkerson, 1956—says this cut can be computed by solving a flow problem: imagine trying to push a fluid from the fire toward the outside, with each cell letting through a flow rate equal to its defense cost; the maximum flow that manages to get through is exactly the price of the best barrier, and the cells that saturate are the barrier. This is what Dinitz’s algorithm computes, as implemented in SciPy. Water is free, a track costs half price, open pine forest costs full fare—and every kilometer is billed according to the probability that a crew can actually hold it, based on documented operational thresholds: below 2,000 kW per meter of front, direct attack is possible; above 10,000, nothing holds, aircraft included.

Byram’s fireline intensity (Byram, 1959): the power released per linear meter of front, in kW/m—the product of the vegetation’s heat of combustion, the mass consumed per square meter and the front’s rate of advance. It is the quantity that decides everything: a Landes pine forest running at 600 m/h releases about 6,000 kW/m—already beyond the reach of a direct ground attack. Flame height follows from it almost directly (about 4 m here).

Two implementation details, for anyone who wants to redo the calculation. First, flow algorithms put capacities on the links between cells, whereas here it is the cell itself one is buying: so each cell is split into an “in” node and an “out” node connected by an internal arc priced at the cell’s cost—the technique known as node splitting (Ahuja, Magnanti & Orlin, Network Flows, 1993, § 2.4). Second, the cut must separate cells counting their eight neighbors, diagonals included—the “Moore neighborhood” of cellular automata—because fire spreads diagonally too: a barrier that only blocks the four cardinal neighbors lets the fire slip between two cells set in a staggered pattern.

The commander’s loop, in principle: every kind of terrain has its price, and the cheapest cut that closes the circle is the strategy.

Tuning it was a lesson in humility by iteration, each one paid for with a hindcast of some twenty minutes:

• without a price on the area conceded, the “optimal” cut went looking for lakes thirty kilometers away and gave up 150,000 hectares—mathematically minimal, operationally absurd;
• a line held at 3 a.m. is not held at 3 p.m.: I had to add overrun, the re-testing of lines when the front intensifies sharply—the midday surge that breaks the lines established overnight;
• and resources are finite: the defense is always attempted, but units wear out arc by arc, and the funding gaps become the breaches through which the big fires spill over.

And the same loop for real: the plan computed by the minimum cut on the July 25 fire, anchored on the ocean, the lakes and the scar. Each orange islet to the east rings a secondary fire detected away from the main one.

The result, on the two reference days: on the contained day, the bias falls from 12 to 7.5—better, not good; the remainder is split between the nooks of the scar the satellite never saw burn, the spot fires the model does not yet fight, and fuel moisture, still computed by an instantaneous formula with no memory (Simard, 1968): it looks only at the hour’s temperature and humidity, so that an afternoon at 39.8 °C can appear wetter than the day before. The known remedy is the Canadian Forest Fire Weather Index (Van Wagner, 1987) and its cumulative components DMC and DC—two “reservoirs” that fill with every rain and drain day after day with the heat, thereby keeping the memory of weeks of accumulated drought. That is the next job. On the day the fire escaped, on the other hand, the model now predicts a mean area within 14% of the observed, and it knows why: the lines held in the morning give way at the thermal peak. In both cases the AUC stays above 0.95—the model still knows where the fire is going.

The experiment a model makes possible: varying the resources

And this is where modeling becomes a political instrument—in the noble sense. Version 3 parameterizes the firefighting effort in “units deployed,” one unit holding about one kilometer of line, with the headcount drawn at random around a mean calibrated on real mobilizations (2,000 to 2,750 firefighters on the great Gironde fires of 2022 and 2026). Nothing then stops you from turning the dial: what happens with 30% fewer resources? With 50% more?

I replayed the two reference days at three levels of deployment, twenty draws each:

Hindcasts at +12 h, 20 draws per deployment level. “Median”: half the draws burn more, the other half less—more robust than a mean against extreme draws. Observed: 1,645 ha on the 25th, 4,642 ha on the 24th. Orders of magnitude from an experimental model, not forecasts.

I was expecting a nice downward curve—more resources, fewer hectares. The model answered something else, and it is the most interesting result of the week: resources do not buy hectares, they buy a loop. Below the threshold where the loop stops being affordable—here, around −70%, the equivalent of a force spread across three simultaneous megafires, which is exactly the fear for the summers ahead—you lose thousands of hectares at once. Above the threshold, the marginal return collapses: between nominal and +50%, not one hectare of difference. And on July 24, the whole column says it: line up 34 units or 168, the fire gets through—the lines give way to intensity, not to numbers.

The shape of the curve is the result: a threshold, then saturation—and on July 24, a curve that resources no longer move.

An important caveat before drawing political conclusions from it: this table understates the real effect of resources, because the model represents neither initial attack—smothering an ignition within the first hour, where every available Canadair counts double—nor the speed of aerial rotations, nor the splitting of the force across several fires. What it establishes is the shape of the curve: a threshold, then saturation. Not the uselessness of resources.

The other army: the logistics that crack, and the people who carry them

There is one thing that neither the table nor the curve shows, and that leaps out as soon as you read the situation reports and the local press: the question was not only how many units, but how they stayed on their feet. Logistics—water, vehicles, aircraft, feeding the crews—was the weak link from end to end, and it was cracking before the episode even began.

The facts, with dates. During the fires, seven Canadairs out of twelve were operational, the rest grounded for maintenance on thirty-year-old airframes—and the order for two additional aircraft had been canceled in 2024, before being placed again in June 2026 for delivery… in 2032. The national fleet of wildland fire engines went from 5,117 in 2002 to 3,845 in 2020, with the share of aging vehicles rising from 51 to 61%; the firefighters’ federation estimates that 10,000 would be needed. Three weeks before the episode, on July 6, a union of professional firefighters warned that more than 300 vehicles were missing to cover the needs of a season already at 7,000 fire starts. On the ground, a battalion chief was asking for a 13,000-liter tanker to “keep a permanent water supply,” reinforcement columns were arriving from the Paris region, and a volunteer firefighter from Bouches-du-Rhône died on the road—on a resupply mission. A chief warrant officer put it bluntly in the press: “we don’t have enough resources, human or material, to respond to disasters of such a scale.” These are not accidents: the Cour des comptes (France’s supreme audit institution) spoke in 2022 of a “failure of anticipation” on the aerial fleet, the Senate (2022) of “chronic under-investment” in fire engines, and the firefighters’ federations of a “model running out of breath.” Four years later, the 2026 episode played out with those very failures—known, written down, and uncorrected.

And yet the lines held on the days that were holdable. Partly because a second army rose up, one that nobody budgets for. On July 24 at 7 a.m., the préfecture of the Landes (the local office of the national government, headed by the préfet) officially issued “an appeal for solidarity to farmers to bring water tankers”—those trailer tanks holding tens of thousands of liters that are towed behind a tractor, and that refill the fire engines as close as possible to the front. Within hours, the Gironde chamber of agriculture registered more than 500 volunteers—Médoc winegrowers, wine merchants with their tanker trucks, public-works contractors with stubble cultivators, blades and bulldozers—of whom about a hundred would actually work the Saumos fire, to the point that the appeal was suspended on the 27th, overwhelmed by the influx. The timber industry felled 22 kilometers of pines in twenty-four hours to open firebreaks—103 km of firebreaks and access tracks created in total, says the prefectoral report of the 27th. Behind the front: volunteers running the supply centers for the 2,750 firefighters, restaurateurs preparing thousands of meals, veterinarians treating evacuated animals for free, the Bordeaux-Lac exhibition center opened for 10,000 people. None of this was improvised from scratch: back in 2022, at Landiras, farmers’ slurry tankers had saved the firefighters “up to three hours a day” according to the chamber of agriculture—and it was precisely this experience that Gironde had begun to formalize, a month before the episode, by taking inventory of the farm equipment that could be mobilized.

Let us reread that through the model’s lens, because it sheds light on both. The model counts “units that hold a kilometer” without asking who crews them: in reality, some of those units were tractors. The water resupply, the three hours a day of 2022, the plowed firebreaks—in the model’s vocabulary, that is endurance: arcs that stay held instead of giving way for lack of water, units that stay on the line instead of shuttling back and forth. In other words, the margin below the threshold, the margin the curve shows decides everything, was partly supplied by society itself—at the very moment when the State, which had had the reports pricing out what was missing sitting on its desk for four years, did not have it. Both halves of that sentence need saying: the mutual aid was magnificent, and it is the symptom of a shortfall. A slurry tanker does not replace a Canadair in maintenance; five hundred volunteers in twenty-four hours cannot be ordered, cannot be planned, and get suspended when the influx overwhelms coordination; and a system that structurally needs its neighbors’ tractors to hold its lines is not a properly sized system—which is exactly what the parliamentary report on the “value of what is saved” (the valeur du sauvé), presented ten days before the episode, was trying to say in budgetary language.

What if L’Avenir en commun had been in force for two terms?

Let’s get to it. The question was put to me this way: would the measures proposed by La France insoumise, applied since 2017, have changed anything about an episode like this one? The exercise is a counterfactual: it cannot be verified, it can only be argued. So I will start with what the program actually contains, because the first surprise is there.

What the program contains—and does not contain. I looked. Neither the 2017 edition nor the 2022 edition of L’Avenir en commun includes a chapter on civil protection. No number of firefighters to recruit, no budget for the SDIS (the services départementaux d’incendie et de secours, France’s county-level fire and rescue services), no number of Canadairs. The measures that touch our subject are elsewhere:

• section 27 (“Defending the forest”): strengthen the resources and staffing of the ONF (the Office national des forêts, the national forestry agency), ban clear-cutting—felling an entire parcel in one go—promote forests diversified in species and age against monocultures, and “strengthen the means of wildfire prevention and suppression”—wording without a figure;
• the Forest policy booklet: doubling the ONF’s staff (about 8,400 agents today, 16,000 in the mid-1980s), public acquisition of 100,000 ha, firefighting resources deemed “notoriously insufficient”;
• section 79: a Mediterranean intervention and civil-protection force against wildfires—the most directly “fire”-related measure in the program;
• section 68: a nine-month citizen conscription including civil-protection missions, and a national guard under civilian command.

In Parliament, on the other hand, the figures exist. I went through the archives of the last two legislatures (2022–2026), and the picture is more precise—and more modest—than a slogan in either direction would suggest:

Amendments and questions from the LFI group, 16th and 17th legislatures. Links at the end of the article. The figure of 220,000 volunteer firefighters by 2027 that one sometimes comes across is a government target, which LFI supported and questioned—not an LFI proposal.

Two honest observations about this table. First: the phrase “LFI proposed so many firefighters and so many Canadairs” would be misleading—the archives show funding mechanisms (€75M of investment, ~+10% in permanent resources, the “value of what is saved” from the Maudet–Pantel report presented ten days before the episode) and a demand that existing government targets be met, not headcount or fleet targets of its own. Second: everything was rejected, withdrawn or left without follow-up, the budgets then being pushed through under Article 49.3 (the constitutional provision that lets the government pass a bill without a vote). Against that, the reality: ONF staffing has shrunk by 40% in twenty years, the French fleet counts twelve Canadairs over thirty years old, the Cour des comptes was denouncing a “failure of anticipation” in their renewal as early as July 2022—and the two aircraft ordered in June 2026 will be delivered in 2032.

Now let’s put the model to work. In kokusho, a public policy can only act through three channels, and they do not carry anything like the same weight:

Channel 1—the available units. More firefighters, more engines, an aerial fleet of sixteen aircraft instead of twelve: in the model, that is the mean deployment going up. And here, setting this post’s two tables side by side is instructive: the real parliamentary proposals—+10% of the SDIS budget, €75M of investment—are of an order of magnitude that, mapped onto my sensitivity curve, falls in the saturation zone. On a holdable day, with the whole national force massed on a single fire, +10% would not have changed the burned area. Their value lies elsewhere, and it is twofold: margin below the threshold for the day when resources are spread thin—three simultaneous ignitions, half the fleet grounded, columns eight hours’ drive away—and equipment that gets moving faster on new ignitions, the channel my model does not yet represent and where every available aircraft counts double. That is precisely the ground of the sixteen Canadairs and the €30M supplementary aircraft: not winning the battle of July 24, but making sure it never takes place.

Channel 2—the width of the firebreaks. The DFCI—défense de la forêt contre l’incendie, forest defense against fire—is the network of sandy tracks, firebreaks and water points that grids the Landes forest precisely to give the crews ready-made lines to lean on. Maintained, cleared of brush, widened—the work of the ONF and of funded local governments—in the model, that means wider breaks, hence higher holding probabilities at equal intensity. This is the channel of the 40% of ONF staff lost: maintaining the network is precisely the work that was stripped away. Hard to quantify, but the mechanism is the right one.

Channel 3—the fuel itself. And this is the decisive channel, because it is the only one that acts on intensity. The Landes forest is a million-hectare monoculture of maritime pine—our fuel map is monochrome, and that monochromy is a public policy one hundred and seventy years old. A forest diversified in species and age, broken up by less flammable broadleaves, means a lower front intensity; and intensity is the only quantity that decides whether a line is holdable. Below 2,000 kW/m, everyone holds. Above 10,000, no one does. The slow measures are the only ones that move the thresholds. But let’s be honest about the horizon: two terms do not transform an industrial pine plantation—ten years of diversification means edges, test parcels, better-kept interfaces. The effect in 2026 would have been marginal; the effect in 2046 would be structural.

And July 24? That is the question that separates an honest counterfactual from a dishonest one. The model’s answer: on that day, none of the above was enough. With 50% more resources, the simulated area for the 24th does not move by a single hectare: the lines give way to intensity, not to numbers. When the front exceeds 10,000 kW/m, the arithmetic of resources no longer applies—you do not bulldoze in the face of a firestorm. The only possible victory on the 24th lay upstream: the fire never reaching that size. Initial attack within the first hour—which the aging aerial fleet does less and less quickly—and prevention, so that an accidental ignition from a brush-clearing worksite does not find 40 °C, an east wind and an unbroken pine forest. In other words: on the extreme days, only pre-fire policy exists. And the extreme days are precisely the ones that make megafires.

The limits of the exercise, without which it is worth nothing: the program itself puts no figure on firefighters or aircraft, and the real parliamentary figures (€75M, +10%) are far more modest than the ±50% of my table, which remains a reading hypothesis; the model is experimental and its residual bias is documented; the heat wave, the wind and a century and a half of monoculture cannot be governed in two terms; and a counterfactual can never be verified. What the exercise establishes is more modest and more solid: through which channels a policy acts on a megafire, and which of those channels were saturated on July 24.

What I take away from it

The first post ended on a modeling lesson: the model was not answering the question I thought I was asking it. This one ends on the symmetrical lesson, on the political side: “more resources” is not a single answer, because “the fire” is not a single problem. There are the holdable days, where every additional unit buys hectares—there, the Canadairs of 2032 ordered in 2026 are a scandal of budgetary arithmetic. And there are the unholdable days, where the only policy that still exists was played out ten years earlier, in the composition of the forest, the maintenance of the firebreaks, and the speed of initial attack on new ignitions.

A political program that wants to weigh on megafires is therefore judged against both regimes at once. On the first, the program gives the direction and it is in Parliament that the figures are found: modest—€75 million, +10%—systematically rejected or pushed through under 49.3, but placed at the two spots the model identifies as the real levers of the holdable regime, permanent SDIS funding and the initial-attack fleet. On the second—the forest, its staffing, its diversity—L’Avenir en commun states the problem at the very place where the thresholds move. And one must enter on the ledger what neither the programs nor my model counts: the margin supplied by society itself—the farmers’ water tankers, the volunteers at the supply centers—which held once again this time, and which no seriously sized State should ever book in its budget as a given.

It has to end with this said plainly: what just happened is not an anomaly, it is a preview. The 2022 Senate report—the very one that priced out the under-investment—wrote it in black and white: by 2050, burned areas could increase by 80%, and nearly half of mainland France’s heathland and forest could be exposed to high wildfire risk. Four years after Landiras, the same forest burned again—bigger, faster, closer to Bordeaux. Two “fires of the century” in four years do not make an exception: they make a regime. This is the new normal, and its signature is precisely the more worrying of my curve’s two columns: the unholdable days of the July 24 kind, the ones where the arithmetic of resources no longer applies, will be more numerous every summer.

You know the scene: the cat at the edge of the table, paw on the glass, eyes locked on yours—and it pushes. We laugh at the cat. We should look at the observer: the one who watches the glass slide and does not move is not a witness, he is a co-author of the breakage. For four years now that glass has been sliding before all our eyes. The reports were on the table—the Cour des comptes in 2022, the Senate in 2022, the firefighters’ federations year after year. The amendments were filed—€75 million for fire engines in 2022, rejected; the Canadair appropriations, rejected then pushed through under 49.3; the aircraft order, canceled in 2024 only to be placed again in 2026, delivery 2032. The job cuts at the ONF continue in 2026, the very summer the forest burns. At this point, the word “failures” is too gentle: these are choices, made knowingly, by people who had the numbers. And this post has spent enough time measuring to have earned the right to say it: I will not be the observer who says nothing to the cat.

And don’t take my word for it: in the middle of the episode, the independent outlet Bon Pote redid the count, roll call by roll call, of the National Assembly’s votes on wildfire suppression. The picture is unambiguous: two blocs. On one side, Communists, La France insoumise, Greens and Socialists, who vote for resources and prevention; on the other, from the president’s party to the Rassemblement national, who vote the opposite—the tourist tax for the SDIS, rejected twice; the insurers’ contribution, rejected when the amendment expected “at least 800 million euros” from it; the program to recruit professional firefighters, voted for by the left alone along with LIOT (a small independent group); and the decree signed by Gabriel Attal in 2024 canceling €50 million in civil-protection appropriations, taking the order for two Canadairs with it. The only unanimity in the whole file: €3 million for the DFCI—which gives the measure of what consensus amounts to. And the measure that matches my model’s fuel channel feature for feature—firebreaks of broadleaves between parcels of conifers, to break the continuity of the pine forest—was voted for only by La France insoumise, the Socialists and the Greens. The thresholds this post talks about have a political color in Parliament, and it can be checked vote by vote.

So yes, this post takes a side. From everything I have read and cross-checked, L’Avenir en commun is today the only national program that answers both regimes at once—and the roll calls above show that when these measures reach the floor, it is the whole of the left that votes for them: fuel and forest—species diversification, an end to clear-cutting, ONF staffing doubled, where the thresholds that decide whether a line is holdable move—and the sizing of civil protection—permanent SDIS funding through the “value of what is saved,” an initial-attack fleet now and not in 2033. Let no one tell me its figures are missing: they were filed, amendment after amendment, under the numbers this post cites—and it is those who rejected them who owe an accounting today. The rest of the political offer, when it talks about fire at all, talks only about aircraft—the holdable regime—and never about fuel—the regime that kills. But the Canadairs of 2033 will change nothing on the days when nothing flies, and those are the days that make megafires. A program that does not talk about the forest is not talking about the problem. The farmers’ tractors held the line this time. Next time—and the new normal guarantees there will be one—I would like the Republic to get there before they do.

The fire, for its part, does not wait for the debate to end: Météo-France is announcing a new heat wave. The map keeps running.

🔥 See the tool online—kokusho.ss2i.ca

Experimental, with no official standing. In the event of a fire, the only authoritative source is the préfecture: landes.gouv.fr · gironde.gouv.fr.

Sources

• Timeline and tally: Wikipedia (French), 2026 wildfires in Gironde and the Landes; press releases from the Gironde préfecture and the Landes préfecture; situation reports from franceinfo (July 27) and France 2 (July 28).
• Blayais: Montel News, July 27, 2026. Strategic sites: armees.com.
• Program: L’Avenir en commun, section 27; Forest booklet; sections 68 and 79 on laec.fr.
• The National Assembly’s votes, roll call by roll call: Bon Pote, “Which political parties voted for wildfire suppression?”, Sophie Kloetzli, July 27, 2026—tourist tax for the SDIS (roll calls 302 and 4074, 17th legislature), insurers’ contribution (4076), recruitment of professional firefighters (133, 16th legislature), forest adaptation plan (1509), broadleaf firebreaks between conifers (1556), decree canceling €50M in civil-protection appropriations (2024).
• Parliament and budget: amendments II-CF1334 (PLF 2023, €75M SDIS), I-CF594 (PLF 2025, TSCA ≈ +10% SDIS), I-3166 (PLF 2026, tourist tax), CL265 (LOPMI 2022, Canadairs 100% EU), II-CF2221 (PLF 2026, supplementary aircraft ≈ €30M); written questions no. 2391 (F. Chauche, volunteers) and no. 9156 (C. Lejeune, sixteen Canadairs); nosparlementaires.fr, “Canadair: what Parliament voted”; La Gazette des communes, the “value of what is saved” report.
• Context: Basta!, ONF staffing; Cour des comptes, referral of July 26, 2022; L’Usine nouvelle, Canadair order (June 2026); Senate, report no. 856 (2022).
• Logistics and mutual aid, 2026 episode: seven Canadairs out of twelve operational (Le Monde, via Wikipedia); prefectoral appeal for water tankers (Landes, July 24, 7 a.m.); Vitisphere: 100 farmers deployed, 500 volunteers, appeal suspended; coordination by the Gironde chamber of agriculture; prefectoral report of July 27: tally, 103 km of firebreaks; franceinfo: supply run by volunteers; franceinfo: “we don’t have enough resources”; France 3: “I wanted to be useful”; Bordeaux Métropole: shelter at Bordeaux-Lac, donation drive; CNEWS: a volunteer firefighter killed on a resupply mission; SNSPP-PATS, July 6, 2026: more than 300 vehicles missing; report: “we’re chasing the fire,” the 13,000-liter tanker; the Paris-region reinforcement column, the 22 km of pines felled in 24 h.
• The 2022 precedent and the structural findings: Réussir: the Landiras slurry tankers (50,000 liters brought in); Réussir: more than 100 tractors and tankers inventoried in Gironde (August 2022); Pleinchamp: “up to three hours a day” saved, and the 2026 formalization; Ministry of Agriculture, 2022; Europe 1: residents resupply the firefighters (La Teste, 2022); fire engine fleet: 5,117 (2002) → 3,845 (2020), 61% aging, FNSPF target of 10,000 (DGSCGC data cited in a budget annex); Senate, PLF 2023: “chronic under-investment,” and the capacity pacts; FO-SIS: “a civil-protection model running out of breath”.
• Fire physics: Byram G.M. (1959), “Combustion of forest fuels,” in K.P. Davis (ed.), Forest Fire: Control and Use, McGraw-Hill—fireline intensity I = H·w·R and the flame-length relation L = 0.0775·I^(0.46); Rothermel R.C. (1972), A Mathematical Model for Predicting Fire Spread in Wildland Fuels, USDA Forest Service INT-115—damping by fine-fuel moisture; Simard A.J. (1968), The Estimation of Moisture Content of Fine Fuels, Forest Fire Research Institute, Ottawa, FF-X-14—the instantaneous moisture formula used (and criticized) here; Van Wagner C.E. (1987), Development and Structure of the Canadian Forest Fire Weather Index System, Canadian Forestry Service, Technical Report 35—the DMC/DC indices with memory.
• Operational holding thresholds: Hirsch K.G. & Martell D.L. (1996), “A Review of Initial Attack Fire Crew Productivity and Effectiveness,” International Journal of Wildland Fire 6(4); Alexander M.E. & Cruz M.G. (2019), “Fireline Intensity,” in Encyclopedia of Wildfires and Wildland-Urban Interface (WUI) Fires, Springer—direct attack possible below 2,000 kW/m, engines up to ~4,000, nothing holds above 10,000; the rule “a firebreak holds from two flame lengths up” is a rule of thumb of DFCI planning, treated here as a soft transition rather than a sharp threshold.
• Containment algorithmics: Ford L.R. & Fulkerson D.R. (1956), “Maximal Flow Through a Network,” Canadian Journal of Mathematics 8—the max-flow/min-cut theorem; scipy.sparse.csgraph.maximum_flow (Dinitz’s algorithm); the conversion from node capacities to edge capacities (node splitting) is described in Ahuja R.K., Magnanti T.L. & Orlin J.B. (1993), Network Flows, Prentice Hall, § 2.4; survey of spread models (cellular automata included): Sullivan A.L. (2009), “Wildland surface fire spread modelling, 1990–2007,” IJWF 18, three parts.
• Validation scores: Brier G.W. (1950), “Verification of Forecasts Expressed in Terms of Probability,” Monthly Weather Review 78; AUC computed via the Mann-Whitney statistic; reliability diagrams and spatial scores (Sørensen-Dice, Jaccard): Wilks D.S. (2019), Statistical Methods in the Atmospheric Sciences, 4th ed., Elsevier. Comparison against persistence as the null reference is forecasting’s classic safeguard.
• Model data: NASA FIRMS, VIIRS 375 m active fire detections (Schroeder W. et al. (2014), Remote Sensing of Environment 143); Open-Meteo (Météo-France models, and Copernicus DEM GLO-90 elevation); land cover and roads: © OpenStreetMap contributors (ODbL) via the Overpass API. Fuel loads and base spread rates per class: assumed orders of magnitude, documented in the code, not a measured inventory.

On Thursday, July 23, a van catches fire on a county road in Biscarrosse. At 3:45 p.m. the flames jump into the forest, and within three days 30,000 people are evacuated. Like everyone else, I follow it on maps of red dots, and a question settles in — the kind of question you don’t quite dare put into words as long as you can’t answer it: what if it heads for the Blayais?

The Blayais is the nuclear power plant sitting on the right bank of the Gironde estuary, some fifty kilometers north of Bordeaux. A map of red dots does not answer that question. It shows where the fire is. Never where it is going.

To get from one to the other, you need a model. I wanted to see how far one could get cobbling together an honest one in two days. The result exists, it runs, and you can look at it here:

👉 kokusho.ss2i.ca — the map is public and updates with every new run.

An experimental tool, with no official standing whatsoever. In the event of a wildfire, the only authoritative source is the préfecture (the French state’s local authority).

But that is not the interesting part of the story. The interesting part is the list of everything it got wrong — and above all, what caught each mistake.

The first decision is moral, not technical

A tool like this one can display two very different things. The first:

“The fire will reach the plant in 17 hours.”

It’s crisp. It’s actionable. And it’s a fraud. To write a sentence like that, you would need to know the exact position of the fire front, the wind for the next seventeen hours, the actual dryness of the fuels and the effectiveness of the firefighting effort. I know none of those four things. Nobody does.

The second looks more like this:

“Out of 200 simulated scenarios, 6 bring the fire into the extended zone around the plant, at the earliest in 29 hours. The forecast wind runs crosswise to the site’s axis. Low confidence: last satellite detection 5 hours ago.”

It’s markedly less satisfying to read. It’s true.

Everything else follows from that choice. The tool never draws a trajectory; it draws envelopes — the established term for those contours that bound the reachable area — at 6, 12, 24 and 48 hours, in three levels of decreasing plausibility: the area reached in more than one scenario out of two, the one reached in one out of ten, and the extreme envelope crossed only in one scenario out of a hundred, the one where everything goes wrong at once.

And it refuses to boil the situation down to a single number. It gives three, separately: the threat level, the confidence that judgment deserves, and the freshness of the latest observation. Because a “green” computed on four-hour-old data is not good news: it’s an information gap. A satellite that sees nothing does not prove the fire has stopped — it proves that it sees nothing.

The building blocks, and what they really do

Click on the figures to open them at full size.

Seeing the fire: FIRMS and VIIRS. NASA distributes, free of charge and in near real time, the thermal detections from its satellites — the service is called FIRMS, and the sensors I use, VIIRS, carve the ground into 375-meter pixels. I prefer them to MODIS, which is older and four times coarser.

You have to understand clearly what a FIRMS detection is: a pixel whose surface temperature is abnormal. Not a fire perimeter. With delays, with gaps when no satellite passes overhead, and nothing at all when smoke or clouds block the view. That nuance governs the whole rest of this article.

Knowing what drives it: AROME, OSM, DEM. Three ingredients move a fire forward. Wind first, which weighs far more than the rest: I take it from AROME, the fine-mesh model from Météo-France (the French national weather service), and not at a single point but sampled across the whole domain — a fire of this size spans several grid cells, and the wind can turn locally. Vegetation next, pulled from OpenStreetMap: a dry pine forest burns, a pond does not, a vineyard barely. Terrain last, through a digital elevation model — simply a file of altitudes — because a fire climbs a slope far faster than it descends one.

Moving it forward: the cellular automaton. The core of the computation carries a learned name for a simple idea.

Cellular automaton — you divide space into regular cells, here 150-meter squares, and you set a rule that says how a cell’s state depends on its neighbors. You apply the rule everywhere, advance one time step, and start again. Conway’s Game of Life is the best-known example.

My rule: a burning cell tries to ignite its eight neighbors, all the faster when the vegetation there is flammable, when the slope rises, and when the wind pushes in that direction. The front spontaneously takes an elliptical shape stretched downwind — which is what firefighters observe in the field, and what models have reproduced since the 1980s.

Accepting that we don’t know: Monte Carlo. This is the point that changes everything.

Monte Carlo method — rather than computing once with the best possible values, you redo the computation hundreds of times, drawing at random, each time, the parameters you know poorly. Then you look at the distribution of the results. The name comes from the casino, and the method from the atomic bomb — Ulam and von Neumann, 1946.

So I run 200 draws. Each time I perturb what is genuinely uncertain: the wind forecast error — which grows with lead time and stays correlated over time, because a wrong forecast is wrong for a stretch rather than every other hour — the error in my own rate-of-spread model, the actual dryness of the fuels, and the occurrence of spotting, those embers thrown ahead of the front that leap across a road or a firebreak.

What gets displayed afterward is no longer a forecast but a tally: this cell burned in 150 of my 200 possible worlds, that one in 3. It’s the same logic as the cone of uncertainty for hurricane tracks.

One clarification that matters: these frequencies are not probabilities in the actuarial sense. They are frequencies conditional on my assumptions. If my assumptions are bad, so are my percentages. Keep that in mind — the rest of the article talks about practically nothing else.

First result: a perfectly motionless fire

First run on real data. The report comes out: new area burned after 6 hours, 103.5 hectares. After 12 hours: 103.5 hectares. To the tenth of a hectare.

A fire that doesn’t gain a single meter in six hours under a 17 km/h wind is wrong. And my 200 draws, supposed to explore different worlds, all gave rigorously the same result — which is even more suspicious.

The cause came down to a choice of index. When I computed the speed of passage from a cell to its neighbor, I took the speed of the source cell, the one already burning. But I mark the whole area already covered as “scar,” with a near-zero rate of spread — which is correct: an already burned zone does not easily burn again.

Except that the fire necessarily starts from the already burned area. All my source cells were scars, and therefore incapable of transmitting anything. The fire was a prisoner of its own perimeter.

The fix comes down to one word: take the speed of the target cell, the one whose fuel is about to be consumed. It’s also more physically accurate — a fire advances at the speed allowed by what it is attacking, not by what it has already burned. Unexpected bonus: it also fixes the crossing of bodies of water, which a flammable source cell could leap across.

Then I looked at the map more closely

The tool was running, the envelopes spread out nicely, the numbers looked plausible. I looked at them for a while before doing what I should have done from the start: open the input map, the one the model uses, and really look at it.

There was a problem. The model was setting the sea on fire.

And it was true. Here is the fuel map — the image that tells the automaton, for each cell, how fast the fire can advance there. On the left what my program saw, on the right the reality:

The whole dark-green mass on the left is the Atlantic. Classified as pine forest.

The reason is almost funny. OpenStreetMap does not map the ocean as an area. There is no “Atlantic” polygon: contributors have drawn the coastline — in OSM jargon, a way tagged natural=coastline — that is, a line, not an area. My query, meanwhile, was looking for areas. It dutifully retrieved the lakes, the ponds and the rivers, all polygons, and the open sea matched nothing.

Now, outside any recognized polygon, my program assumes pine forest. That was a deliberate choice: in the Landes forest (the vast maritime-pine plantation covering the southwest of France) the maritime pine dominates, and erring on the side of “it burns” biases the model toward caution. Except that applying that caution to 40% of the computational domain is no longer called caution. On this map, water goes from 3.4% to 40.7% once corrected: more than a third of my working area was flammable ocean.

My first fix retrieved the coastline and used it to cut the domain — perfect on my isolated test. In real conditions, failure: three of the twelve requests to the OpenStreetMap server came back in error, the coastline ended up full of holes, and a coastline with holes cuts nothing. The sea became fuel again.

The right solution lay elsewhere, and it exploits an OpenStreetMap convention: when a coastline is drawn, land is always on the left of the drawing direction. So it’s enough, for each cell, to find the nearest coastline segment and check which side you fall on — a simple cross product. Land on the left, sea on the right. A hole in the data now costs only local precision around the hole.

I only knew my first fix had failed because I had taken care to make the program shout. When it could not reconstruct the sea, it wrote in plain words in its report: “coastline present but unable to derive the extent of the sea from it: the open sea is likely to be treated as fuel.” A model that fails silently lies. A model that fails loudly lets itself be repaired.

The awkward question: does it work?

At that point, the tool was producing pretty maps. A pretty map has never proven anything.

And I had at hand something to catch it out: the fire had been burning for several days, so its own past was available. Rather than waiting to see whether the next forecasts came true, I could replay the ones we could have made two days earlier and see what they were worth. It’s a well-known method, and it has a name: hindcasting.

Hindcast (or retrospective forecast) — you place yourself at a moment in the past, keep only the data available on that date, simulate forward, then compare with what actually happened. It’s the standard way to evaluate a forecasting model when you can’t afford to wait.

So I place myself on the morning of July 24, throw away everything observed afterward, simulate twelve hours, and compare with what actually burned. Then I do it again for the 25th. Two runs, a handful of minutes of computation — and by far the best ratio between effort spent and what it taught me.

On the morning of the 24th, when the fire was running freely, the model over-predicts by a factor of 1.7. For a spread model, that’s respectable — we’re in the right order of magnitude. On the 25th, as firefighters were regaining control of the front: a factor of 12.3.

What’s interesting is not that the model is wrong. It’s where the difference between the two days comes from. The model did not turn bad overnight: same code, same wind, same forest. What changed between the 24th and the 25th was the firefighting effort.

My program doesn’t see it. It knows nothing of the crews engaged, nor of the control lines — those breaks firefighters open with bulldozers to stop the front — nor of the water drops. So it computes, without my having explicitly decided it, a no-suppression counterfactual: what the fire would do if nobody stood in its way. On the 25th, physics alone gave 22,758 hectares; the fire covered only 1,645, because people prevented it.

There is a consolation in these figures, and it’s an important one. It lies in a measure called the AUC.

AUC, for area under the ROC curve — measures the quality of a ranking, independently of absolute values. If I pick at random one cell that burned and one that did not, the AUC is the probability that the model ranked the first one higher. 0.5 = a coin toss, 1 = perfect ranking.

My AUC is 0.96 to 0.98 in both cases — while the area bias, for its part, varies by a factor of seven. In other words: the model knows very well where the fire is going, and is badly wrong about how much. That’s the best possible failure mode, because a scale error can be calibrated, whereas a direction error condemns the tool.

Which brings me to the least intuitive decision of this whole tinkering. I had a calibration factor ready to go: slow the spread down by just enough to land on July 25. I did not apply it. It would carve into the model the assumption that “suppression always succeeds” — precisely the one you must not rely on in front of a nuclear plant. The tool, moreover, refuses on its own to publish a global factor when its validation cases are too heterogeneous, and explains why rather than averaging two incomparable regimes.

What it doesn’t do — and that’s the most serious part

The worst limitation is none of the ones I’ve just recounted. It comes down to a phrase: the coupling is one-way. Weather drives the fire; the fire never modifies the atmosphere.

Yet a large wildfire makes its own weather. That is pyroconvection: the column of superheated air it sends skyward can rise several kilometers and form a pyrocumulonimbus, a genuine thunderstorm cloud born from the fire itself. It produces dry lightning that starts new fires tens of kilometers away, and it can collapse all at once, slamming a violent gust down to the ground, in any direction whatsoever.

That’s exactly what lets fires we thought contained break loose, and it is independent of the synoptic wind — the large-scale wind, the one AROME forecasts. So it’s invisible to my model. Real fire-atmosphere coupling exists, it goes by names like Meso-NH/ForeFire or WRF-SFIRE, and it requires laboratory-grade computing resources. Out of reach.

The compromise: not to simulate the phenomenon, but to assess its potential. There is an indicator for that, the continuous Haines index, which combines the instability of the air aloft with its dryness — in short, it says whether the sky “acts as a chimney” that day. Crossed with the fire’s radiative power, it gives me a score. A fraction of my 200 draws, equal to that score, then switches into pyroconvective regime: far more uncertain direction, boosted spread, more frequent and more distant spotting. Those draws naturally feed the extreme envelope.

A high potential therefore reads as “the wide envelopes become credible,” never as “this is what will happen.”

Another blind spot, discovered while watching this week’s heat wave roll in. My fine-fuel moisture comes from a classic fire-weather formula, Simard’s, which looks only at instantaneous temperature and relative humidity. It has no memory. Yet three days at 38 °C dry out the litter in depth, and the soil along with it. Hence this absurd result: my model shows a fuel moisture that rises on the day it will hit 39.8 °C. So it underestimates the effect of a heat wave. What’s needed are indices with memory, like the DMC and DC of the Canadian Forest Fire Weather Index, which accumulate the moisture deficit over days and weeks. That’s the next project.

So, the Blayais?

Click to enlarge — or go see the live version at kokusho.ss2i.ca.

The answer stayed the same from the first run to the last: observed front at 36 kilometers, none of the 200 scenarios coming within 10 kilometers, wind pushing the opposite way. The plant was never threatened. And the tool says so with its reasons, not with a verdict.

The site actually exposed was elsewhere: the Cazaux air base, 7 kilometers from the Biscarrosse fire, with up to 6.7% of scenarios reaching its extended zone.

And then there was that last morning when Cazaux abruptly went orange, with 96.7% of scenarios reaching that same zone. Spectacular. And wrong.

The satellite had seen nothing for fifteen hours. My program had fallen back on its fallback assumption: for lack of knowing where the active front is, consider that the entire burned perimeter is active. So the fire was spreading in every direction at once, and my 96.7% no longer measured a convergence toward Cazaux — it measured my ignorance. The actually observed closing speed, for its part, was zero.

From now on, in that specific case, the level falls back to “high uncertainty, no approach observed” instead of crying fire — unless an approach is actually measured, in which case the alert stands. It may be the fix I’m happiest with: it keeps the tool from turning an absence of information into an alert.

What I take away from it

All of this was cobbled together in two days, and I didn’t type the code: I had an AI write it. Same method as for the Czech convertible three weeks ago, but this time on a subject where being wrong is not trivial.

What cannot be delegated, on the other hand, is the rest: deciding that we would display envelopes and never a trajectory, choosing the sources, demanding that the model be tested against the fire’s own past rather than against laboratory tests, and reopening the input map when a result smelled wrong. The machine writes fast and well. It doesn’t know what needs checking.

Five fundamental errors were found in the model. What surprised me most was seeing what caught them:

• the fire imprisoned by its own scar: by an implausible number in a report;
• the rasterization that bogged down: by a computation that never gave control back;
• the flammable sea: because I finally looked at the input map, the one nobody thinks to open;
• the coastline reconstruction that didn’t hold up in real conditions: by a warning I had taken the trouble to write for that precise case;
• the false orange alert: by confronting what the simulation said with what the observation said.

None of them was found by the automated tests. I have sixty-four, and each of these bugs now has its own — they will prevent regression. But no test could have guessed that OpenStreetMap does not map the ocean. Tests check what you have already thought of. They are silent about the rest.

What worked was friction with reality: the real data, the real map, the real past of the fire. Hindcasting taught me more in two runs than two days of development did.

And its main lesson was not “the model is off by this much.” It was: the model does not answer the question I thought I was asking it. I was asking it what this fire was going to do. It was answering what it would do if nobody stood in its way.

That is useful information — it’s even exactly what you need to know what a wildfire is capable of. But it is not what you think you’re reading on a map.

🔥 See the tool online — kokusho.ss2i.ca

Experimental, with no official standing. In the event of a wildfire, the only authoritative source is the préfecture: landes.gouv.fr · gironde.gouv.fr.

It’s 4 p.m., it’s 37.7 °C outside at the hottest point of the past twenty-four hours, and my bathroom reads 30 °C. Not the bathroom after a shower: the bathroom empty, shutters closed, nobody in it. That’s what a heatwave does to a house — it fills it slowly, degree by degree, through the roof, through the walls, through every pane of glass, and by evening the house has become a radiator that hands the day back to you while you’re trying to sleep.

Against that, there’s not much you can do in the moment. But a heatwave has a weakness: the night. Around 4 a.m., the outside air drops to 20 °C, sometimes lower. For a few hours, there is out there a stock of free coolness, immense, renewed every night — and the only question worth asking is: how do we get it inside?

A bathroom extractor fan as a workhorse

The house already had everything it needed, actually. It just took looking at it differently.

Downstairs, a fresh-air inlet, originally installed to feed the wood stove. Upstairs, the bathroom — the hottest spot in the house, elementary physics. And between the two, a modest VMC (the French term for a mechanical ventilation unit) that, for years, has concerned itself only with humidity: it switches on when the shower fogs things up, off when it’s dry.

But if you run that extractor fan at night, something more interesting happens: it sucks up the hot air accumulated upstairs, throws it outside, and the resulting low pressure draws the cool night air in through the inlet downstairs. The whole house becomes a circuit: fresh air comes in on the ground floor, crosses, rises, and leaves through the top, carrying the day’s heat with it. The benefit isn’t local to the bathroom — it’s a house-scale stack effect, with a fan of a few tens of watts as the only engine.

The technical term for this is free cooling. I prefer the way we say it in French: the night works for us.

The rule, and the traps it avoids

What remained was to write the decision rule. The little computer that drives the extractor fan now queries the weather and only switches on extraction if four conditions are met at the same time:

1. the outdoor maximum over the past 24 hours is above 22 °C — we really are in the hot season;
2. the bathroom is above 24 °C — it really is hot upstairs;
3. the living room is above 20 °C — the house isn’t already cooled down;
4. the outside air is at least 3 °C cooler than the inside — otherwise we’d be stirring air for nothing.

The subtlety is in the first condition. You might think it’s enough to compare inside and outside. Wrong — and a mistake that would cost dearly in January: a house heated by the stove to 24 °C with 5 °C outside shows a 19 °C gap, more than enough to trigger a naive rule… which would then throw the wood’s heat out the window, sucking in freezing air through the air inlet. The very same one that feeds the stove. The system would sabotage itself.

Hence the season criterion: the outdoor max over a rolling 24 hours. My January readings top out at 14.6 °C; the summer ones never drop below 22 °C. Between the two, a chasm — the guardrail can’t be crossed by accident. And above all, it doesn’t look at the temperature of the moment: a 13 °C night after a 32 °C day is precisely the time to extract, and an instantaneous threshold would have forbidden it.

What the numbers say

Before wiring anything up, I replayed the rule against the real data from the past week — the house has been logging everything for years, it might as well be useful.

The week in one picture: the outdoors (blue) breathes from 20 to 38 °C, the bathroom (pink) takes the hit and settles around 28-30 °C. And at the far right, that line going up: the fan command switching to ON — the system has just been armed, a few hours before its first night.

Verdict: over the week of July 6 to 13, the rule would have triggered 48 hours of extraction. Average gap between inside and outside at the moments of triggering: 4.9 °C. Time slots: concentrated between 1 a.m. and 9 a.m., never in the afternoon — the rule found the rhythm of the nights all by itself.

And the figure that amused me most: during that same heatwave week, the extractor fan didn’t run a single minute. The air was so dry (29 to 37% humidity in the bathroom, against a trigger threshold of 60%) that its historical mission never woke it up. A perfectly functional motor, installed, wired, powered — and 100% dormant, precisely during the week when it had the most to offer. That’s exactly the kind of untapped resource I love: zero hardware to buy, just a rule to write.

Tonight is the first night under real conditions. The unknown is a frank one: the air inlet was sized for a stove’s combustion, not for ventilating a house. If its cross-section is too tight, the fan will mostly pull on the leaks in the building envelope and the actual airflow will be disappointing. Tomorrow morning’s curve will settle it — if the bathroom drops off sharply compared with the previous nights, we’ve won.

Remarkable events: −7 °C and +41.7 °C, the same year

A house that logs everything builds up its own little mythology. The table of outdoor records for 2026 almost speaks for itself:

• January 6, 2026: −7.0 °C. The coldest day ever recorded by the station. The stove ran nonstop, the air inlet downstairs was sucking in frost.
• June 23, 2026: 41.7 °C. The hottest — before summer had even officially begun. Three hours in a row above 41 °C.

The morning of the record: the plain under snow, crystal-clear sky — the same clear sky that, six months later, would let the sun push the thermometer to 41.7 °C.

A 48.7-degree range in under six months, at the same spot, measured by the same chain of sensors. The average, meanwhile, drifts without a sound — and that’s precisely the trap.

It reminded me of Mélenchon, during his first presidential campaign, already bristling at the word “warming” (réchauffement): too gentle a word, almost the promise of an early spring, two more degrees on an average, who would even notice? And who insisted, pointedly, on “climate disruption” instead (dérèglement climatique, a climate knocked out of adjustment). The nuance isn’t cosmetic, it’s the whole question: what damages houses, crops and people isn’t the average drifting — it’s the extremes pulling apart in both directions. Sharper frosts and earlier heatwaves. A climate machine that hasn’t simply gained a degree: one that has lost its thermostat.

July 13 over the years, since 1970 (Open-Meteo aggregates for my location). The average climbs by +0.32 °C per decade — 19.5 °C in the first years of the series, 21.5 °C over the last ten. Two degrees in half a century: that’s the “warming,” and on this graph it looks harmless. What you only see by squinting is the pink curve of the maximums running wild — the recent peaks blow through the ceiling of the 1970s. That curve is the disruption.

My two records of 2026 make the case on their own. And that’s exactly why you instrument a house: you don’t prepare for an average, you prepare for extremes — in both directions.

Under the hood, for those who’d like to build it

Everything above runs on hardware from the back of a drawer — that’s the important point, and the reason this post exists: anyone can put this together on a Sunday.

• In the bathroom: a Raspberry Pi Zero W (~€15), a €2 DHT11 temperature/humidity sensor on one GPIO, and a €2 433 MHz radio transmitter on another.
• The ventilation unit isn’t modified by a single wire. It’s plugged into a supermarket 433 MHz remote-controlled outlet (~€10): the Pi simply replays the ON/OFF codes of the original remote (rpi-rf library, protocol 1, 350 µs pulse — the values are captured by listening to the remote with a €1 receiver). No 230 V wiring, reversible in thirty seconds.
• A small server somewhere — here a VPS for a few euros a month, but a NAS or a second Pi would do exactly the same: one PHP page, one SQLite database, and that’s it.

The house’s workforce. Top, the veteran: a 2012 Raspberry Pi Model B — 14 years of service, it drives the living-room heating in Ruby. Middle, the bathroom’s Pi Zero, which has just learned free cooling. Bottom, their eyes: the DHT11, the €2 temperature/humidity sensor — the little ridged blue box every tinkerer has come across at some point. (Photos: Gareth Halfacree CC BY-SA 2.0; Evan-Amos, public domain; Crackopl CC BY-SA 3.0.)

Hunting down watts is part of the game, for machines that run around the clock. The Pi Zero draws ~0.6 W. The old Model B pulls ~2.5 — blame its 2012 linear regulators, which burn the excess voltage off as pure heat, and its USB/Ethernet chip, powered permanently. Nothing can be done about the architecture, but you can trim the software fat: rummaging through the veteran this week, I found a MySQL and an Apache from 2017 that had been running for nothing for nine years, an HDMI output active in NTSC with no screen on the end of it, a Bluetooth never paired, and a daemon waiting for shortcuts from a phantom keyboard. All of it cut: two degrees less on the processor in the middle of a heatwave, 38 MB of RAM given back, and above all no more pointless writes to the SD card — that’s the real killer. On the scale of the bill it’s anecdotal (2.5 W ≈ 22 kWh/year ≈ €5), but a system you want to see last ten years owes it to itself to be lean.

The architecture choices are all dictated by the same obsession: surviving outages, router reboots and the years.

• No daemon, a cron. The controller launches every 5 minutes, lives for twenty seconds, measures, decides, sends its radio code, exits. A process that isn’t running can neither leak nor hang — the Pi is at 267 days of uptime without giving it a thought.
• It’s always the Pi that pulls, never the server that pushes. The Pi re-downloads its configuration (a YAML file) every minute with a plain curl, and queries the weather at decision time. Behind any router, NAT or IP change, it works — and the “Enable” box ticked on the web page takes effect in the field the following minute.
• The weather comes from Open-Meteo (open-meteo.com): a free API, no key, with history. An hourly cron archives it server-side, and the Pi receives a minimal JSON: current temperature, max over a rolling 24 h, living-room temperature. Serving only observations — never the forecast — matters: the 11 p.m. line was announcing 24 °C while it was 35 outside, and a rule fed on forecasts would have sucked in the furnace’s air.
• A single table for everything: observations (source, metric, value, unit, metadata). Sensors, setpoints, commands, weather — everything goes into the same mold. Adding a sensor means adding a source, zero migration. It’s this table that made it possible to replay the rule against the archives before wiring it up.
• Fail closed. Server unreachable or weather more than two hours old → the Pi falls back to its original humidity logic. No 24 h max → no extraction (the season guardrail can’t be bypassed by accident). The worst-case scenario of a failure is the behavior from before.
• The curves on the page are drawn by uPlot, a ~50 KB library that handles tens of thousands of points without flinching.

And a word on what, to my mind, is non-negotiable: this data never leaves my perimeter. What these sensors measure is the inside of a house — when someone showers, when it’s heated, when it’s empty. The Pis push their readings over SSH to a server that I administer, the page that displays them asks for a password, and the loop stops there. No manufacturer cloud, no Alexa “skill,” no home-automation SaaS that shuts down in three years taking the history with it, not one byte in anybody’s analytics. The only outside dependency runs the other way: the house downloads Open-Meteo’s public weather, it sends nothing. The day the server changes — a NAS, another VPS, a shoebox — you move one SQLite file and everything starts back up.

Total budget per instrumented room: under €30. The luxury isn’t in the hardware — it’s in the years of data you accumulate, that you can query the day you have an idea, and that belong to no one but you.

Next: getting into the thickness of things

So far, all my sensors measure rooms. The next step is more intimate: getting inside the insulation.

The project: a rod planted vertically in the attic insulation, with four temperature probes at staggered depths — surface, one third, two thirds, bottom against the plasterboard. Above it, a fifth probe in the air under the roof tiles, which climbs to 60-70 °C right now. Below, the living-room thermostat, already in place. A complete measurement column, from the sun to the living space.

What it will tell, day after day:

• The real thermal lag: how many hours does the heat peak under the tiles take to cross the insulation? The manufacturer states a theoretical value; the settled, aged insulation does as it pleases. I want the true number, in my house.
• The damping: by how much is the day/night amplitude squashed between the surface and the bottom?
• The effect of the draft chimneys I installed on the roof to evacuate the heat under the tiles: in comparable weather, the insulation surface should be cooler if the draft is doing its job. Two columns of probes — one near the chimneys, one far away — and the answer will fall out on its own.
• And in the long run, an aging detector: a thermal lag that shortens year after year is insulation that’s degrading. Better to know before the heating bill says so.

Hardware-wise, nothing heroic: waterproof probes at a few euros each on a one-pair-of-wires bus, a microcontroller that sleeps 99.9% of the time on two salvaged rechargeable cells — enough to last about two years without changing the batteries. The electronics stay cool at the bottom of the attic; only the probes go up to the front line.

And in winter, we flip everything around

The heatwave will end. And the same intellectual plumbing will serve again, turned inside out like a glove.

The next project running through my head: air-based solar thermal panels on the outside wall — dead-simple solar collectors, a glazed black box in which air warms up in the winter sun. Even at 5 °C outside, a well-exposed panel puts out air at 30 or 40 °C in the middle of the day. Hooked up to the house’s air inlet, it becomes free preheating: instead of drawing in 5 °C air to feed the stove and make up for the extraction, we draw in air already warmed by the sun.

And the loop closes elegantly: it’s the same decision logic as free cooling, inverted. In summer, we extract at night when outside \< inside. In winter, we’ll inject during the day when panel > inside. The same sensors, the same weather, the same four-condition rule with its guardrails — only the sign changes. The probes in the insulation will even say whether the preheating shows up in the attic gradient.

A house, at bottom, is a thermal system that doesn’t know it. Mine is only just getting to know itself — and tonight, for the first time, it’s going to try to cool itself down while I sleep. I’ll tell you tomorrow whether it managed.

Postscript, on the morning of July 14

The first night has happened. The fan extracted for nearly twelve hours, from 7 p.m. to 8 a.m., with a one-hour pause around 1 a.m. — the gap had fallen back below the stop threshold, the rule did exactly what it was taught.

Raw result: bathroom from 31 °C at bedtime to 26 °C at rising. The best night of the week. But the figure I like is elsewhere. On the previous nights, the outdoors dropped to 23-24 °C and the bathroom stayed stuck at 28: a four-to-five-degree gap in the morning, the signature of a house that exchanges nothing with the night. This time, the controller held the gap between 1.4 and 2.4 °C until morning — the inside followed the outside on its way down, hour after hour. The air renewal is really there, and the air-inlet unknown is resolved: it delivers.

Transparency demands it: the windows were open that night, heatwave obliging — impossible to separate their share from the fan’s. The next night will be done windows closed, extractor fan alone. If the bathroom still hugs the outdoors to within two degrees in the morning, the demonstration will be complete. Domestic science advances one night at a time.

Next episode: the curves from the first night with the windows closed, and what 48 hours of nighttime draft change (or don’t) about a heatwave.

Illustration: a manga-style reinterpretation of one of the seller’s photos — the original is on justchairs.eu.

I came across a 1970s Czechoslovak convertible sofa online, made by OPP Drevovyroba, for sale at a dealer in Budapest. Low profile, sculptural armrests in bent teak plywood, and a mechanism described in a single sentence: “the sofa turns into a bed in one motion.” €1,550, 1,500 km from home, and dimensions that don’t fit my living room. The conclusion was obvious: rather than buy it, redraw it — and understand it along the way.

This post is the story of that exercise, carried out with an AI (Claude) driving Blender live. Spoiler: the AI got the mechanism wrong three times, and that is precisely what makes the story interesting.

The setup

On the tooling side, this has become almost mundane: Blender, a small add-on that opens a server on the machine (BlenderMCP), and the AI that connects to it. Ten minutes to install. From there, it writes Python inside Blender, builds geometry, takes screenshots of the viewport to check its work, and starts over. Me, I watch the model turn live on my screen and comment.

The choice made from the outset: a parametric model. Not mouse-driven sculpting, but a script with a block of parameters at the top — width, seat height, cushion thickness, backrest angle — and all the geometry, mechanism included, recomputed whenever a value changes. As we’ll see, that choice saved the day more than once.

Three theories for one mechanism

The seller provides about fifteen photos, none of the mechanism in action. So it had to be deduced.

Theory no. 1: the simple hinge. The AI’s first interpretation: the backrest tips backward on a hinge, like a click-clack sofa. Modeled, animated… and demolished by looking more closely at the photos: in bed position, the front strip of the sleeping surface is in front of the seat, not behind it. So the backrest passes over the top of the seat. Exit the hinge.

Theory no. 2: four-bar kinematics. If the backrest has to fly over the seat without hitting it, I told myself, it has to rotate and translate — hence two pivots and some connecting links. The AI took the idea seriously, very seriously in fact: it wrote a solver that places the pivots by numerical search along the perpendicular bisectors of the two poses, maximizing the clearance between backrest and seat throughout the swing. Result: a perfectly functional four-bar mechanism, 17 mm clearance verified over the whole travel. Elegant. And completely wrong.

Theory no. 3: the single pivot. A close-up of the armrest settled it: the screws attaching the arm to the backrest are a rigid fastening, not a pivot. Arm and backrest form a single moving part, which rotates around the round trunnion visible on the side of the box. One pivot per side. And then everything falls into place: since the pivot is low and central, the arc of rotation rises above the seat. There never was a collision problem to solve. The Czech designers didn’t need linkages — they had simply placed an axle well.

The lesson deserves a frame: when the AI misunderstands the real world, it doesn’t err timidly — it over-engineers. The four-bar mechanism was the brilliant answer to a problem that didn’t exist.

The beautiful mathematical gesture survived the shipwreck of theory no. 2: two poses of a rigid body in the plane determine a unique center of rotation — the intersection of the perpendicular bisectors. No more numerical search: the pivot is computed, exactly. And when given the right input geometry, it lands within a few millimeters of the original trunnion’s location. A nice cross-validation, fifty years later.

The armrest that becomes a leg

Another find from the bed-position photos: the backrest cantilevers 46 cm out in front of the box, and it’s the armrest that supports it — as it swings, the armrest’s branch points toward the floor and its tip rests there, an improvised strut. The little platform where you rested your elbow becomes a foot pad.

In the parametric model, we inverted the logic: rather than draw the armrest and then observe where it lands, the AI computes its bearing points by inverse rotation from their target on the floor. The tip of the armrest is defined as “the point which, after a 110° rotation, touches the floor at y = -47 cm.” Check at the final frame: z = 0.0 mm. Which also explains why the original armrest is so short and set back: its position is not an aesthetic choice, it’s the landing constraint. Form follows mechanism.

Where we go beyond the original

Understanding is good; improving is better. Three flaws of the original piece went through the wringer.

The two-firmness sleeping surface. On the original, a thick seat and a thinner backrest make for a bed with two zones. Fix: a common thickness of 14.5 cm everywhere, a perfectly uniform 126 × 200 cm sleeping surface.

The 65 cm deep seat. Impossible to lean back while keeping your feet on the floor. On closer inspection, the original already cheats: its backrest isn’t at the rear edge but pushed forward on the platform, and the dead zone behind it becomes sleeping surface when unfolded. We parameterized that cleanly: prof_utile = 50 cm, and the pivot recomputes itself.

The soft side facing the wrong way. The real head-scratcher. The forward swing exposes the back of the backrest as the sleeping surface: if the front face is soft for sitting, you sleep on the firm face. The original made its choice, and too bad for the seat. Our solution: a central axle running through the middle of the backrest. During the swing, the backrest makes a half-turn on itself — and the same soft face serves as backrest by day and sleeping surface by night. Cascading consequence: the arm now stops halfway up the backrest to carry that bearing… exactly at armrest height. The armrest is the bearing.

That left keeping the backrest from spinning freely. First idea: a slide bolt. Second idea, much better: a pin running in a 180° semicircular groove, concentric with the axle, milled into the inner face of the arm. The ends of the groove are the stops for the two positions — the travel of the groove is the travel of the half-turn. No latch to operate, automatic indexing, and in both poses the loads press the pin against its stop. Verified in the model: the pin sits exactly at the end of the groove in both positions.

What I take away from it

A picture is worth a thousand tokens. The three decisive corrections came from close-ups I sent to the AI: the rigid screws, the armrest-turned-leg, the forward-set backrest. It reasons remarkably well — but about what it’s shown.

The AI over-engineers when it misunderstands. The four-bar solver was magnificent and useless. Beware of brilliant solutions: check the problem first.

Parametric makes mistakes cheap. Three complete overhauls of the mechanism, and each time a few minutes of recomputation rather than hours of remodeling. Since the anchor points (pivot, floor contacts, bearing) are computed rather than placed by hand, everything follows.

The collaboration makes sense. It computes intersections of perpendicular bisectors and checks clearances to the millimeter; I can see that a 65 cm deep seat is unlivable and that a screw is not a pivot. Neither of us would have produced this design alone.

To be continued in the next episode: dimensioned 2D drawings, details of the bearing and the groove, and fabrication in 18 mm plywood. The script and the model are already running — all that’s missing are the dimensions of my living room.

The files

Everything is downloadable, help yourself:

• sofa_parametrique.py — the complete script: parameters, pivot computation, construction, animation. Open it in Blender (Scripting tab) and rerun it after changing the PARAMS.
• canape_convertible.blend — the Blender scene with the swing animation (frame 1 = sofa, frame 61 = bed).
• canape_convertible.glb — the model in glTF format, animation included, readable everywhere (online 3D viewers, game engines, AR).

Photos of the original sofa: justchairs.eu. 3D model: Blender 5.1 + BlenderMCP.

It all started with a stupid argument.

“Turn it off, time’s up.” An ordinary sentence. Except that evening, the reply wasn’t a normal teenage sigh. It was curt, raw, almost hostile — as if I had just ripped something away from him. Ten minutes later, he was himself again. But in between, there had been that moment: a kid I didn’t recognize, irritable, shut down, somewhere else.

And it wasn’t the first time. The pattern kept coming back: he would be watching Roblox videos — a YouTuber named Kevko, some Steal a Brainrot, some Lucky Block — and when I interrupted him right in the middle, things went sideways. Not afterward. Right in the middle.

I could have left it there. Declared “screens are bad,” set a rule, and worn myself out enforcing it. But I had a more precise hunch, and a son too smart to swallow a ban without an explanation. I needed to understand exactly what was going on in his head. And for that, I needed data, not impressions.

Act II — The investigation

First hypothesis, the most worrying one: what if the content itself was the problem? A lot of Roblox videos revolve around stealing, beating, trapping, trolling, winning against everyone else. Was my son spending his afternoons internalizing a logic of competition and domination?

The trouble was, I had no idea. I felt. And when it comes to raising kids, gut feeling is the shortest road to unfairness.

So I decided to do what a journalist would do: read the sources. Not half-watch two videos — pull the full transcripts of the channel’s biggest videos and analyze them, word by word.

I identified his 10 most-viewed videos (from 426,000 to 786,000 views), extracted the automatic French subtitles, and cleaned everything up: 48,437 words of transcript. Then I counted. I sorted the vocabulary into broad families — urgency, competition, reward, accumulation, conflict, mockery — and measured their frequency per 1,000 words.

That’s when the numbers started talking. And they didn’t say what I expected.

The aggressive content I had been dreading — domination, mockery, trolling — was practically nonexistent: 0.4 and 0.5 per 1,000 words, basically statistical noise. My son wasn’t learning to crush other people.

What dominated was something else entirely: accumulation and urgency. Always one more item. Always faster. The two most frequent theme words on the entire channel were “encore” (more) and “vite” (fast). And when I measured interjections and laughter — a proxy for intensity — some videos climbed to 23 excitement markers per 1,000 words, without a single pause for breath.

I had the wrong suspect. The danger wasn’t ideological. It was physiological.

Act III — What we found

All that was left was to check my numbers against the science. And that’s when everything clicked into place.

1. The unpredictable reward machine. The heart of Steal a Brainrot is chance: the Lucky Block that might drop a rare brainrot, the passive income that keeps ticking and nudges you to log back in. That is precisely variable-ratio reinforcement — the mechanism casinos have exploited for a century because it’s the most addictive one there is. The brain releases dopamine while anticipating the reward, not upon receiving it. You stay in permanent tension: what if the next one is the one?

2. It’s not the violence, it’s the pace. The key piece I found in a study published in the journal Pediatrics in 2011. Researchers showed children 9 minutes of a cartoon that was simply fast — a cut every eleven seconds — with no violence at all. Right afterward, their ability to concentrate and their patience were measurably degraded, compared with children who had watched a slow cartoon. Nine minutes. The Kevko format is exactly that: saturated delivery, choppy editing, zero breathing room. It isn’t what he says that acts on my son. It’s the speed.

3. And that’s why it was blowing up at home. When I cut him off in the middle, my son’s brain was still “up.” And the American Academy of Pediatrics says it explicitly: when the screen goes off, dopamine drops, and that drop leaves us grumpy and irritable. The irritability I was taking full in the face wasn’t insolence. It was a predictable chemical state — the backlash of an excited state that hadn’t been allowed to come back down.

The cruelest part is the relational effect. The content put him in a state where he was pushing away, without meaning to, the people in the same room. And the trap of “always one more” is that there is never a good moment to stop — so never really a moment when he was present with us. The real cost wasn’t screen time. It was real moments, with real people, disappearing.

The nuance, because we have to stay honest. No, brainrot doesn’t literally “rot the brain” — it became the Oxford dictionary’s word of the year in 2024, but it’s a cultural marker, not a diagnosis. No, the famous “dopamine detox” isn’t a real scientific concept: you don’t “reset” your dopamine by switching off screens. And yes, brainrot is also kids’ humor, a generational language. My son is not in danger. But he is, by design, being manipulated — and that is something we can fix.

Act IV — What we’re trying to do about it

I decided to make a bet: on his intelligence.

No head-on ban — a clever kid works around it and resents you for it. Instead, I switched sides. The message was no longer “Dad forbids it” but “engineers paid millions are playing with your brain, and I’m on your team against them.” Nothing annoys a teenager more than being manipulated. That was my best lever.

Then I proposed an experiment, because he likes science:

“For one week, just observe your mood in the 10 minutes after you stop. Rate it out of 10. And compare: when someone cuts you off in the middle, versus when you pick the moment to stop. If I’m wrong, I’ll admit it. But look at the data yourself.”

Giving him back control is precisely what the research identifies as the factor that most reduces end-of-screen meltdowns. And turning a recurring argument into a joint investigation takes him out of the defensive position.

Finally, we watched some videos together — not sermons, but breakdowns made by people a teenager respects:

• “Dopamine” series — ARTE, TikTok episode (~9 min): dissects, technique by technique, the app he knows. Clinical tone, zero moralizing, the “they’re manipulating me” click. → https://www.youtube.com/watch?v=-pOWdBpVR3s
• “Et tout le monde s’en fout” — #59 Les algorithmes (~7 min): funny, on your side, never preachy. → https://www.youtube.com/watch?v=5NiVg4DBJrI
• Tracks ARTE — “Brainrot: est-ce qu’internet fait pourrir nos cerveaux ?” : tackles his universe head-on. (Preview it first.) → https://www.youtube.com/watch?v=ubT8hS0lAlg
• Stupid Economics — “L’économie de l’attention”: the “your attention is the product being sold” angle. → https://www.youtube.com/watch?v=rMV1WaWGb3I
• Tristan Harris — TED Talk (French subtitles): the former Google engineer who sounded the alarm first. Maximum credibility. → https://www.ted.com/talks/tristan_harris_how_a_handful_of_tech_companies_control_billions_of_minds_every_day?language=fr

The plan: start with the first one (9 minutes, he recognizes his app), let him comment, don’t draw the conclusion for him. The short, factual format does the work on its own.

Epilogue

I haven’t “won.” This isn’t a battle you win in one evening, and that was never the point. But something has changed: my son stopped seeing a father who confiscates, and started seeing a mechanism that manipulates him. He has a vocabulary to name it now. And between us, conversation has replaced argument.

The content he watches isn’t evil. It isn’t even ideological — my own data proved it to me. It’s just a machine, very well designed, to keep a child’s brain in a state of maximum excitement and make it come back. Understanding the machine is already halfway to breaking free of it.

And that is a bet I’m willing to make on my son’s intelligence.

Sources & references

On dopamine and post-screen irritability - American Academy of Pediatrics — Screen Time and Temper Tantrums (the dopamine drop when the screen goes off makes kids irritable): https://www.healthychildren.org/English/family-life/Media/Pages/screen-time-and-temper-tantrums-helpful-tips-for-parents.aspx

On pacing/editing that degrades attention - Lillard, A. S., & Peterson, J. (2011). The Immediate Impact of Different Types of Television on Young Children’s Executive Function. Pediatrics, 128(4), 644-649. (The “SpongeBob” study.) Accessible summary (NPR): https://www.npr.org/sections/health-shots/2011/09/12/140401099/spongebob-may-be-too-speedy-for-preschool-brains - Recent meta-analysis on the short-term effects of media on children’s attention and executive functions (PMC, 2024): https://pmc.ncbi.nlm.nih.gov/articles/PMC12412071/

On reward loops and addictive design - The Vegas Effect of Our Screens — Psychology Today (variable-ratio reinforcement): https://www.psychologytoday.com/us/blog/tech-happy-life/201901/the-vegas-effect-of-our-screens - Why We Can’t Stop — Communication Research / Taylor & Francis (rewarding elements of games and problematic gaming among teens): https://www.tandfonline.com/doi/full/10.1080/15213269.2023.2242260 - Debunking the Dopamine Detox Trend — The Scientist (the “dopamine detox” is a myth): https://www.the-scientist.com/debunking-the-dopamine-detox-trend-72036

On “brainrot” and Steal a Brainrot - “Brain rot” named Oxford Word of the Year 2024 — Oxford University Press: https://corp.oup.com/news/brain-rot-named-oxford-word-of-the-year-2024/ - Steal a Brainrot — encyclopedia entry (passive income, gameplay loop, monetization): https://en.wikipedia.org/wiki/Steal_a_Brainrot

On using screens as an emotional regulator - Using screens to calm kids may hurt their emotional regulation — CNN (reporting on a study published in JAMA Pediatrics): https://edition.cnn.com/2022/12/12/health/tantrum-distraction-screens-parenting-wellness

Explainer video resources (cited in the article) - Dopamine series — ARTE (playlist): https://www.youtube.com/playlist?list=PL8Ax_z5vzflwdvoTnARE5FiYl42Sg-fYb - Et tout le monde s’en fout — #59 Les algorithmes: https://www.youtube.com/watch?v=5NiVg4DBJrI - Brainrot : est-ce qu’internet fait pourrir nos cerveaux ? — Tracks / ARTE: https://www.youtube.com/watch?v=ubT8hS0lAlg - L’économie de l’attention — Stupid Economics: https://www.youtube.com/watch?v=rMV1WaWGb3I - Tristan Harris — TED (French subtitles): https://www.ted.com/talks/tristan_harris_how_a_handful_of_tech_companies_control_billions_of_minds_every_day?language=fr

Methodological note: the lexical analysis covers the automatic transcripts (French YouTube subtitles) of the channel’s 10 most-viewed videos, about 48,000 words. Acknowledged limitation: a transcript measures words, not sound volume or editing pace — and that pace is precisely what the science identifies as the most decisive factor. The figures are therefore a converging clue, not a direct measurement of overstimulation.