IoT Consulting for Devices That Have to Work in the Field
IoT consulting from an engineer who designs, builds and runs connected hardware in production. Architecture, power, connectivity, firmware updates and data ingest for devices that sit outdoors and have to keep working.
I design, build and run connected hardware for a living. My company makes battery-powered controllers that sit in fields and over fish ponds, read sensors over RS485, and report over cellular networks for a year at a time without anyone visiting them.
That work has taught me where connected products go wrong, and it is almost never where the datasheet says. It is in the gap between a device that works on a desk and one that works after a winter outdoors. IoT consulting with me is about closing that gap in your product, before it costs you a recall or a season of bad data.
Problems I get asked about
Battery life that does not match the spreadsheet
The estimate said a year and the device lasts three months. The gap is usually in what happens around sleep: how long the modem takes to attach, what wakes the device, and what stays powered when it should not.
Data lost when the network drops
A device that only sends live readings leaves holes in every chart. I help design buffering that survives days without coverage, stamps each reading when it was taken, and catches up cleanly.
Sensors that work on the bench and fail on site
RS485 and Modbus problems rarely show up at a desk. Addressing, bus wiring, power sequencing and timing all behave differently with a long cable and a real sensor.
Firmware updates you are afraid to send
Updating devices you cannot reach by hand needs a plan for failed downloads, mixed hardware revisions and a way back. I help set that up before the first unit ships.
Choosing between cellular, WiFi and LoRaWAN
Each one changes the power budget, the running cost and what the device can promise. The right choice depends on where the device sits and how often it has to speak.
A backend that struggles as the fleet grows
Ingest that was fine for fifty devices slows down at five hundred. I review the message path from device to database and find where it will give first.
Who this is for
- Teams building their first connected product who want the architecture checked before they commit to it.
- Companies with devices already deployed that are draining batteries, dropping data or failing in ways nobody can reproduce.
- Founders who need an independent technical opinion on a design, a supplier or a plan.
How we can work together
- A working session
- One focused call on one problem. I read your material beforehand so the time goes to the problem.
- A written review
- I go through your design, code or plan and send back findings in order of priority, with what I would change and why.
- Ongoing advisory
- Regular calls while you build, with questions answered in between. Suited to a team working through a hard stretch.
See how I work
Questions people ask first
Do you build the device or the firmware for us?
My role here is advice and review. Your team, or the partner you choose, does the building, and I stay close enough to catch problems early.
What do you need from us before a first call?
Whatever exists: a block diagram, a schematic, the firmware repository, a description of the failure. The more I can read beforehand, the more useful the call.
Which hardware and protocols do you know best?
ESP32-based devices, cellular modems, RS485 and Modbus sensors, MQTT and over-the-air updates are the stack I run in production. I also work with LoRaWAN.
Talk to me about ioT consulting
Tell me what you are building and where it is stuck. I read every message myself.