Feature Request: Improve FANET support: FNNGB parsing
Basic support for Airwhere/Fanet/Flarm devices is already implemented using flarms $PFLAA strings. However, the fanet protocol has a lot of more features which are not covered right now:
- Tracking with up to 5s tracking interval
- Custom pilot names, not only IDs
- Messaging
- Weather stations
- Tracking on Ground for retrieve
- some more... A brief description of the fanet protocol can be found in [1].
To communicate with a fanet modem (eg. Skytraxx 2.1 or Beacon) it is necessary to parse a #FNF string and to send a #FNT string for sending messages [2].
The FNF string:
#FNF src_manufacturer,src_id,broadcast(0..1),signature,type,length,payload(length∗2hexchars)\n
"All values will be given in hexadecimal format. Each payload byte is formated as 2-byte-chars in hex format." [2]
src_manufacturer: Sender ID first 2 bytes (01-FD)
src_id: Sender ID least 4 bytes (0001-FFFE)
broadcast: ignore for now
signature: max 32bit signature, ignore for now
length: length in byte of payload
type: one of:
- 0: ACK
- 1: Tracking
- 2: Name
- 3: Message
- 4: Service
- 5: Landmarks
- 6: Remote Configuration
- 7: Ground Tracking
Payload depends on type, I will only cover type 1-3 in this issue:
Type 1:
This is basically the same information as send by PFLAA and therefore should be easy to implement.
Payload length should be 11 byte (22 2-byte-chars)
Includes Lat, Lon, Online Tracking, Aircraft type, alt scaling, alt, speed scaling, speed, climb scaling, climb, heading(, turn rate scaling, turn rate)
Each bit is described in [1] Line 59-92: https://github.com/3s1d/fanet-stm32/blob/master/Src/fanet/radio/protocol.txt#L59
Example: #FNF 11,2E,1,0,1,B,7963469EC507369100002\n
Type 2:
The pilot name is send as a 8bit String (of arbitrary length, \0 termination not required), still formated as 2-byte-chars
Type 3:
First Byte (first 2 chars) are ignored, then the message is send as a 8bit String (of arbitrary length, \0 termination not required), still formated as 2-byte-chars
So first a parser for the FNF string is needed, then type 1 can be handled the same as PFLAA, although a higher refreshing rate of the position on the map and more details would be great. Type 2 could be used to print a name instead of the pilot id and type 3 could be integrated into the message widget. Sending messages would require to send a FNT string which is described in [1] and [2].
[1] https://github.com/3s1d/fanet-stm32/blob/master/Src/fanet/radio/protocol.txt
[2] https://github.com/3s1d/fanet-stm32/raw/master/fanet_module.pdf