Multi-interface IoT Gateway Integration | Obeita
Delivered project. The completed hardware and software met the customer’s agreed requirements in testing. Specifications for a new project must be agreed separately.
Obeita delivered a multi-interface IoT gateway project built around STM32F407. The project connected field acquisition with a defined software data path, progressing from customer requirements and contract confirmation through hardware/software design, physical testing and delivery.
A gateway scope built around device identity
The integration problem was to handle RS485 and local sub-GHz radio traffic while keeping the originating device and command destination clear. Obeita’s hardware and software work addressed the agreed gateway scope. The documented architecture separates collection, validation, cloud adaptation and management so the field connection and server connection have distinct responsibilities.
Modbus RTU and radio-node messages use different acquisition paths. Their data model needs to retain device identity through parsing and upload, while a downstream message needs an agreed address and routing rule. This message handling is the technical focus of the case; adding another physical interface alone does not define how a server can control the connected equipment.
Network settings and gateway management
The public design includes Ethernet, Cat.1 and Wi-Fi uplink options and a host configuration tool for network and cloud parameters. Software design connects configuration data with the gateway’s operating behavior. Storage and recovery of settings, cloud registration fields and command acknowledgements belong to that definition. OTA is documented within the management scope, with image checking and interrupted-update recovery requiring an implementation appropriate to the selected firmware.
Power domains and field-interface protection
The hardware architecture separates the 6–28 V input, a 5 V intermediate stage, separate 3.3 V logic and peripheral supplies, and a 3.9 V cellular rail. The documented RS485 path combines SP3072EEN transceivers, TVS devices and gas-discharge protection. These component choices describe how protection is approached in the circuit. An assembled-product surge claim requires a defined waveform, wiring arrangement and product-level test report; the component list alone does not establish that rating.
Documented architecture and configuration
This table records the project’s documented architecture and selection boundaries. Options, variants and design inputs remain qualified as shown; their inclusion here is not an independent guarantee that every option formed part of the delivered configuration.
| Item | Configuration |
|---|---|
| MCU | STM32F407VET6, Cortex-M4 |
| Field acquisition | 2 × RS485; Modbus RTU; sub-GHz/LoRa path |
| Uplinks | Ethernet, Cat.1, Wi-Fi options |
| Input design | 6–28 V with reverse-polarity/protection circuitry |
| Configuration | Host tool for network and cloud parameters |
| Management scope | Data validation, downstream commands and OTA |
Delivered gateway and verified project outcome
Obeita delivered the agreed gateway hardware and software after completing physical testing. The tested functions met the customer’s requirements. The outcome covers the contracted project configuration; it does not publish a throughput figure, an immunity level or a guarantee that every listed uplink option was delivered together.
For a new installation, the field topology, device-address model, cloud message contract and update/recovery requirements should be settled together. Protection requirements also need to reflect the wiring and installation environment rather than being inferred from individual components.
Scope a similar multi-interface gateway
Send Obeita your RS485 and radio-node topology, protocol details, server message format and installation protection requirements. We can use them to define a gateway development and physical-test scope around the equipment you need to connect.