Park Air

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
…


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