MDU

https//www.racom.eu/eng/support/prot/mdu/index.html

Print version

MDU protocol for MORSE

verze 9.0.17.0

8/7/2007

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]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.

2. Data Format

All packets in the MDU protocol are characterized by this structure:

| STX/8 | VER/8 | LENGTH/16 | ADDRESS/8 | HCHK/8 | MSGTYPE/8 |
   E3      01      00 05         33        1C         B1

|  DATA/8*N   | CRC/16 |
  00 04 47 BA    98 8F
STX

beginning of packet (sync byte) 0xE3

VER

version of protocol (always 0x01)

LENGTH

message length (MSGTYPE + DATA only), 2 bytes Motorola format

ADR

slave’s address, i.e. slave fills in its own address
00 – broadcast (packet discarded)

HCHK

header checksum (sum of STX+VER+LENGTH+ADDRESS)

MSGTYPE

message type

DATA

sequence of data bytes

CRC

CRC16 of message type and data

3. Implementation in MORSE

External device – Morse Communication Unit (CU)

The CU checks each incoming frame step by step as follows:

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

  2. STX is E3h

  3. VER is 01h

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

  5. Address is not 00h (broadcast)

  6. Header checksum is O.K.

  7. 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.

Example:

  PLC Master -> CU RS
E3 01 00 05 33 1C B1 00 04 47 BA 98 8F
  Morse packet data:
                  B1 00 04 47 BA

Fragmentation algorithms:

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.

  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.

  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.

Examples for the parameter (t)>0, e.g. 1000ms:

 1. PLC -> CU
FF FF FF E3 01 00 05 0D F6 B1 00 04 47 BA 98 8F FF FF FF 
 Morse packet data:
                           B1 00 04 47 BA

 2. PLC -> CU
FF FF FF E3 01 00 05 0D F6 B1 00 04 47 BA 98 8F FF FF FF EE EE E3 01 
00 01 0D F2 31 D4 C1 FF FF FF 
 Morse packet data:
                           B1 00 04 47 BA   (1st packet)
                           31               (2nd packet)

 3. PLC -> CU
FF FF FF E3 01 00 05 0D F6 B1 00 04 47 BA 98 8F FF FF FF EE EE E3 01 
00 01 0D F2         (1st frame)

31 D4 C1 FF FF FF   (2nd frame)

 Morse packet data:
                           B1 00 04 47 BA   (1st packet)
                           31               (2nd packet)

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.

3.1. Communication example

 PLC Master ----> CU RS
E3 01 00 01 33 18 31 D4 C1

 MORSE packet data 
                  31

 CU RM ----> PLC Slave
E3 01 00 01 33 18 31 D4 C1


 PLC Slave ----> CU RM
E3 01 00 05 33 1C B1 00 04 47 BA 98 8F

 MORSE packet data 
                  B1 00 04 47 BA

 CU RS ----> PLC Master
E3 01 00 05 33 1C B1 00 04 47 BA 98 8F

The packet incomming from PLC Master or from PLC Slave can be the same. RS sends it to the address according to ADDRESS byte, RM sends it to the address of last request from RS.

4. Configuration Parameters

MDU parameters:
PLC Master - CU RADIOSLAVE ... CU RADIOMASTER - Slave PLC
(m)ode :RADIOMASTER (wired to slave)
(a):0ms
(q)uit
>>
(m)

(S) RADIOSLAVE (wired to master) – RADIOSLAVE is the CU connected to PLC Master, sends data to an address which is filled in the header of the packet.

(M) RADIOMASTER (wired to slave) – RADIOMASTER is the CU connected to PLC Slave, sends data to the address of the RS which has sent the request.

ATTENTION – The Setr older than 9.0.17.0 uses the reverse labelling M/S !

(a)

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

6. History

9.0.17.0 – 06/2007 – unification of terms RS/RM in the Setr

©  2024 RACOM s.r.o. All Rights Reserved.