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:
|
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:
- The frame length must be greater than or equal to 14 bytes (minimum packet size, only header and tail, no data)
- STX (sync)is E3h
- Header length (hdrlen) is 0Dh (13 bytes)
- The actual packet length must be greater than or equal to message length (msglen) filled in header + 1 (tail)
- Header (hdrchk) checksum is O.K.
- CRC (datachk) is O.K.
- 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.
- 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 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