Elevate Aura builds the over-the-air update path for connected devices: how a new build is published and delivered, how a device knows which version it is running, what happens when an update fails, and how an owner triggers one from the companion app.
An over-the-air update system is how firmware reaches a device that is already in a customer's hands. Elevate Aura builds that path end to end: publishing a build, delivering it over Wi-Fi, BLE or a gateway, verifying it before it is trusted, installing it, and recording which version each unit is now running.
The hard part is failure. An update that arrives half way through a power cut, or a build that starts and then stops responding, must leave a working device behind. We design that behaviour generically around your controller and its storage: the running image is not discarded until a new one has proved it boots, and a device that cannot confirm a healthy start returns to what it had.
We also build the human side: the version view across your fleet, staged rollout to a small group first, and an update the owner can trigger from the companion app. Hardware, storage layout capability and the bootloader support on the part are your hardware team's territory. This is a software-only engagement.
Without an update path, every firmware defect becomes a logistics problem with a travel budget attached to it.
An engineer drives out with a programmer to change three lines of code.
Support cannot answer the first question of any investigation: which build is on that unit.
The old image was erased before the new one had proved it could boot.
A bad build reaches the whole fleet in an afternoon because there was no staged rollout.
Controller, storage, bootloader support and the link the update travels over.
A build is versioned, signed and made available to the fleet or a subset.
Download over Wi-Fi, BLE or a gateway, resumable and power aware.
Integrity and signature checked before anything is written or trusted.
The device proves a healthy boot, or returns to the previous working image.
Version, outcome and any error recorded against the unit.
Workflow: A fix is published to a pilot group, confirmed against their reported version, then released to the rest of the fleet.
Result: A firmware fix without a travel plan.
Workflow: The app shows that a newer build exists, the owner starts it, and progress and any failure are shown plainly.
Result: Updates happen without a support ticket.
Workflow: The partially written image never becomes the running one, and the device starts on the build it already had.
Result: A unit that comes back on rather than going to the workshop.
Units in clinics and homes.
Machines on customer sites.
An installed base across regions.
Connected devices at volume.
First shipment, first field fix.
Fewer visits, faster fixes.
The new image is verified before it is trusted and the previous working image is kept until the new one has confirmed a healthy start. A device that cannot confirm that start returns to the build it was running. The exact arrangement depends on the storage and bootloader support your controller offers.
Over whatever link the product already has: Wi-Fi to your backend, BLE from the companion app, or a gateway on the machine's own bus. Downloads resume after an interruption rather than starting again from the beginning.
Every device reports its version, and that is recorded against the unit with its update history and any failure. The fleet view sits on a dashboard your support team uses. See device dashboard development.
Yes. The companion app shows that a newer build is available, starts the update, shows progress and reports failures in plain language rather than an error code. See device companion app development.
We work in software only. Where your part provides bootloader and storage support for updates we write to it, but the controller choice, memory layout capability, board and hardware route stay with your team. We do not design PCBs or certify anything.
Tell us the controller, its storage and how the device connects. We will scope an update path that fits the part you have, including the app side and the version view across your fleet.
Founder-led · Chennai, India · Built and supported by the person who wrote it