Industrial connectivity, engineered to be depended on.
ConnectLinks designs and builds gateways that connect industrial equipment to the systems that need its data — and takes on custom development for companies whose requirements do not fit a catalogue product.
What we do
Industrial plant is long-lived. Meters, drives, controllers and building systems installed a decade ago still run well, still speak Modbus or BACnet, and are rarely worth replacing simply to make them visible. The gap is connectivity, not equipment.
We close that gap. Our gateways read installed equipment on its own protocols and deliver its data to wherever it is needed — a cloud platform, a control room, or an existing building management system — over Ethernet or cellular, at sites that may have neither reliable internet nor mains power.
How we approach it
Constraints first
Industrial deployments fail on the things that are easy to postpone: what happens when the network drops for six hours, when the modem stops responding, when power is interrupted mid-write, when a device on the bus goes quiet. We design for those conditions from the outset, because they are the normal operating environment rather than exceptions.
Proven components, not fresh code
Each product is assembled from libraries that carry their own regression suites and version history — protocol stacks, modem control, storage, buffering, watchdog-safe task patterns. New work is confined to the integration layer. A product therefore inherits fixes for problems it has not yet encountered, and reaches the field with fewer of them.
Evidence over assertion
Behaviour is verified on hardware and measured, not assumed. Where a figure appears in our documentation it comes from a run: a soak duration, a sample count, an observed cadence. Where something is unproven, it is marked unproven — including on this website, where products in development carry their real status and unvalidated device counts are not quoted.
Background
ConnectLinks was founded by an engineer with more than thirty years across research and development and IT services. The engineering foundation is protocol work: seven years through the 1980s developing the networking stack for an indigenously built X.25 packet switch and PAD — public data networking at a time when the personal computer itself was still new, and when a protocol stack was implemented from the specification rather than assembled from existing libraries.
That equipment did what an IoT gateway does now: translate between a serial device and a packet network, and hold data the link cannot yet carry. The transports have changed completely; the engineering problem has not.
Two decades in IT services followed, managing delivery of e-commerce and web technology programmes. That period established the delivery practice the company runs on: how work is scoped, how commitments are made, and what separates a system a customer can depend on from one that merely demonstrates well.
Recent work returns to embedded systems and protocol engineering: firmware, connectivity stacks and the field devices they run on. Cellular telemetry units, battery-powered loggers operating for years at single-digit microamp sleep current, and protocol gateways — delivered as turnkey projects for customers in water, environmental monitoring and medical equipment. Those projects are the foundation our own product range is built on.
Where the company is today
Custom development is our current business. Most of our work is designing and delivering connectivity and telemetry devices for customers whose requirements no catalogue product meets — and it is available now, while our own product range is still in development.
What makes that commercially viable at our scale is that projects are not written from scratch. Several years of work has produced a set of libraries that are already proven in deployed devices: cellular modem control, Modbus RTU and TCP stacks, Ethernet and flash storage drivers, store-and-forward buffering, and configuration persistence. Each carries its own regression suite and version history.
Those libraries are deliberately platform-independent. The same cellular or Modbus implementation compiles and runs against a desktop test harness on Windows or Linux and on the target hardware itself, with only a thin porting layer beneath it. The practical consequences are direct: behaviour is verified on a workstation long before hardware exists, a customer's project is not tied to a single microcontroller, and new development is confined to the integration specific to their requirement.
The result is a shorter schedule and, more importantly, a device that reaches the field carrying fixes for failures it has not yet encountered — because those failures were already found and closed on someone else's bench.
Our own product range remains in active development. Specifications are preliminary and nothing is on sale yet; we publish development status honestly rather than announcing dates we cannot stand behind.