MARS-A is a full duplex protocol with 32bit long addresses, with
error detection (based on 16 bit checksum or 16 bit CRC) and with error
correction. MARS-A could perhaps be characterised as the most user
friendly of the network protocols in the MORSE system. With simplicity on
the user interface, it offers access to all services in the MORSE data
network system. Of course, the user has the option to choose whichever
subsets to work with from the protocol.
The obsolete MARS-U (MARS rev.2) protocol (equipped with 16bit long
address) is replaced by this new protocol. Longer address space is needed
mainly for mobile applications in the MORSE network. The difference
between this protocol and the obsolete mars-u protocol is that of longer
address and different frame type.
Data frame example in the MARS-A format:
|FT/2|FN/2|R/1|S/11| PT/8|H/1|L/1|R/3|N/3 | A/32 | DATA |F/8|BCW/16| | C008 | 89 | 05 |690F 1244| AAAA | | 98EC |
FT/2 |
frame type |
FN/2 |
frame number |
R/1 |
repeat |
S/11 |
size, length of link layer data field, S= data |
PT/8 |
packet type |
H/1 |
H2N bit |
L/1 |
local mode |
R/3 |
reserve |
N/3 |
net number |
A/32 |
destination or source address according to the parameter |
DATA |
user data, length is S – 6 [byte] |
F/8 |
stuffing used to achieve an even size of the frame |
BCW/16 |
checksum |
The detailed description of the format follows.
The physical layer is given within the possibilities of the
hardware in the MORSE system. In principle, MARS-A can operate in any
arbitrary channel configuration. The standard assumption is for
asynchronous communication between DTE-DCE on a duplex V.24 interface,
using only data signals RXD, TXD, and ground (3-wire communication).
Communication at higher speeds and at greater distances can use the
RS422 interface. Synchronous communication is only possible on the V.24
interface.
The link layer protocol can operate on an arbitrary physical
interface enabling full duplex asynchronous communication with 8 data
bits. It is fully transparent for data transfer, consequently
flow-control Xon/Xoff cannot be used. It is also not necessary to use a
hardware handshake as control of data flow is secured by the protocol
itself. Due to its simplicity, this link layer protocol is useful for
links with a negligible rate of error. The frame always has an even
number of bytes. A set it is composed of a 16 bit label, a data block
(always an even number of bytes), and a 16 bit control word
(BCW).
There are three types of link layer frames:
-
Data frame
-
Control frame
-
Service frame
Standard communication is Data frame – Control frame:
Example: | |
Data frame: | C009 0900 690F 8105 AB11 223A A828 |
Control frame: | 8106 |
Answer: | |
Data frame: | E009 0900 690F 8106 CD33 442F 881C |
Control frame: | A106 |
Data frame (including previous example):
| L/16 | LLD/size | F/8 | BCW/16 | C009 0900 690F 8105 AB11 22 3A A828
L/16 |
Label. |
LLD/size |
Link layer data. |
F/8 |
Stuffing – byte with an arbitrary value used to achieve an |
BCW/16 |
Block Control Word – Checksum mode is counted as |
Label – 16 bits (1 Word) divided as follows:
| FT/2 | FN/2 | R/1 | S/11 | 11 00 0 000 0000 1001 ( = 0xC009 )
FT/2 |
Frame Type
|
FN/2 |
Frame Number. Numbers are not incremented for repeated |
R/1 |
Repeat bit
|
S/11 |
Link layer data size (LLD), length of data field in bytes, |
Control Frame:
| FT/2 | FN/2 | CC/4 | CT/8 | 10 00 0001 0000 0110 ( = 0x8106 )
FT/2 |
Frame Type
|
FN/2 |
Frame Number. Equal to FN of acknowledged frame. |
CC/4 |
Control frame class – currently 0x1 |
CT/8 |
Control frame type
|
Time Get Service: read GMT from DCE
Request format:
| L/16 |0001/16| BCW/16 |
Response format:
| L/16 |0081/16|gmtsec/32|tfix/1|R/5|msec/10| BCW/16 |
Time Get Service: read GMT and localtime from
DCE
Request format:
| L/16 |0002/16| BCW/16 |
Response format:
| L/16 | 0082/16 | gmtsec/32 | tfix/1 | ts/1 | R/4 | msec/10 | | sec/8 | min/8 | hour/8 | day/8 | month/8 | year/8 | BCW/16 |
-
Time information is valid when the first bit of the first
byte of the frame is transmitted. -
The accuracy of time read is better, than 1
millisecond. -
When repeating, the time information is updated before
sending the frame, thus a repeated frame will differ from the
previous one.
Time Put Service: synchronise DCE’s internal
clock
Synchronisation command format:
| L/16 | 0003/16 | gmtsec/32 | R/6 | msec/10 | BCW/16 |
-
Time information is valid when first bit of the first byte
of the frame is received. -
The accuracy of time synchronisation is better, than 1
millisecond.
Confirmation format:
| L/16 | 0083/16 | BCW/16 |
Here:
L/16 |
label |
Time GMT:
gmtsec/32 |
current time, in seconds, |
msec/10 |
current milliseconds in running second, max. 999ms also |
tfix/1 |
radio modem time fix quality
|
ts/1 |
timesavings (1 – on) |
R/4, R/5, R/6 |
reserved, must be zero |
Local time (includes time zone and daylight savings):
sec/8 |
Seconds |
min/8 |
Minutes |
hour/8 |
Hour (0–23) |
mday/8 |
Day of month (1–31) |
month/8 |
Month (0–11) |
year/8 |
Year (calendar year minus 1900) |
The network layer contains the network header and the data, that
is in the previous example:
| NETWORK HEADER | DATA | 0900 690F 8105 AB11 22
Header structure (including previous example):
| PT/8 | H/1 | L/1 | R/3 | N/3 | A/32 | 0000 1001 0 0 000 000 0x690F 8105 ( =0x0900 690F 8105)
Network layer data:
| DATA | AB11 22
PT/8 |
Packet type, see next chapter |
H/1 |
H2N bit |
L/1 |
Local |
R/3 |
Reserved, must be zero |
N/3 |
Network number (transferred over the network) |
A/32 |
Address |
-
Packet numbering is not compulsory. Only the lowest three bits
from the number are transmitted. The entered number is transported
to the address, and can serve to control the order of the delivered
packets (the MORSE network does not guarantee a perfect order for
packets). -
The address is the source address (Host receives a packet) or
the destination address (Host transmits a packet). The packet goes
in the CU through the CNI (Channel to Node Interface), which maps
the user address space to the MORSE address space e.g. by a
mask. -
The maximum allowable length of data in the MORSE network
layer is 1626 bytes. Longer packets are not defined within the
system. The optimum packet size for MORSE system is 200-400
bytes.
The Packet type composition:
|U/1|B/1|R/1|subt/5|
U/1 |
link security bit |
B/1 |
broadcast (multicast) bit |
R/1 |
reserved |
subt/5 |
subtype |
The subtypes of packets can be divided into 5 groups:
-
User packets
-
Request for services
-
Service reports
-
System reports
-
Special packets
Here we describe the most important MORSE packet subtypes:
09h – USER DATA |
The basic type of packet for transporting data from source |
0Ah – PROT DATA |
This type of data is designed for data flow control in the |
10h – SERVICE REQUEST |
Request for a MORSE service. |
12h – SERVICE REPORT |
Report from a MORSE service. |
0Ch – PACK ERROR REPORT |
MORSE error message. First word is the Error Number, the Some of these Error Numbers are here:
|
The packet used in the next example has this composition:
F008 0980 690F 8902 AAAA B32F
This is more exactly (see Data format chapter):
F 0 0 8 0 9 8 0 690F 8902 AAAA B32F bytes 11 11 0 000 0000 1000 0000 1001 1 0000 000 bits __ __ _ _____________ _________ _ ____ ___ _________ ____ ____ FT FN R size PT H L,res N address data BCW meaning (8 bytes) |<-- -->|
Here is H=1, so the address is considered as destination.
In this example the packet in MARS-A format is received via SCC2
port in CU 690F8901, goes through the MORSE network and then outputs
from CU 690F8902 via SCC3 port. The monitored points are labeled
*
* * * rxsim -> SCC0 -> 690F8901 -> 690F8902 -> SCC1 -> tx MARS-A source destination MARS-A protocol address address protocol
>> 12:29:37.101 rxsim 12 | S02 F008 8980 690F 8902 AAAA 332F 12:29:37.102 tx 2 | S02 B106 CNI mon |toa frm |dst src | size|TT N 12:29:37.102| |690F8902 690F8901|S02I OUT 2||89 0usr 0 AAAA 12:29:37.135 tx 12 | S03 D008 8900 690F 8901 AAAA 13AC 12:29:38.143 tx 12 | S03 D808 8900 690F 8901 AAAA 1BAC
The monitoring contains 5 parts:
-
The inputting packet, H=1 and destination address.
-
Confirmation ACK on SCC2.
-
The packet outgoing from SCC2 to the node 690F8901, data
only. -
The packet transmitted from SCC3 port, H=0 and source
address. -
The repeatedly transmitted packet from SCC3, because the ACK
on SCC3 is missing.
In the next example we send a request for the software version in
a radio modem and we receive answers. Packet type is 10h
or
12h
, request for system software version is formulated as
three bytes E0277600 (or E027 followed by the binary coded software
version in the case of the answer). Address of the radio modem
690F0501
serves here as destination and source
also. The protocol is configured in checksum mode.
//Send & receive 16:51:55.87|tx S0 14 D00A 1080 690F 0501 E027 7600 3AA3 16:51:55.87|rx S0 2 9106 16:51:55.88|rx S0 36 E020 1200 690F 0501 E027 0000 0045 01B2 0000 0000 0041 01B2 0000 0000 0042 01B2 0000 7FFD 16:51:55.90|tx S0 2 A106 //Send & receive with ACK after the frame 16:52:11.42|tx S0 14 E00A 1081 690F 0501 E027 7600 0AA2 16:52:11.42|rx S0 36 F020 1201 690F 0501 E027 0000 0045 01B2 0000 0000 0041 01B2 0000 0000 0042 01B2 0000 6FFC 16:52:11.43|rx S0 2 A106 16:52:11.45|tx S0 2 B106 //Send & receive 16:52:12.44|tx S0 14 F00A 1082 690F 0501 E027 7600 1AA1 16:52:12.45|rx S0 2 B106 16:52:12.45|rx S0 36 C020 1202 690F 0501 E027 0000 0045 01B2 0000 0000 0041 01B2 0000 0000 0042 01B2 0000 5FFF 16:52:12.48|tx S0 2 8106 //Send & receive with repeats 16:52:20.89|tx S0 14 C00A 1083 690F 0501 E027 7600 2AA0 16:52:21.99|tx S0 14 C80A 1083 690F 0501 E027 7600 22A0 16:52:23.09|tx S0 14 16:52:23.09|rx S0 2 8106 16:52:23.11|rx S0 36 D020 1203 690F 0501 E027 0000 0045 01B2 0000 0000 0041 01B2 0000 0000 0042 01B2 0000 4FFE 16:52:23.14|tx S0 2 9106 //Send with no answer 16:52:33.04|tx S0 14 D00A 1084 690F 0501 E027 7600 3AA7 16:52:34.13|tx S0 14 D80A 1084 690F 0501 E027 7600 32A7 16:52:35.22|tx S0 14 D80A 1084 690F 0501 E027 7600 32A7 16:52:36.32|tx S0 14 D80A 1084 690F 0501 E027 7600 32A7 //(MORSE error message should be generated...)
Time set and time get example (via link layer of the
protocol).
PLC sends the synchronisation command which sets the time in the CU, GMT:17.8.2007, 08:29:35.873 monitored on SCC2 of synchronised CU, the CU time was changed from 08:35:24 to 08:29:26 >> 08:35:24.870 rx;i 12 | S02 0008 0003 46C5 4E56 03E7 0B7F 08:29:26.992 tx 6 | S02 0002 0083 0081 08:29:26.992 tx 2 | S02 8106 08:29:27.002 rx;i 2 | S02 8106 PLC connected via MARS-A enquire about the time, the CU responds using the longer format, GMT:17.8.2007, 08:29:35.873 monitored on SCC2 of questioned CU: >> 08:29:35.873 rx;i 6 | S02 0002 0002 0000 08:29:35.874 tx 18 | S02 100E 0082 46C5 4E5F 436A 231D 0811 076B 771B 08:29:35.874 tx 2 | S02 8106 08:29:35.890 rx;i 2 | S02 9106 PLC connected via MARS-A enquire about the time, the CU responds, GMT:17.8.2007, 08:32:21.232 monitored on SCC2 of questioned CU: >> 08:32:21.232 rx;i 6 | S02 0002 0001 0003 08:32:21.232 tx 12 | S02 2008 0081 46C5 4F05 40E8 69A1 08:32:21.232 tx 2 | S02 8106 08:32:21.245 rx;i 2 | S02 A106
Code fragment in C language, which will convert binary GMT to
ASCII.
void main() { time_t t=0x388BAD40; struct tm *gmt; gmt = gmtime(&t); console.printf("GMT is: %s", asctime(gmt)); }
The transfer is designated to occasional use, e.g. for the
configuration changings in the distant communication unit (CU).
HW arrangement and the parameter setting is similar, like at the
connection with async. link, see the example
in the MORSE Guide 1. The full RS232 cable for connection between SCC
and the phone modem is recomended. In the case of using 3-wires cable
connect the DTR and DSR pins on the phone modem. In the telephone modem,
there is necessary set the parameter AT&K0 (the data flow control
off) and ATQ0, ATV1. The autoanswer function can be ON, however it is
executed from CU also. Considering the various characteristic of the
phone modems it is necessary to test the configuration in
advance.
The speed 19200 bit/sec is sufficient for fixed lines (can be to
57600), for GSM set max 9600. It should be in any case equal to the
speed of telephone modem.
With help of SPe 0t
set the parameters of protocol
MARS-A on both CU equal:
MARS-A parameters: (a):1000ms (r):5 (c)rc:OFF (G)SM:1 no traffic t(i)meout:0sec (t)el.: Opposite retranslation address:00000000 (l)oc:OFF loc (s)ource:00000000 (R)emote dial-up :OFF DO ORDER SPECIAL CABLE! DO SET IDLES TO 30! (q)uit >>
(G)SM:1 |
in calling CU activates the function of phone connection, in |
t(i)meout:30 |
switches out the phone connection at longer dellay, than 30 |
It can be set either to 0 (the function is off) or the time longer
then 30 sec, because after beginning of connection the holding packets
are send every 20 sec and this at normal circumstances prevents the
termination of connection.
STARTING OF CONNECTION:
Fulfil the telephone number (t)el.
:
to the parameters MARS-A protocol in the same form, like at telephone
call:
25 link inside the firm net
566618578 public line
0566618578 call from the firm net “through zero”
Don’t save this parameter by (w)rite
command, but
initialize it only:
(q)uit Enter (I)nit Enter
The telephone modem makes the connection, which is visible in this
way:
-
the LED named OH (Off Hook) is on, the modem started
work -
the modem dial the number (audible)
-
if the start of connection with the opposite modem was
succesful, takes place the connection parameter negotiation, which
looks like the variable tone for pair of seconds. After succesful
parameter negotiation the LED CD (Carrie Detect) is on -
from this moment it is possible to comunicate between both
radio modems through phone line, e.g. send the ! command and change
the configuration in the opposite CU
After the automatical sending of the holding packet, the address
of opposite CU appears in the MARS-A parameters like “Opposite
retranslation address”. When we need cancel the connection, we do
Init with empty string(t)el.:
in
MARS-A parameters.
Check the cancel of connection, which shows like switching off CD
and OH. In case of any problem we stop the connection by phone modem
switching off and on. We choose from main menu SPe0t
and
check, if the parameter (t)el.:
is
empty. In other case the phone number would be dialled at next start of
CU.
This remote access via the telephone modem replaces the connection
using the service cable. Configuration:
PC -- TM ---telephone network --- TM -spec.cable- CU
PC |
PC with OS Linux and program |
TM |
telephone modem |
spec.cable |
RS232 crossed cable, in which pin CD is connected to pin DTR |
CU |
MR400 series CU, fw 746 or higher, default configuration |
A remote CU is connected via the serial port to the telephone
modem using a “Special dial-up cable”. The CU can be set up with default
configuration, the SCC used has protocol MARS-A set up with parameter
(R)emote dial-up:ON
. It is a good idea to set up the
parameter idle to a higher value, for example SPe
.
2i RX (i)dle:100
Set up parameters containing the telephone number and port in
program rr_setrdial
. After starting the program sets up a
connection with the destination TM and then starts
.
rr_setr
After connection TM-spec.cable-CU the CU starts to send on wires
each 30 sec the ASCII command autoanswer ATS0=1. The TM sets the
communication speed according to CU. When PC through rr_setrdial calls
the distant TM, then TM accepts the call, sets CD=1 and in this way
appears DTR=1 on CU. Only now at DTR=1, the CU can send data via
it’s TM into distant application rr_setr.
Now we can work with Setr in the destination CU in the same way as
if connected via the service cable. We are not connected via SCC0, as is
the case with the service cable, but via SCC used for “special dial-up
cable”. Connection of the cable:
SCC 25-pin male (radiomodem) (dial-up modem) 1 - CD --- 20 - DTR 2 - RxD --- 2 - TxD 3 - TxD --- 3 - RxD 4 - DTR --- 8 - CD 5 - GND --- 7 - GND 6 - 6 - DSR 7 - RTS --- 5 - CTS 8 - CTS --- 4 - RTS 9 - 9 - NC - NOT CONNECTED
MARS-A parameters:
MARS-A parameters: (a):1000ms (r):5 (c)rc:OFF (G)SM:0 no traffic t(i)meout:0sec (t)el.: Opposite retranslation address:00000000 (l)oc:OFF loc (s)ource:00000000 (R)emote dial-up :OFF DO ORDER SPECIAL CABLE! DO SET IDLES TO 30! (q)uit >>
The link layer protocol is always configured using the protocol
parameters.
(a) |
ACK timeout in milliseconds |
(r) |
No of repeats (not counting the first trial) |
(c) |
OFF = lengthwise parity used, default state ON = CRC-16 mode |
(G) |
telephone modem connection, see chapter Section 3.5, “Support for dial-up on GSM or telephone modems” |
(i) |
switches out the phone connection automatically |
(t) |
called telephone number |
– |
Opposite retranslation address:00000000 |
(l) |
OFF = normal state ON = local retranslation mode for the service purposes, the |
(R) |
OFF = normal state ON = (R)emote dial-up, the service access into a remote CU via |
There are two basic parameters:
-
(a) – ACK timeout – the time after transmitting a data frame in
which the transmitting station waits for an ACK frame. If the ACK does
not arrive, the frame is repeated. -
(r) – number of repeats – if the number of repeats is exhausted
and the ACK timeout expires, the network layer is informed that the
packet is lost.
The state diagram on the transmitting side of the link layer
protocol has only two states:
The “quiet” state, and the “waiting” state
while expecting an ACK frame. Immediately after receiving a demand to
transmit a data frame, the “quiet” state passes into the
“waiting” state in order to receive the ACK. After receiving
the ACK, or if the timeout expires after the last repeat, the link layer
protocol goes back to the quiet state. While in the waiting state, the
protocol declines all requests to send a frame.
The receiving side reacts instantly after receiving a correct data
frame by sending an ACK frame. For a correct frame, the ACK is sent
immediately after it is finished, so the ACK timeout must be set at least
equal to the time for transmitting the longest frame. An incorrect frame
is silently discarded.
Between two characters in the frame, there cannot be a greater delay
than is set in the idle parameter. A split frame is evaluated as an error,
even if this occurred due to the hardware handshake.
revision 0 (MARS M) 3/1999 |
two 2 byte addresses, data frame type 00, size in net header, |
revision 1 (MARS U) 4/1999 |
one 2 byte address, data frame type 01, (switch old on) |
revision 2 (MARS U) 4/1999 |
one 2 byte address, data frame type 01, numbered ACK |
revision 3 (MARS A) 12/1999 |
one 4 byte address, data frame type 11, numbered ACK,added |
revision 4 (MARS A) 9/2001 |
added broadcast bit and security bit to the packet type |