Main content
EnglishRomână
Contact
EnglishRomână

IoT and embedded software, firmware to app

We develop IoT and embedded software as one chain, designed by one team: the firmware, the radio link, the cloud and the phone app. It runs live in a museum and, as a prototype, on our own rally hardware.

Project briefIoT case studies
FIG. 1Muzeul Baia, live zone mapDemo data
Live zone map on the museum floor plan: ethnography hall 24 people, history hall 14, foyer 5 and multipurpose hall 4, each shaded by occupancy, with entries and exits in the last hour.

IoT system architecture: five layers, one design

Most IoT failures sit between layers, which is why all five are designed together.

FIG. 2From the sensor to the screen
Five layers of an IoT system: sensors feed an ESP32-S3 hub (device), which talks Bluetooth LE (link) to a phone app (gateway), which sends readings to a cloud database (cloud), read on a dashboard (screen).BLEHTTPSSensorsGNSS, IMU, wheelESP32-S3 hubC, FreeRTOSAppiOSIngestChecked devicesDatabaseReadingsDashboardMaps, replaysDeviceLinkGatewayCloudScreen

The five layers in detail

Device: Firmware
C on ESP-IDF and FreeRTOS, or an Arduino-class board for a first prototype.
  • Pulse counting with glitch filters
  • GNSS and inertial sensor drivers
  • SD logging that survives power loss
Seen in: Regularity Rally System, battery prototype
Link: Protocol
The contract between the device and everything after it.
  • Bluetooth Low Energy
  • Secure pairing
  • Backfill after a dropout
Seen in: Regularity Rally System, battery prototype
Gateway: Phone or edge
The piece that turns packets into records and relays commands back.
  • iOS Bluetooth in the background
  • Reconnect and re-scan
  • Commands back to the device
Seen in: Battery prototype
Cloud: Ingest
A cloud database that accepts what real firmware sends.
  • Only known devices accepted
  • Every reading kept
  • New sensors added safely
Seen in: Muzeul Baia
Screen: Dashboard and app
Where people read the data and act on it.
  • Live zone maps
  • Hourly buckets in local time
  • Replays of a full session
Seen in: Muzeul Baia, Regularity Rally System

Reliability on real hardware

  • SD logging with a drain on power loss
    What it handles: The ignition cut in the middle of a stage
    Project: Regularity Rally System
  • Crash-recovery journal and watchdog in the app
    What it handles: The app killed by the phone during a stage
    Project: Regularity Rally System
  • Versioned session logs that replay
    What it handles: A bug reported after the drive, far from the car
    Project: Regularity Rally System
  • Counter-reset handling in SQL
    What it handles: A people counter that restarts and starts again from zero
    Project: Muzeul Baia
  • Raw payload stored with every reading
    What it handles: A firmware update that changes the payload shape
    Project: Muzeul Baia
  • Bluetooth state restoration and auto-reconnect
    What it handles: A phone locked in a pocket, or walked out of range
    Project: Battery telemetry prototype

One team from firmware to app

  • The packet format is decided once, in a document both ends are tested against.
  • A reading that looks wrong on the dashboard has one owner, from the sensor to the chart.
  • The replay tools run the same code as the live path, so a problem seen on the road can be reproduced at a desk.
  • App fixes ship over the air, as on the Muzeul Baia audio guide since its first release.

IoT projects at their real stage

Muzeul Baia

In production

People counters feed a live zone map; the audio guide works offline.

Live room occupancy, no one identified

Room occupancy refresh, no one identified

Muzeul Baia case study
FIG. 3The audio guide, offlineDemo content
Audio guide app home screen in Romanian: a note that the content is saved for an offline visit, a button to browse exhibits, a QR scan shortcut and three exhibits from the collection.
Exhibit screen in the audio guide app: an illustration of the mammoth jaw, its title, a narration player paused at 0:08 of 0:13 and the exhibit text in Romanian.

Regularity Rally System

Prototype, own R&D

Distance from the wheels, drift corrected by GNSS.

Distance from the wheels, corrected by GNSS

Timing error on a 3.2 km test stage

Project notes

The board is routed and passes its design checks but is not fabricated yet, and the app talks to a simulated hub.

Regularity Rally System case study
FIG. 4Pilot displayTest data
Pilot display in dark mode: ON PACE above a large green delta of plus 0.5 seconds, a tolerance bar from minus 2 to plus 2 seconds, the next speed change to 55 km/h in 3.00 km and the finish at 9.00 km. Synthetic test data.

Battery telemetry prototype

NDA

Vehicle battery telemetry, from firmware through an iPhone to the cloud.

Project notes

A proof of concept for engineering use. No client name, no screens.

Sector
Automotive batteries, EU
Device
Embedded firmware, Bluetooth
Gateway
iPhone app
Project details on request
FIG. 5Battery telemetry loopNDA
Battery telemetry loop: the sensor board notifies readings over Bluetooth LE to a native iOS gateway app, which syncs them to one cloud document per device; commands written in the cloud travel back through the phone to the board.NotifyWriteSyncCommandSensor board12 V batteryiOS appGatewayDevice documentOne per device

IoT and embedded development FAQ

Firmware, cloud and mobile app from one team

One team writes all of it: the device firmware in C, the ingest and the database, the dashboard and the phone app. The Regularity Rally System spans firmware, a custom board and an iPhone app; Muzeul Baia spans people counters, cloud ingest, a staff map and an audio guide app.

Hardware and PCB design

Prototype boards are designed as code: the rally carrier board is a SKIDL netlist laid out in KiCad, with SPICE simulations of the power input. Volume manufacturing and radio or safety certification belong to a later stage and involve a manufacturer and an accredited test lab.

Chips, sensors and protocols

ESP32-S3 on ESP-IDF and FreeRTOS, Arduino-class Bluetooth boards for early prototypes, u-blox GNSS receivers, ST inertial sensors and TI Hall-effect sensors. Links so far: Bluetooth LE GATT on NimBLE and CoreBluetooth, and HTTP push from PoE sensors.

Taking a prototype to production

A prototype proves the sensing and the protocol. Production adds a fabricated and tested board, an enclosure, certification and a way to update devices in the field. The rally hub shows where a prototype stands: routed board, firmware passing host tests in CI, bring-up not started.

Offline operation

Devices and apps are built to work without a connection. The rally hub logs to an SD card and backfills the phone after a dropout; the museum audio guide keeps its content on the phone, so a visit works with no signal.

Device data: where it goes

Readings land in a cloud database, and only known devices can send them. The museum's counters are anonymous by design: they count passages between rooms and never identify a person.

A device, its firmware and its app, in one brief

A few lines on the sensor and who reads the data are enough to start.

Project brief
Case studies
Email
contact@elastoapps.com
Studio
Cluj-Napoca, Romania, EU