Sierra Wireless DART 300 User Manual
User’s Guide
UDP/TCP Service
2110212 Rev 1.0
Page 73
8.4. Sample UDP/TCP Configurations
These are actual sample cases. They are provided as a guideline to aid your configuration
planning.
planning.
8.4.1.
Case 1 – Semi-intelligent RTU
The host device is a Remote Terminal Unit (RTU) designed for industrial control and monitoring
applications.
applications.
It provides an ASCII user interface, terminating lines with <LF><CR>. The unit can accept
single characters as commands; responding to unrecognized characters with a single prompt line
showing the valid command characters. The device cannot issue AT commands, and cannot
process modem result codes. The messages from the device do not contain the characters “AT” in
sequence so its messages will not be processed by the modem’s command state processor.
single characters as commands; responding to unrecognized characters with a single prompt line
showing the valid command characters. The device cannot issue AT commands, and cannot
process modem result codes. The messages from the device do not contain the characters “AT” in
sequence so its messages will not be processed by the modem’s command state processor.
The device will generate a message whenever an input value changes. These messages are
unsolicited status reports. The device can also issue status reports on request.
unsolicited status reports. The device can also issue status reports on request.
This situation suggests that the device should be configured as a UDP server, without a session
timeout, and with the Server Receive Lock enabled. The device will remain in an open session,
sending unsolicited status to the last calling client. The Server Receive Lock allows the user to
change monitoring systems (clients) if needed, or to call the device from multiple systems.
timeout, and with the Server Receive Lock enabled. The device will remain in an open session,
sending unsolicited status to the last calling client. The Server Receive Lock allows the user to
change monitoring systems (clients) if needed, or to call the device from multiple systems.
Other configurations are possible, including closed sessions, since the unsolicited messages from
the RTU are harmless to the modem’s command processor.
the RTU are harmless to the modem’s command processor.
Cabling
The RTU is configured as DTE meaning that it is designed to connect directly to a modem.
However, the unit does not support bi-directional flow control using RTS/CTS. It uses the
outmoded application of RTS, only asserting RTS when it wants to transmit. The DART 300 will
not send the device any data unless RTS is active; an indication to the DART that the local host is
ready to receive. The RTU can operate using only Rx, Tx, and GND.
However, the unit does not support bi-directional flow control using RTS/CTS. It uses the
outmoded application of RTS, only asserting RTS when it wants to transmit. The DART 300 will
not send the device any data unless RTS is active; an indication to the DART that the local host is
ready to receive. The RTU can operate using only Rx, Tx, and GND.
To use the RTU with the DART 300, the DART must see asserted RTS and DTR signals. This
cable will assert both of these.
cable will assert both of these.
The cable’s DCE end has a male connector and plugs into the modem. The DTE end has a female
connector on the cable and plugs into the RTU.
connector on the cable and plugs into the RTU.
DCE (male)
DTE
(female)
1 DCD
Not Connected
1 DCD
2 RxD
2 RxD
3 TxD
3 TxD
4 DTR
4 DTR
5 GND
5 GND
6 DSR
6 DSR
7 RTS
7 RTS
8 CTS
Not Connected
8 CTS
9 RI
Not Connected
9 RI
Figure 8-1: Cable Without DTE-DCE Flow Control.
Rx, Tx, and GND are straight through (DTE to DCE). The modem’s DSR is tied back to RTS and
DTR to assert these two control signals that RTU does not provide.
DTR to assert these two control signals that RTU does not provide.