Testing the Perle IOLAN SDS1M for use in a DNP3 radio network


For a master station upgrade, a device/terminal server is required to interface a number of radios and RTUs to the master station.  The handshaking with the radios requires precise timing of RTS/CTS lines, and so a Perle IOLAN SDS1M was obtained for testing, with the intention to purchase a SDS-16C provided that the testing demonstrated that it would be suitable.

Testing Setup

The master station software installed on a laptop is connected to a radio in one of two ways:

  1. Directly via a serial cable
  2. Via an Ethernet cable to the SDS1M which is in turn connected to the radio.

A second radio is connected to a Foxboro SCD5200 RTU.  The master station can be configured to poll the RTU via one of three communication channels:

  1. Via a hardware serial port on the laptop
  2. Via a TruePort virtual serial port and through the SDS1M (uses Ethernet)
  3. Via Ethernet, and then through the SDS1M

Handshaking requirements for the radios

RTS/CTS handshaking is used to key the radios and works as follows:

  1. The DTE (Master station or RTU) raises RTS when it wishes to transmit data.
  2. The radio (DCE) raises CTS when it is ready to receive data.
  3. The DTE waits for CTS to be asserted by the radio, or waits a pretransmission time (PTM), and then starts transmitting data.  An appropriate PTM for these radios is 80+ms.
  4. The data finishes transmitting and the DTE drops RTS immediately.


All oscilloscope captures are on a 100ms time base, unless otherwise specified.

All serial ports are set to 9600/N/8/1/No Parity

RTU serial V28 port

PTM – 100ms

Squelch – 20ms

Master station COM1 (hardware serial port)

PTM – 100ms

RTS Warm down time – 1ms

Master station COM3 (TruePort serial port)

PTM – 100ms

RTS Warm down time – 1ms

Connection Profile – “Optimise Network Throughput”

Test 1 – Attempting communication with the RTU via Ethernet

This test was not able to be completed as the SDS1M does not appear to support the correct handshaking required by the radio.  The hardware flow control setting simply keeps RTS high all the time.  However using a microcapp device to perform the handshaking produced satisfactory results (with no flow control set in the SDS1M).

Test 2 – Attempting communication with the RTU via a hardware serial port

This test was completed successfully without any problems.  Figure 1 below shows three scope captures of the RTS lines of both radios.  Note that there is no occasion in which both RTS lines are high (this would mean both radios are attempting to transmit at the same time).  The master station RTS signal is on the bottom, and the RTU RTS signal is on top.

sds1m-2 sds1m-1 sds1m-3

Figure 1 RTS lines of both radios

 The scope captures below in Figure 2 show the RTS off delay – the time between the last data being transmitted and the RTS signal going low.  It is important that this time is as close to zero as possible, as the responding RTU can raise RTS on its radio in as little as 10ms from the time it receives data and the two radios must not be transmitting at the same time.  Figure 2 shows just that; RTS goes low immediately following the Tx data.

 sds1m-4 sds1m-5 sds1m-6

Figure 2 RTS off delay (RTS on top, TXD bottom)

Test 3 – Attempting to communicate with the RTU via the TruePort virtual serial port

This test produced mixed results.  Communication was established with the RTU, but it was not at all consistent.  Some reply packets of data coming back from the RTU appeared to have the start of the packet missing (short packets that did not start with the 0564 DNP signature).  At other times the RTU did not respond at all.  One plausible theory was that the RTS signal was not always being set low immediately following the Tx Data, rather it was occasionally set low slightly after or before the Tx Data, which would cause either the master station transmission to be cut short, or the start of the RTUs reply cut off respectively.

Figure 3 shows four oscilloscope captures of the two RTS lines, with the master station RTS signal on bottom and the RTU RTS signal on top.  Note that in three of the captures the master station RTS line is clearly still high when the RTU has set its RTS signal high.  The fourth is very border line.  Note that the master station does not reply (acknowledge) these RTU replies, as the data packet is incomplete.

 sds1m-7 sds1m-8 sds1m-10 sds1m-9

Figure 3  RTU RTS on top, Master RTS on bottom

In Figure 4, the RTS off delay is shown (master station RTS signal on top, master station Tx on bottom), and in three of the images there is clearly a gap between the time that the Tx data is transmitted and RTS going low.  This is in the region of 10-40ms, whereas in fig. 2 times are all sub-10ms.  In the first image it can be clearly seen that RTS is set low before all the data is transmitted.  This will likely cause the radio to truncate this transmission.  From observing many other scope captures, the time for RTS to go low after the data has been transmitted can vary in the range +/- 40ms.  This time should be very close to 0ms, and should certainly not be negative.

 sds1m-14 sds1m-13 sds1m-12 sds1m-11

Figure 4 RTS off delay


Ideally we would use the TCP Sockets mode of the IOLAN SDS, and have it do the flow control.  However as this is not possible, the TCP Sockets mode with no flow control combined with a microcapp will perform adequately.  Only one radio attached to the master station requires handshaking, with all the others being dedicated links and so do not need flow control anyway.  Incidentally, the microcapp website describes the same problems with RTS/CTS flow control as was encountered while testing the SDS1M.


Microcapp http://www.dcitech.com/microcap.htm

| February 1st, 2011 | Posted in SCADA |

Leave a Reply