Serial-to-Ethernet and Cellular DTU Adaptation | 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 this ESP32-S3 serial-to-Ethernet and cellular DTU project after completing requirements definition, contract scoping, hardware and software design, and physical testing. The engineering focus was carrying RS485 device data to an agreed IP destination while keeping Ethernet, Wi-Fi and cellular implementation choices explicit.
Scoping the device-to-server connection
The project was organised around the source serial data and its destination, rather than treating network connectors as interchangeable. The agreed customer requirements defined the DTU connection task; the contract then bounded the hardware and firmware work needed for delivery.
The documented architecture provides different uplink directions: W5500 Ethernet over SPI, the ESP32-S3 Wi-Fi radio, and an ML307R Cat.1 modem controlled through AT commands. A selected TCP, UDP, HTTP or MQTT integration has its own session and data-handling requirements.
Developing the hardware and firmware together
Obeita completed the hardware and software work within that agreed scope. The technical design connects the serial forwarding task to the selected network path, programming access and supply arrangement. CH340C with an automatic download circuit provides a documented development entry point; ESP-IDF, Arduino and MicroPython remain possible framework choices rather than simultaneous delivered environments.
The published power architecture includes USB development power and a TPS54331-based field-input path. RS485 wiring includes TVS protection and selectable termination. For a similar cellular design, the power budget must account for both modem start-up demand and transmit peaks. The ML307R’s 1.8 V UART is not directly compatible with 3.3 V MCU logic; correct modem supply voltage does not establish UART compatibility.
Keeping optional link behaviour explicit
The presence of alternative uplinks does not define automatic failover. A new project requiring link switching needs agreed priorities, timeouts, session restoration and treatment of unsent data. Likewise, powering an external instrument from a field terminal requires confirmation of the actual pin assignment, available voltage and current, and grounding.
Documented architecture and configuration
The table records the documented architecture, configuration directions and selection boundaries for this case. Optional items, firmware-dependent choices and expansion directions are not independent guarantees that every listed option was delivered. The agreed project hardware, software and functional scope define the actual delivery.
| Item | Configuration |
|---|---|
| Controller | ESP32-S3 |
| Ethernet | W5500 over SPI; RJ45 |
| Cellular option | ML307R Cat.1; region/carrier compatibility review |
| RS485 | TVS; selectable 120 Ω termination |
| Programming | USB / CH340C / automatic download |
| Power paths | USB 5 V or 12–24 V DC design |
Delivery outcome and test scope
The contracted DTU hardware and software were completed and delivered. Physical functional testing confirmed that the delivered project satisfied the customer’s requirements.
This outcome applies to the selected project configuration and functions. It does not claim that every uplink, software framework or application protocol was delivered together, or establish automatic failover or universal carrier compatibility.
Discuss a similar project
Send Obeita representative RS485 frames, the destination IP service or API, deployment country, supply arrangement and any required fallback behaviour. These details define a comparable DTU project without assuming that optional links share the same firmware behaviour.