Frédéric Bosc

Independent IoT consultant & engineer

I build connected systems for a living, internationally, and at a scale where the mistakes get expensive. One stretch of that involved overseeing the operation of 400,000 gateways for a globally funded startup, which is a good way to learn which design decisions survive contact with a fleet and which only work on a bench.

My work sits where hardware meets software. In practice that means specifying devices that will still be working after a winter outdoors, building the network and storage that sit behind them, and then handing the lot over: repository, documentation, and enough training that nobody has to phone me to keep it running. I have no reseller agreements and no manufacturer ties, which is the only reason a recommendation from me is worth reading.

Some of what I do is straightforward integration. A fair amount is not, and that is usually the interesting part: reverse engineering a register map with an undocumented machine in front of me, writing firmware for a bridge that has to survive a plant room, sizing a solar panel against the darkest fortnight of the year rather than the annual average, or working out why a fleet that behaved perfectly for eleven months went quiet in February. I put a solar-powered tracker on a high-altitude balloon once and followed it from France to Turkey, 55 hours and a maximum link of 511 km, on under a hundred euros of hardware. That was for fun, and it taught me more about power budgets than any datasheet has.

The technology varies with the problem, which is the whole reason I stay vendor-neutral. A site with mains power and an existing network asks a different question from a pump station three kilometres from anything, and the answer might be cellular, a low-power radio, a wired fieldbus, or all three feeding one pipeline. What does not vary is the layer underneath: ingest that does not lose readings, storage that still answers quickly in year five, and dashboards built for the people who open them every morning rather than for a demonstration.

Infrastructure of this kind has two possible careers. It runs quietly for years and nobody thinks about it, or it becomes everybody's problem, and what separates the two is almost always a set of details that are tedious to get right and cheap to skip. Getting them right is most of the job, and it happens to be the same discipline that keeps a project on its dates.

The thread running through all of it is a bias towards the long view. It decides which hardware I will specify, which architecture I will argue for, and how I work with the people I am building for, and it is why I care what happens after go-live. A deployment is rarely finished on the day it is switched on, and I would rather still be useful at that point than have handed over something nobody can maintain.

Everything I write about here is something I have built and measured, which is also true of the demo dashboard: real devices, reporting now, open without a login. It is a fair picture of what I leave behind. Open the demo dashboard

Some of the companies I have worked with