MDU

MDU protocol for MORSE

1. Introduction

The Multi-Detector Unit protocol has been designed by Nederland
Haarlem company. This protocol is used for communication of intelligent
traffic signs with the centre.

Important

The terminology is unified from Setr version 9.0.17.0 according
next schedule:

PLC Master - CU RADIOSLAVE ... CU RADIOMASTER - Slave PLC

CU (radiomodem) connected via SCC to PLC Master is called
Radioslave (RS), CU connected to PLC Slave is called
Radiomaster (RM). Changes appear at a new Setr version,
the firmware version has not influence.

The older Setr uses different terminology, also:

( PLC Master - CU MASTER ... CU SLAVE - Slave PLC )

Communication in the network with this equipment is always of the
Master- Slave variety. The network can have many masters, and one slave
can be subordinate to several masters. Due to this reason, the access
module for this protocol is implemented in the MORSE system in such the
manner, that the slave always answers to the address of the master which
has sent the request.

Broadcast packets (destination address 00) are not supported. These
packets are discarded.

3. Implementation in MORSE

External device – Morse Communication Unit (CU)

The frame length must be greater than or equal to 9 bytes
(minimum packet size, only header and tail, no data)

STX is E3h

VER is 01h

The actual packet length must be greater than or equal to length
filled in header + 6 (header length) + 2 (crc)

Address is not 00h (broadcast)

Header checksum is O.K.

CRC is O.K.

If all the above checks passed O.K., the packet is delivered into
the Morse system. As the destination and source addresses are in the
header of the Morse packet and the 32-bit CRC is used for data error
checking within the Morse system, only the message type and data are
transfered within the inner Morse packet.

The MDU protocol access module uses the following algorithms for
frame completing/fragmentation:

When the CU finds the STX byte in the received frame, it tries to
find the end of the frame on the basis of information about length in the
header, or alternatively ETX.

1.If the actual length of the frame is greater than the expected
length, the frame is split into 2 frames and these are processed
separately. <li> 2.If the actual length of the frame is less than
the expected length, the MCU waits for the next part of the frame. The MCU
joins incoming frames until the length of the joined frame is equal to or
greater than the expected length.

If the actual length of the frame is greater than the expected
length, the frame is split into 2 frames and these are processed
separately.

If the actual length of the frame is less than the expected
length, the MCU waits for the next part of the frame. The MCU joins
incoming frames until the length of the joined frame is equal to or
greater than the expected length.

CU – External device

The MDU protocol access module simply amends the Morse packet data
received with the MDU header and tail following the above rules. The
complete frame is then transmitted immediately to the External
device.

Flow control

No software handshake is used within the MDU protocol link layer. If
all buffers in the CU are full, there is no way to inform the device
connected. So any packet which may arrive in this situation is silently
discarded. To avoid this a hardware handshake (RTS/CTS) can be used.
Nevertheless the probability that the MDU master will overload the network
is negligible, assuming normal behaviour of the system.

Waiting timeout for the next frame fragment. If the next part
of the frame does not come within this time, the previous part is
discarded.

If this timeout is set to 0, the fragmentation algorithm is
switched off and every frame is considered to be a complete packet,
i.e. discarded when it is not complete.

5. Debugging messages

When you configure the (D)ebugging level in the SCC to 1, you can
get the debugging messages as follows. The messages are sent to the
service destination address (see menu Unit ), default 2nd SCC.

"Ch_in problem: PACKET TOO SHORT:%hu"
- The frame length must be greater than or equal to 9 bytes
(minimum packet size, only header and tail, no data)
"Ch_in problem: NO SYNC BYTE %02Xh"
- There is no STX (E3h) in the packet
"Ch_in problem: VERSION !01:%Xh"
- sw version (2nd byte in the header) is not 01h
"Ch_in problem: PACK LENGTH: %hu(%Xh), INC. PACKET LEN:%hu(%Xh)",
- The real length of the incoming packet is shorter then the length
which is filled in in the header of the packet
"Ch_in problem: MDU_BROADCAST_ADR 00h"
- destination address is 00h, packet is discarded.
If master - address 00h is filled in the header;
if slave - master's address not known (no request from
the master before).
"Ch_in problem: INC. HCHK: %02Xh, CALC. HCHK:%02Xh"
- calculated header checksum is not equal to header checksum
in the header of the packet
"Ch_in problem: INC. DCHK: %Xh, CALC. DCHK:%Xh"
- calculated CRC data is not equal to CRC in the tail of the packet
"m_user_in: INC. PACKET TOO SHORT:%hu"
- incoming packet from Morse transport channel is shorter
than 1 byte (msgtyp)
"Waits %hums for next part of packet"
- Information, that the Morse system waits ..ms for the next fragment
of the packet
"No packet joining"
- Information, that the Morse system does not wait for the next
fragment of the packet (timeout=0)
"Join packet problem: Timeout for next fragment expired"
- Information, that timeout for the next fragment expired. All current
income fragments are discarded