C on Texas Instruments and ESP32 parts for Bluetooth tags and hubs, including our own hardware. Not many web studios can say that.
We ship our own hardware, so the constraints here are ones we live with rather than read about.
Duty cycling, sleep states and radio scheduling designed around the battery, because a tag that dies is a tag nobody trusts.
Advertising intervals, provisioning and connection handling, tuned for range and battery rather than left at defaults.
Signed updates delivered through the hub, with a recovery path so a failed update doesn't brick the device.
The same team writes the firmware, the app and the console, so problems don't get lost between suppliers.
Our own tags and hubs run firmware we wrote, on TI and ESP32 parts. This is a thing we do rather than a thing we advertise.
On a coin cell the radio is almost the entire budget. Getting from months to years is a firmware problem before it is a battery problem.
Getting a device onto a network safely, and being able to fix it afterwards without collecting it. A device you can't update is a device you'll replace.
Reading a part correctly at low power, which usually means understanding its datasheet better than its example code does.
Getting a toolchain to build again is normally the first real problem, and often the largest.
Written for someone deciding, not for someone who already knows. Skip it if you do.
C running directly on a microcontroller, usually with no operating system underneath it. The chip has kilobytes of memory rather than gigabytes, no screen and no keyboard, and your code is the only thing running. It's the same language as ever; the constraints are what make it a different discipline.
Because every chip vendor ships a C compiler and a C library on the day the part is released, and the alternatives arrive later or not at all. When you're choosing a component for its power draw and its price, the language has to follow the hardware rather than the other way round.
There's no safety net. No garbage collector, no exception you can catch, and a mistake with memory doesn't crash politely — it corrupts something and shows up hours later as behaviour nobody can reproduce. That's why firmware is written slowly and reviewed carefully.
On a battery-powered device almost every decision is about staying asleep. How often to wake, how long to transmit, when to talk to a sensor. Get it wrong and a two-year product life becomes two months, and it can't be fixed later in software without changing the behaviour you sold.
Nearly always the radio duty cycle. It's measurable on a bench and usually improvable by a large factor.
Every bug becomes a recall. Adding over-the-air updates later is possible but far more expensive than designing them in.
A missing toolchain version or an undocumented step. Extremely common in inherited hardware and the first thing to fix.
Yes. Schematics and PCB layout in KiCad, then manufacture.
Texas Instruments SimpleLink and Espressif ESP32 parts, which cover most low-power Bluetooth and Wi-Fi work.
Usually yes, given the schematic and the datasheets. Where the hardware itself is the limitation we'll tell you plainly rather than write around it.
Usually. We start with the schematic, the datasheets and whatever firmware exists, and tell you what is feasible before quoting anything.
Yes, in KiCad, through to manufacturing files. Doing both means the firmware and the hardware are decided together rather than negotiated afterwards.
A few lines are enough to start. You get a reply within two working days.
