INCA

https//www.racom.eu/eng/support/protocols_docum/mpgbc280a_inca.html

1. Introduction

The INCA broadcast protocol has been designed by Nederland Haarlem® company. This protocol is used for communication between parking facilities signs and the centre.

The protocol can work in three modes (1.point to point, 2.broadcast, 3.multicast), but only point to point mode is supported by the Morse system.

2. Data Format

All packets in the INCA protocol in point to point mode are characterized by this structure:

| sync/8 | hdrlen/8 | msglen/16 | datachk/16 | msgid/8 | srcaddr/16 |
    E3       0D         00 15       85 F8        00        81 05

 msgtyp/8 | destaddr/16 | hdrchk/8 |      data/size        | tail/8 |
   01         81 06         84      02 00 00 6A 00 82 02 2D    0D

where:

sync start of packet (STX), always E3h
hdrlen length of header (for point to point mode always 0Dh)
msglen total message length (excluding tail)
datachk data check (CRC-16 over message data)
msgid identification of message
srcaddr source address
msgtyp type of destination address:
  • point to point mode — always 01 or 02
  • broadcast mode — 03 (not supported by Morse)
  • multicast mode — 04 (not supported by Morse)
destaddr destination address
hdrchk header checksum (exlusive-or over sync, hdrlen, msglen, datachk, msgid,srcaddr, msgtyp and destaddr)
data transmitted data, size bytes = msglen – 0Dh
tail end of packet (ETX), always 0Dh

3.Implementation of the protocol in the MORSE system

INCA protocol access module.

3.1. External device – Morse Communication Unit (MCU)

The MCU checks every incoming frame step by step as follows:

  1. The frame length must be greater than or equal to 14 bytes (minimum packet size, only header and tail, no data)
  2. STX (sync)is E3h
  3. Header length (hdrlen) is 0Dh (13 bytes)
  4. The actual packet length must be greater than or equal to message length (msglen) filled in header + 1 (tail)
  5. Header (hdrchk) checksum is O.K.
  6. CRC (datachk) is O.K.
  7. Tail is in right position and it is 0Dh.

If all the above checks are 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 msgid (identification of message), msgtyp (message type) and data are transfered within the inner Morse packet.

Example:

External device -> MCU(MR25)
      E3 0D 00 15 85 F8 00 81 05 01 81 06 84 02 00 00 6A 00 82 02 2D 0D

Morse packet data:
      00 01 02 00 00 6A 00 82 02 2D

Fragmentation algorithms:

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

When the MCU 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.
  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 or greater than the expected length.

Examples of fragmentation:

1. External device -> MCU
FF FF FF E3 0D 00 15 85 F8 00 81 05 01 81 06 84 02 00 00 6A 00 82 02 2D 0D
FF FF

      Morse packet data:
      00 01 02 00 00 6A 00 82 02 2D

2. External device -> MCU
FF FF FF FF E3 0D 00 15 85 F8 00 81 05 01 81 06 84 02 00 00 6A 00 82 02 2D
0D FF FF EE EE E3 0D 00 15 6D F9 01 81 05 02 81 06 6F 02 00 00 6A 00 02
02 2D 0D FF FF FF

      Morse packet data:
      00 01 02 00 00 6A 00 82 02 2D    (1st packet)
      01 02 02 00 00 6A 00 02 02 2D    (2nd packet)

3. External device -> MCU
FF FF FF FF E3 0D 00 15 85 F8 00 81 05 01 81 06 84 02 00 00 6A 00 82 02 2D
0D FF FF FF FF EE EE E3 0D 00 15 6D F9 01 81 05 02 81 06 6F 02 00
00 6A                        (1st frame)
00 02 02 2D 0D FF FF FF      (2nd frame)

      Morse packet data:
      00 01 02 00 00 6A 00 82 02 2D    (1st packet)
      01 02 02 00 00 6A 00 02 02 2D    (2nd packet)

3.2. MCU – External device

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

3.3. Flow control

No software handshake is used within the INCA protocol link layer. If all buffers in the MCU 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 External device will overload the network is negligible, assuming normal behaviour of the system.

3.4. Communication example

      INCA centre ----> MCU 05
E3 0D 00 15 85 F8 00 81 05 01 81 06 84 02 00 00 6A 00 82 02 2D 0D

      Morse packet data   MCU 05 ----> MCU 06
00 01 02 00 00 6A 00 82 02 2D

      MCU 06 ---->INCA outstation
E3 0D 00 15 85 F8 00 81 05 01 81 06 84 02 00 00 6A 00 82 02 2D 0D


      INCA outstation ----> MCU 06
E3 0D 00 17 8E C2 00 81 06 02 81 05 B4 02 00 00 6A 00 C2 03 2D FD E8 0D

      Morse packet data   MCU 06 ----> MCU 05
00 02 02 00 00 6A 00 C2 03 2D FD E8

      MCU 05 ----> INCA centre
E3 0D 00 17 8E C2 00 81 06 02 81 05 B4 02 00 00 6A 00 C2 03 2D FD E8 0D

4. Protocol Parameter Settings in the MCU

(t) timeout

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 debu(G)ging level in SCC to 1, you can get debugging messages as follows:

The messages are sent to a 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: HDRLEN !%hu(%02Xh):%hu(%02Xh)"

header length which is filled in the header is not 0Dh

"Ch_in problem: MSGLEN: %hu(%Xh), INC. PACKET LEN: %hu(%Xh)",

The real length of the incoming packet is shorter than the length which is filled in the header of the packet

"Ch_in problem: INC. HCHK: %02Xh, CALC. HCHK:%02Xh"

the calculated header checksum is not equal to header checksum in the header of the packet

"Ch_in problem: INC. DCHK: %Xh, CALC. DCHK:%Xh"

the calculated CRC data is not equal to CRC in the tail of the packet

"Ch_in problem: TAIL !%02Xh:%02Xh"

the tail is not equal to 0Dh

"m_user_in: INC. PACKET TOO SHORT:%hu"

the incoming packet from the Morse transport channel is shorter than 2 bytes (msgid, 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

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