Embedded Software Development

What we do

What turns an electronic board into a device is the software running on it. Our embedded software service covers that layer: device start-up, sensor and bus reading, the communication stack, persistent storage of the configuration, behaviour on failure and updating in the field.

Most of the time we write firmware for boards we designed ourselves, but we can also work on a board designed by another team. In that case we start by reading the schematic and the datasheets; pin mapping, power-up order and the behaviour of the line drivers have to be clear before any firmware is written.

Communication layer

A field device exists to move data, so most of the work is communication. The layers we work with regularly:

• M-Bus (EN 13757): The wired meter line. Primary and secondary addressing, polling meters, decoding the data telegram, and flagging a meter that does not answer without aborting the reading session.
• wM-Bus: Listening to wireless meters over the radio and decoding their frames.
• RS485: A multi-device line over long cable runs, carrying field protocols such as Modbus RTU.
• Cellular (GSM): Connecting to a remote server through a modem, with retry and queueing when the link drops.
• LoRaWAN: Long range at low power; node firmware that works within duty cycle and spreading factor constraints.
• Bluetooth (BLE): A local link established next to the device with a phone or a handheld terminal, for commissioning and reading flows.

Which layer is chosen depends on range, power budget, whether cabling is possible and how often the data is needed. That decision comes before the hardware design, because the choice of radio and modem also shapes the power stage of the board.

How we work

Device firmware cannot behave like desktop software: there is no user, nobody to restart it, and the line can drop at any moment. So we follow a fixed discipline:

• A non-blocking, timer-driven flow in which every task carries its own state.
• A watchdog arrangement that recovers the device if an operation gets stuck.
• Configuration kept in non-volatile memory, so the device can be set up in the field without being reprogrammed.
• Bus errors counted and written to a readable log — so a problem is read from the record rather than described over the phone.
• A version number carried on the device, and a partition scheme ready for remote updates.

Technology

Processors from the ESP32 family are common on the boards we work with: our wireless meter receiver board uses an ESP32-S3 with an SX1262 radio, and our LoRa nodes use an ESP32 with an SX1276 radio. The processor and radio differ per project and are decided together at the specification stage.

Our experience on the metering side comes from our own products: the firmware of the M-Bus master converters (cellular, Wi-Fi, USB and Bluetooth versions), of the RF + GSM collector terminal and of the wireless meter receiver board was written by this team.

Scope and limits

• We do not attempt to reverse-engineer the closed protocol of a third-party device without documentation from its manufacturer.
• Figures such as battery life, reading range and data latency depend on site conditions; we do not commit to numbers for them before they are measured.
• Where security matters, key storage, signed updates and access control are planned separately as part of the scope.