Multi-protocol gateways sitting between local sensors or controllers and the network, with custom gateway development where the sensor set, protocol mix or environment does not match anything off a shelf. On industrial sites, that is most of the time.
A gateway does more than forward data. It translates between protocols that were never designed to meet, buffers when the uplink drops so an outage costs latency rather than data, filters and aggregates so the connection carries information rather than raw samples, and acts as a single managed boundary between an operational network and everything outside it.
Standard units cover the common cases. The awkward cases are the norm on real sites: a legacy serial protocol nobody documents, an unusual power arrangement, a hazardous-area classification, an enclosure constraint, or a radio combination that is not sold as a bundle.
Custom gateway development starts from those actual requirements rather than from a reference design, and covers hardware, firmware, certification path and the device-management integration that makes a fleet of them supportable.
| Parameter | Detail |
|---|---|
| Function | Protocol translation, buffering, edge processing and network boundary |
| Industrial protocols | Modbus, OPC UA and common fieldbuses |
| Uplink protocols | MQTT, MQTT-SN, CoAP and HTTP |
| Short-range mesh | Thread border router, Zigbee, BLE, and Matter over Thread or Ethernet |
| Buffering | Store and forward, so an outage costs latency rather than data |
| Edge processing | Filtering, aggregation and thresholding before uplink |
| Concurrent multiprotocol | Thread and BLE time-sliced on one 802.15.4 radio where the design permits |
| Custom development | Hardware, firmware, certification and device management |
| Typical markets | Industrial, smart building, utilities, infrastructure |
Maturity — silicon-proven, FPGA-validated or RTL stage — is confirmed at enquiry for the specific configuration you need, rather than claimed generically here.
Send the target node, the interface requirements and the integration context. If this is not the right fit, that will be said early rather than discovered at integration.
Thread is supported in the border router role, bridging an IPv6 802.15.4 mesh to the IP network, with Matter carried over Thread or Ethernet where an application needs it. Zigbee and BLE are supported alongside, subject to the radio and coexistence constraints below.
They share the 2.4 GHz band and, in most designs, a single 802.15.4-capable radio — so concurrent operation is achieved by time-slicing rather than by true simultaneity. Whether that is acceptable depends on the latency and throughput each protocol needs, and it is established at design rather than assumed.
It translates between local device protocols and network protocols, buffers data when connectivity drops, applies local filtering or processing, and provides a single managed boundary between an operational network and the outside.
When the sensor set, protocol mix, power arrangement, enclosure constraint or hazardous-area classification does not match a standard unit — which on industrial sites is the normal case rather than the exception.
Modbus, OPC UA and common fieldbuses on the industrial side, with MQTT, MQTT-SN, CoAP and HTTP on the uplink side. Proprietary and legacy serial protocols are handled in custom developments.
Tell us the specification, the constraint and the deadline. Programmes that cross silicon, radio, embedded and AI are where Faststream is strongest.