Print version

9. Protocols

The CU diagram shows, that the packets from the user equipment comes into node through serial communication channel SCC0, 1, 2, 3 or ETH0. After passing through the MORSE network, they leave the last node again through SCC. Inside the MORSE network are used the packets in the MORSE form but the user equipment use packets in various forms. One of the tasks of SCC is to convert these packets into unified form suitable for the transfer through network and on its output adjust it again in users form. This function is defined in the protocols relevant to the various user equipment.

The protocols can be assigned individualy to each of SCC in the menu SPe, see MORSE firmware documentation, chapter SCC channels for more details. Each protocol uses its set of parameters, which contain the user’s information for the function of the protocol. The protocols can be classified, roughly, according to their function:

  • Mere asynchronous link between two points. For example: ASYNC.LINK, ASYNC LINK++

  • The protocols furnished by address and checksum. This allows the connection between different points of network, they guarantee the error free data transmittion. For example: RDS

  • Protocols containing additional information useful in the network like packet type, packet number, notice about repeated transmitting or some special services in the link layer. For example: MARS-A

  • Protocols MASTER-SLAVE type. This numerous group defines one station as the central, which sends the questions to other stations and expects the answers from them. For example: MDU, MININET, MODBUS, S-BUS, COMLI, PR2000

  • Protocol comunicated through Ethernet channel.

Some illustrational examples for function of individual groups will be shown here. More exact descriptions are on the pages in part Support, Software, Interface protocols. Next examples shows the form of packet at input into the MORSE network through SCC having appropriate protocol, next the packet in MORSE form outputting the SCC to the node and at last the packet outputting the destination CU through channel SCC.

9.1. ASYNC LINK protocol

This simple protocol uses only one parameter – MORSE address of opposite station:

ASYNC LINK parameters:
link destination

The next monitoring shows the packet containing the data AAAA, which was accepted by SCC channel S02. Next it was sent from SCC2 into the node modified in the MORSE packet form with addresses (from right) source and destination. The packet is processed in the node (addresses from and to added) and transmitted through RF channel and at last it leaves MORSE network in the destination station through channel SCC1 with the original form AAAA.

08:38:35.336 rxsim   2 | S02

CNI mon     |toa      frm     |dst      src     |          size|TT N
08:38:35.337|                 |00001241 00001240|S02I  OUT    2||89 0user

RF mon      |toa      frm     |dst      src     |lNo!DQ!RSS size|TT N
08:38:35.337|690F1241 690F1240|690F1241 690F1240|019  RFTX     2 89 0dat

Monitoring: source 690F1241|6.
08:38:35.353 tx      2 | S01

The address of opposite CU must be put in the parameter of protocol ASYNC LINK. This is why the data can be transfered only between in advance chosen pair of CU (see the name of protocol). The data transferred between the user equipment and SCC port are not checked on lost nor error free transfer.

9.2. RDS protocol

This protocol doesn’t contain the address in its parameters, instead the address is contained in the incoming packet to SCC. It is the down part of destination address 41, more the packet contains the aid label 44, length of data 0200, checksum 25 and the data transfered AAAA. The data is the only part, which is transferred through the morse network, as we can see in second part of monitoring. The last part shows the packet leaving the MORSE network through SCC1 port.

Monitoring: source 690F1240|7.
12:47:34.006 rxsim   7 | S02
4441 0200 AAAA 25
12:47:34.007|690F1241 690F1240|690F1241 690F1240|01C  RFTX     2 89 6dat

Monitoring: source 690F1241|0.
12:47:34.039|690F1241 690F1240|690F1241 690F1240|01C*30* 65    2*89 6dat
12:47:34.039 tx      7 | S01
4440 0200 AAAA 26
  • One must say, that more information from input packet were transfered through MORSE network, in this case the address, which is the standard part of the MORSE packet. Transfer of this address through network in original input packet would be duplicated. Similarly duplicated would be the transfer of others part of input packet because it can be reconstructed by RDS protocol in output port SCC1.

  • The comunication can be directed in different nodes, because the destination address is contained in the incoming packet. The user equipment should be able assemble the packet properly including the address and checksum.

  • The checksum characterizes the state of packet at dispatch from the user equipment and according to it is checked the error free communication between outer equipment and the SCC port. In this illustrations are omitted the ACK messages, more about them in article Chapter 8, Secured packet transfer.

9.3. MARS-A protocol

The MARS-A protocol is equipped by all required functions. It contains in its head the address, the packet type, the repeated transmitting label, the numeration of packets transmitted and more. The example shows the dispatching of data AAAA to the address 690F1241. The second part shows the packet going from RFC to the antenna. The last one is the packet going out of the destination node through SCC1, which is adjusted in the MARS-A form.

Monitoring: source 690F1240|4.
13:09:03.750 rxsim  12 | S02
C008 0980 690F 1241 AAAA 186C

13:09:03.751|690F1241 690F1240|690F1241 690F1240|030  RFTX     2 89 0dat

Monitoring: source 690F1241|3.
13:09:03.781|690F1241 690F1240|690F1241 690F1240|030*29* 66    2*89 0dat

13:09:03.781 tx     12 | S01
F008 0900 690F 1240 AAAA 28ED
  • The packet incoming into network through the port differs in its head and in checksum from the packet leaving the network, but the data is equal. The dissimilarity of head results from its function, e.g. the incoming packet contains the destination address, the outgoing packet contains the source address.

  • The target address is not written among the parameters but it is contained in the packet incoming in MARS-A protocol from outer device and so the packets from connected terminal can be send to different targets in the network.

9.4. The data transfer between different protocols

Considering the fact, that the protocols converts the incoming packet to the unified MORSE form for transmission through the network and before outputing the packets converts again in the form required by outer device, it is possible to use different protocols on net input and net output. For example, the transport of data AAAA which was inputted by RDS protocol and outputted by MARS-A protocol looks like this:

Monitoring: source 690F1240|7.
13:26:50.465 rxsim   7 | S02
4441 0200 AAAA 25

13:26:50.466|690F1241 690F1240|690F1241 690F1240|03D  RFTX     2 89 7dat

Monitoring: source 690F1241|4.
13:26:50.498|690F1241 690F1240|690F1241 690F1240|03D*29* 67    2*89 7dat

13:26:50.498 tx     12 | S01
C008 0907 690F 1240 AAAA 18EA

This feature can be used for creating the exchange, which proceeds the data from various CU equipped by different protocols.

9.5. Service access

Upon communication between Setr and the CU over the service cable a SERVICE connector is used. This works over the SCC0 channel and MARS-A protocol.

After connecting CU to the PC with a service cable protocol MARS-A is set automatically to SCC0. For the duration of the service connection user communication on SCC0 is interrupted.

After disconnecting the service cable the original protocol settings and user communication on SCC0 are automatically restored.


Radio modem MR25 uses channel SCC2 for service access