Custom gateway and telemetry development
For requirements that no catalogue product meets, we design and deliver the device — specification through to field-supported production.
Where this is the right approach
Off-the-shelf gateways assume a conventional site: mains power, a network, a common protocol, an ordinary enclosure. Industrial requirements routinely violate one of those assumptions, and the resulting device either does not exist or exists only as an expensive import with a support chain measured in weeks.
We take on those cases. Typical drivers are a power budget that rules out conventional hardware, a protocol or meter that standard products do not handle, certification or sourcing constraints that demand a domestic supplier, or a volume too low to interest a large vendor.
Capability
| Field protocols | Modbus RTU and TCP; BACnet; CAN and J1939. Reading installed equipment on the protocol it already speaks. |
|---|---|
| Connectivity | Cellular (4G LTE) including SMS control paths, Ethernet, and store-and-forward buffering for sites where the link is intermittent rather than reliable. |
| Low-power design | Battery-operated devices with multi-year service intervals. Delivered designs reach single-digit microamp sleep current while remaining field-configurable. |
| Verification | Host-side regression suites, instrumented bench soaks, and captured evidence rather than demonstration. |
Delivered work
The following were engineered and delivered for customers. They remain their products; described here is the engineering, not a catalogue.
| Battery flowmeter gateways | Cellular telemetry from water flowmeters across three meter types, operating unattended on battery power with a long reporting interval. |
|---|---|
| Digital water level recorder | Cellular DWLR for remote water-level monitoring, built to the same low-power discipline: multi-year unattended operation without mains supply. |
| Environmental monitoring unit | Ammonia, humidity and temperature monitoring for a customer's hygiene-monitoring product. |
| Medical device | A CO₂ insufflator for laparoscopic surgery, developed to a customer's specification. Noted here as a measure of the range and rigour of work undertaken. |
Customer names are withheld pending their consent.
What a project inherits
Development does not begin at an empty repository. Several years of work has produced a component base that is already proven in deployed devices:
| Cellular | A modem control library covering the full lifecycle — power sequencing, network registration, data sessions, MQTT and HTTP, SMS, and recovery from an unresponsive modem. |
|---|---|
| Field protocols | Modbus RTU and Modbus TCP implementations, with the framing, timing and error-recovery behaviour that real buses require rather than what the specification alone implies. |
| Storage and buffering | SPI flash drivers, crash-safe configuration persistence, and store-and-forward buffering that survives power loss mid-write. |
| System patterns | Watchdog-safe task structures, liveness supervision, and status reporting designed to remain truthful under failure. |
Each carries its own regression suite and version history, and each is pinned per product so a device's exact component versions are recorded rather than inferred.
Platform independence is the multiplier
These libraries are written to be independent of the hardware beneath them. The same cellular or Modbus implementation compiles and runs against a desktop harness on Windows or Linux and on the target microcontroller, with only a thin porting layer between. Three consequences follow, and all three reach your project:
- Behaviour is verified before hardware exists. Protocol logic is exercised on a workstation, in seconds, against fault injection that is impractical to reproduce on a bench.
- Your project is not tied to one microcontroller. If cost, availability or a certification requirement forces a change of part, the protocol work moves with it.
- New code is confined to integration. The bulk of the firmware has already been run for months in deployed devices.
The commercial effect is a shorter schedule. The engineering effect matters more: the device reaches the field carrying fixes for failures it has not yet experienced, because those failures were already found and closed elsewhere.
How a project runs
| Requirements | What must be measured, the site's power and network conditions, where the data must arrive, and the constraints that are not negotiable. |
|---|---|
| Design | Hardware platform, protocol stack and power budget, documented before implementation begins. |
| Implementation | Assembly from existing libraries; new development limited to the integration layer. |
| Verification | Host-side suites, then extended soak runs on target hardware with captured evidence. |
| Field | Pilot deployment, then production and ongoing support. |
Engineering automation
A substantial part of our engineering process is automated: regression execution, evidence capture, documentation consistency checks, and the product video manuals published on this site. This is a deliberate operating model rather than a novelty. It allows a small organisation to hold a verification standard normally associated with much larger teams, and it is why a modest project can be quoted without reducing the testing that goes into it.