https//www.racom.eu/eng/support/protocols_docum/bc132a_parkair.html
1. Introduction
This protocol is assigned for exchanging short messages between two points.
The connection is checked for good safety every e.g. 300ms on the wires and
every e.g. 5sec in the air.
2. Data format
The packets are created by 2 individual bytes which should have this form
(in bits):
xxxx xxx1 xxxx xxx0
The bits 1 and 0 are compulsory, the others can carry the information.
Neither header nor checksum is used.
3. Configuration parameters
The SCC should separate the single bytes, so the RX(i)dle and RXbuf(s)ize
must be set as follows:
SCCs:
n m g b p8 i s XRC D G o
(0)RS232 ASYNC SW 19200N81 1 1 — D 0 PARK AIR
(1)RS232 ASYNC SW 19200N81 5 1600 — D 0 MARS-A
(2)RS232 ASYNC SW 19200N81 5 1600 — D 0 MARS-A
Protocol parameters:
PARK AIR parameters:
(a)ddress::00000002
net (t)x timeout:5s
(n)et inactivity timeout:10s
link (r)epeat period:1000ms
(l)ink inactivity timeout:2000ms
(q)uit
>>
The meaning of parameters results from this description:
Packets received in SCC Packets transmitted from RFC
periodically, in shorter -> every (t)5sec is the packet transmitted
interval then (r)1000ms
packet having different -> packet is transmitted immediately
content then previous
inactivity longer -> every (t)5sec is transmitted 0x0000
then (l)2000ms
Packets received in RFC Packet transmitted from SCC
periodically, in shorter -> every (r)1000ms is the packet transmitted
interval then (n)10s
periodically, in shorter -> stop transmitting to SCC
interval then (n)10s
arrives packet 0x0000
inactivity longer -> stop transmitting to SCC
then (n)10s
4. Example of implementation into the MORSE system
The packets FFFE or 0100 are received and divided to bytes with help of
RX(i)dle and RXbuf(s)ize. The secondary result is the defective picture
from monitoring. The message:
10:43:36.594 — 1 | S00
0000 FE
has the same sense as:
10:43:36.594 rx 1 | S00
FE
1) Normal traffic, FF FE is incoming every 500ms,
FFFE is transmitted every 5sec:
10:43:36.591 rx 1 | S00
FF
10:43:36.594 — 1 | S00
0000 FE
10:43:37.091 rx 1 | S00
FF
10:43:37.093 — 1 | S00
0000 FE
10:43:37.591|690F5502 690F5501|690F5502 690F5501|7F4 RFTX 2*89 2dat
FFFE
10:43:37.592 rx 1 | S00
FF
10:43:37.594 — 1 | S00
0000 FE
…
2) Different packet 01 00 arrives and it is transmitted immediately.
Next packet FFFE is different from previous one and it is transmitted
immediately also:
10:43:39.595 rx 1 | S00
FF
10:43:39.597 — 1 | S00
0000 FE
10:43:39.834 rx 1 | S00
01
10:43:39.839 — 1 | S00
0000 00
10:43:39.842|690F5502 690F5501|690F5502 690F5501|7F5 RFTX 2*89 3dat
0100
10:43:40.097 rx 1 | S00
FF
10:43:40.098 — 1 | S00
0000 FE
10:43:40.102|690F5502 690F5501|690F5502 690F5501|7F6 RFTX 2*89 4dat
FFFE
…
3) Receiving of FF FE stopped and (l)2000ms later starts the
transmitting of 0000 from RFC:
10:43:42.099 rx 1 | S00
FF
10:43:42.101 — 1 | S00
0000 FE
10:43:44.105|690F5502 690F5501|690F5502 690F5501|7F7 RFTX 2*89 5dat
0000
10:43:49.106|690F5502 690F5501|690F5502 690F5501|7F8 RFTX 2*89 6dat
0000
…