IoT, embedded systems and video surveillance
We design systems that connect computing to the physical world: firmware for microcontrollers, gateways and kiosks on Raspberry Pi, integration of inverters, cameras and smart devices even without the cloud, video and audio analysis, small robots.
Part of this work starts in our in-house lab: prototypes that actually run, every day, measured and documented, which help us understand a technology before we take it to a client. The status of each example shows which are prototypes and which are delivered work.
Firmware for ESP32 and I/O boards
We write C++ firmware for ESP32-S3 boards with opto-isolated inputs and relays: state machines, REST APIs, MQTT, a web dashboard served by the board itself, over-the-air (OTA) updates and remote access without opening ports on the router.
Technologies and products
- ESP32-S3
- PlatformIO and ESP-IDF 5
- I²C and SPI
- MQTT, REST, WebSocket
- OTA
One example
-
In-house lab Prototype
Two power sources that must never touch
- The problem
- Switching loads between the grid and the photovoltaic (PV) system without the two sources ever running in parallel.
- What we did
- A board with 8 inputs and 8 relays drives two contactors that are also mechanically interlocked, with a 15-minute stability timer, manual operation as the starting state and a return to manual after a loss of PV. Remote access goes through an outbound WebSocket tunnel: we tried WireGuard on the board and rejected it.
- Where we have got to
- In continuous operation since May 2026; a twin board for the heating, stuck in a boot loop caused by a rare chip revision, started up again with a different bootloader.
Inverters, batteries and serial buses
We integrate power equipment through its documented protocols and, where documentation is missing, we reconstruct them by measuring: a multimeter on the pins, passive listening on the bus with CRC checks, tests at several speeds. We do not touch a working original component until the alternative has been validated.
Technologies and products
- RS-232 and RS-485
- Modbus RTU
- pyserial
- Raspberry Pi
Examples
-
In-house lab In progress
A “USB” port that was an RS-232 serial port
- The problem
- An inverter’s service port, marked as USB, did not respond to any test.
- What we did
- Four failed attempts (USB device, USB host, TTL serial, data cable), then the multimeter: −5 V at idle on the data wire, meaning three-wire RS-232. On the RS-485 bus between inverter and battery, passive listening with Modbus CRC validation showed that the inverter polls 14 addresses with a proprietary function.
- Where we have got to
- Test bench defined and decoder ready, based on the manufacturer’s register map; direct communication is still in progress.
-
In-house lab Prototype
A manufacturer's cloud made stable
- The problem
- Pending direct communication, the data came from the manufacturer’s cloud, which kept expiring the session (127 logins in two hours) and renaming fields.
- What we did
- Token-based authentication and tolerant parsing, flagging fields that have disappeared instead of showing a wrong value.
- Where we have got to
- Zero new logins in nine minutes of testing and no battery shown “at 0%” because of a renamed field.
Smart devices without depending on the cloud
We bring devices designed for apps and the cloud onto the local network, with our own APIs, and make them reachable remotely through outbound tunnels, without opening inbound ports.
Technologies and products
- Tuya local protocol
- eWeLink OAuth2
- autossh
- aiohttp and systemd
One example
-
In-house lab Prototype
Cloud quota used up in two days
- The problem
- The devices’ free cloud quota ran out in two days, at around 26,000 calls a day.
- What we did
- Batched reads with a monthly cap and a service on Raspberry Pi that uses the local protocol, with one open connection per device; the cloud stays as a fallback.
- Where we have got to
- Four devices read and controlled locally, 24 out of 24 acceptance tests passed, six out of six commands from the dashboard.
Kiosks and video walls on Raspberry Pi
We use Raspberry Pi boards as full-screen terminals: an image configured by script at first boot, a browser in kiosk mode under systemd, a watchdog that reloads the page, diagnostics of the video output and the power supply.
Technologies and products
- Raspberry Pi and Raspberry Pi OS
- Chromium in kiosk mode
- Xorg and systemd
- vcgencmd
One example
-
In-house lab Prototype
An information wall and the limit of the GPU
- The problem
- A Raspberry Pi 3 had to display a portal at 1920×1080, but the browser was stuck on a version that was too old.
- What we did
- Reinstallation with the current operating system and an up-to-date Chromium; a black screen at boot fixed by changing the video driver; 15 voltage drops in 26 minutes eliminated with a UPS.
- Where we have got to
- A working wall and a written requirement: the Pi 3 GPU supports up to WebGL 1, so interactive maps need a Pi 4 or 5.
IP cameras, DVRs and video streams
We republish cameras and recorders, even old or closed ones, as standard streams; we size frame rate and transport to the actual bandwidth.
Technologies and products
- RTSP and HLS
- H.264 and HEVC
- ffmpeg and mediamtx
- Manufacturer SDKs
- GStreamer
Examples
-
In-house lab Prototype
A DVR without RTSP, republished as a standard stream
- The problem
- A 4-channel analogue DVR offered no RTSP, ONVIF or web interface.
- What we did
- Using the manufacturer’s SDK we found that the proprietary stream contains MPEG-PS with H.264 video: we copied it with ffmpeg, without re-encoding, to an RTSP server.
- Where we have got to
- Four channels available over standard RTSP (704×576, about 25 frames per second).
-
In-house lab Prototype
Video latency of up to 27 seconds, brought down to 1.5
- The problem
- Three 4K cameras and a video intercom over VPN arrived with 14-27 seconds of latency, and the intercom’s video arrived broken up.
- What we did
- 10 frames per second at the source, keeping the same resolution, and a direct connection instead of the relay; for the intercom, UDP with a reordering queue.
- Where we have got to
- On the camera we measured, 10 frames out of 10 read with 1.5 seconds of latency; H.264 errors on the intercom down from about 1,600 to 18 every three minutes. The limit then became the upload bandwidth, measured at about 11 Mbit/s.
Video and audio analysis
Detection and tracking of people, vehicles and animals on every frame, autonomous control of motorised cameras, number plate reading and acoustic recognition of sirens, with a portal of notifications that the operator can dispute. We also fix the open-source components we use: a patch of ours to the video bridge stopped a leak of 2,400 file descriptors and 80 MB a minute per client.
Technologies and products
- YOLO11 and ByteTrack
- OpenCV
- ONNX
- FastAPI
- MQTT and SQLite
Examples
-
In-house lab Prototype
A dark car against the light, from invisible to visible
- The problem
- The smallest model could not see a dark car against the light.
- What we did
- Measurement-based choice of model and per-class thresholds (person 0.50, vehicle 0.35, animal 0.45); inference moved to a dedicated machine.
- Where we have got to
- From 0 to 205 detections on 205 frames; inference on a 4K frame fell from 1,350 to 24 ms.
-
In-house lab Prototype
Sirens recognised without neural networks
- The problem
- Recognising a siren in ambient noise without false alarms.
- What we did
- A rule on the spectrum: the tone must rise at least 40 dB above the background of its band for at least 8 seconds. We tested it with synthetic sirens mixed into 12.5 minutes of real audio.
- Where we have got to
- Zero false alarms and the siren recognised in 8 seconds.
Mobile robotics
We turn robot kits into mobile nodes that can be controlled over the network: ESP32 firmware with token-based APIs and over-the-air updates, small patches to the on-board microcontrollers, test benches and simulators. We verify movements on the camera frames, not on the command sent.
Technologies and products
- Arduino (AVR) and ESP32
- avrdude and esptool
- MPU6050 gyroscope
- WebSocket and OTA
One example
-
In-house lab Prototype
A rover that kept switching itself off
- The problem
- The factory firmware did not report the battery status (the rover switched off without warning) and left the motors running if the command was interrupted.
- What we did
- New firmware on the ESP32 and a patch to the on-board microcontroller, with the flash memory 98% full: battery reading, shutdown below 6.5 V, a one-second watchdog, gyroscope-guided rotation.
- Where we have got to
- 13 out of 13 acceptance tests passed; a commanded 90° rotation measured at 86.4°.
Radio spectrum measurements (SDR)
We measure the spectrum and channel occupancy with low-cost SDR receivers, separating real signals from instrument artefacts.
Technologies and products
- RTL-SDR
- rtl_power and rtl_tcp
- numpy and scipy
One example
-
In-house lab Prototype
Twenty-five transmitters that did not exist
- The problem
- A wide scan of the spectrum “found” 25 non-existent transmitters.
- What we did
- They were the receiver’s gain curve: comparison with a local moving median and an estimated crystal error, with a stated repeatability of ±3 ppm.
- Where we have got to
- A reliable measurement bench, with its limits written down.
SCADA and industrial systems
Remote support for SCADA and HMI systems: analysis of the diagnostics, an architecture map, runbooks and checklists for restarts.
Technologies and products
- FactoryTalk View SE and FactoryTalk Linx
- Allen-Bradley ControlLogix and CompactLogix PLCs
- EtherNet/IP
- SQL Server Express
- PowerShell and WinRM
One example
-
Industrial plant Delivered
An HMI stuck after a blackout, because of a switched-off PC
- The problem
- After a blackout the HMI froze at every start-up; about ten restarts had not helped.
- What we did
- We analysed about 21,000 diagnostic records with a script and documented the exclusion of the other causes: two byte-for-byte identical copies of the project, all PLCs reachable, licences and databases in order. The cause: a PC hosting a server of the distributed system had stayed switched off.
- Result
- Once the PC was switched back on, the HMI started up again. We delivered the incident report, the system fact sheet, the runbook and a checklist for restarts after a blackout.