Embedded firmware / Vehicle telemetry
Embedded application for a vehicle control and telemetry unitFirmware architecture, development and QA
Telemetry and over-the-air update firmware for an electric-bike control unit
An electric-bike maker whose products are built around its own smart batteries and powertrain wanted its bikes to use mobile connectivity for new rider and fleet features. It already had telemetry-unit hardware and a backend, but the unit's embedded software had only basic functionality.
Build the embedded application for the vehicle control and telemetry unit on an automotive MCU: cellular connectivity, telemetry reporting, core IoT functions, over-the-air firmware upgrades and USB connectivity for configuration from a PC, all on the client's existing boards and backend.
- Product
- Embedded application for a vehicle control and telemetry unit
- Buyer
- Light electric vehicle makers with telemetry hardware and a backend but basic device software
- Engagement
- Firmware architecture, development and QA
- Indeema scope
- Firmware architecture, Real-time application, Cellular connectivity and reporting, Over-the-air firmware updates, PC configuration and QA
The product need
What had to become possible
Build the embedded application for the vehicle control and telemetry unit on an automotive MCU: cellular connectivity, telemetry reporting, core IoT functions, over-the-air firmware upgrades and USB connectivity for configuration from a PC, all on the client's existing boards and backend.
Ownership, made clear
Where the work started and what Indeema owned
Starting system
Telemetry-unit boards
Two hardware revisions of the vehicle telemetry unit board were already designed, with an embedded project framework configured.
The unit's role on the bike
The vehicle control and telemetry unit takes inputs such as throttle position, brake lever and wheel-speed sensors and monitors and controls vehicle functions.
Existing backend
The client had backend infrastructure with a development server and data visualization in place.
Indeema owned
Firmware architecture
Review the hardware's low-level specifications, define the high-level firmware architecture and the software components, and adopt an RTOS on the chosen MCU.
Real-time application
Design the application on the RTOS thread-management API, with separate engineers on tasks such as modem initialization, update flow and telemetry queuing.
Cellular connectivity and reporting
Initialize the cellular modem and implement the queue that reports telemetry to the client's backend.
Over-the-air firmware updates
Implement the device firmware update flow so an interrupted connection cannot leave the unit unusable.
PC configuration and QA
Add USB connectivity for configuration from a PC; verify each milestone build against agreed acceptance criteria, with technical-lead review of all merged code.
Worked with
Cellular modem
Quectel cellular module on the telemetry unit, driven by the firmware for network connection and data transfer.
Client backend
Telemetry and firmware updates flow between the unit and the client's existing server and data visualization.
PC over USB
A USB link for configuring the unit from a computer.
Product constraints
What made the engineering difficult
- 01
Gaps in cellular coverage
The unit had to keep working when its GSM module could not reach the network, without losing telemetry.
- 02
Limited storage for queued messages
Telemetry stored during outages competes for limited on-device storage, so the queue had to avoid both message loss and running out of space.
- 03
Updates over an unreliable link
A firmware upgrade interrupted by connection loss must not brick the unit.
- 04
RTOS on a new MCU
Adopting an RTOS on the chosen automotive MCU required working through low-level hardware details before application work could start.
Engineering judgement
Decisions that shaped the product
Structure the application as RTOS threads
Use ThreadX thread management so modem handling, telemetry reporting and updates run as separate real-time tasks.
Queue telemetry on the device
Buffer telemetry locally while out of coverage, designed around storage limits so messages are not lost.
Make updates recoverable
Design the update flow so an interrupted download leaves the unit able to recover.
Define acceptance criteria up front
Agree a development strategy and acceptance criteria early, and have QA verify each milestone build against them.
Delivered product capability
What the product can do
- 01
Embedded application
A real-time application on Renesas RA and ThreadX that replaced the basic initial embedded code.
- 02
Cellular telemetry reporting
Modem initialization and queued telemetry reporting to the client's backend.
- 03
Coverage-gap handling
Telemetry stored on the device during network outages, within on-device storage limits.
- 04
Over-the-air updates
Device firmware upgrades designed to survive connection loss without bricking the unit.
- 05
USB configuration
Configuration of the unit from a PC over USB.
Product change
What changed for the product team
The client's telemetry unit moved from basic embedded code to a real-time application that connects over cellular, reports telemetry to the existing backend, keeps telemetry through coverage gaps, accepts firmware updates over the air and can be configured from a PC over USB.
For a light electric vehicle team that already has boards and a backend, the case shows the device-side firmware work that connects them: RTOS architecture, cellular reporting designed for coverage gaps, and update flows that tolerate a dropped connection.
- The basic initial embedded code was replaced with a real-time application providing cellular connectivity, telemetry reporting, OTA updates and USB configuration.
- Each milestone build was verified by QA against acceptance criteria agreed at the start.
Product evidence
A closer look at the product
Technology, in context
C/C++ · ThreadX RTOS · Renesas RA · Quectel cellular module · Python · NGINX · Grafana · GitLab
A comparable product problem?
E-bike telemetry unit firmware
Bring the product context, the system that already exists and the engineering decision you need to make.