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 …