Pilot3iCollisionAware

Features

• ADS-B in Receiver

• P3I Transmitter/Receiver– Transmitter range in free space Approx 25Km

• RS232 GPS NMEA (ADS-B out)

• Bridge Connect WiFi– WiFi enabled 3rd Party devices

• Bridge Connect RS232– Hardwired 3rd Party devices

3rd Party Interfaces

• WiFi Connected Devices– SkyDemon– RunwayHD (TBD)

• Hardwire Connected Devices– XC-Soar

P3I: Block Diagram

HostSystem

ADS-BRX

P3IRX

P3ITX

1090Mhz

868Mhz

WiFi

RS232NMEA out

RS232traffic

2.4Ghz

Transponder

Device

P3i: Hardware

P3I: 3rd Party Interface (skydemon)

P3I: 3rd Party Interface (xcsoar)

P3i: Software Requirements

• Apple IOS : OEM API Library– Integration into 3rd Party, consistent with the

OpenP3iProtocol– Allow overlays onto 3rd Party software

• Surrounding Aircraft– Position (Latitude/Longitude)

– Speed

– Altitude

– Track

– Extended info

» Pilot name,

» Flight plan (current/next leg)

P3i: OpenP3iProtocol24 bytePacket

syncicaolongitudelatitudealtitudetrackmsdknotsaircraftcrc

Byte 0

Byte 23

P3i: OpenP3iProtocolsync

24 bytePacket

The sync character is a single characterIdentifier, indicating the start of a 24 bytePacket of data. The chosen character is ‘$’, this conforms with the GPS NMEAStandard for a ‘$’ meaning start of line, eg

$GPGGA …

P3i: OpenP3iProtocolicao

24 bytePacket

The icao field is a 24bit value which is usedAs a unique identifier over the air, this canBe the same value used for the transponderOr a pseudo random identifier, an exampleOf an icao would be 0x40526F

P3i: OpenP3iProtocol longitude/latitude

24 bytePacket

The longitude and latitude values are encodedAs decimal degrees, encoded into a 32-bit Floating point number, as specified by IEEE-754 single precisionBit[31] - SignBit[30:23] - ExponentBit[22:0] - Mantissa

Note: 64-bit double number representation would be more accurate,But in reality the inaccuracy due to a 32-bit representation, is soSmall it is not worth consideration.

P3i: OpenP3iProtocolaltitude

24 bytePacket

The altitude value is encoded in metresAbove Mean Sea Level (amsl), this is representedAs an unsigned 16 bit value. There is noRequirement for a signed value, aircraft rarely goUnderwater in normal operation!Although the packet representation is in metres, theDisplayed value is likely to be feet, giving the Following vertical rangerange: 0ft - 215,000ft (AMSL)

P3i: OpenP3iProtocoltrack

24 bytePacket

The track indicates the aircrafts track vectorIn degrees Relative to true north. Encoded as an unsigned 16 bit value, this represents therequired track of 0 – 359

Note: This is a little bit of overkill as the data can represent O – 65535, it may be worthwhile breaking this down into aSmaller structure ofBit[15:9] - reserved (7 bits)Bit[8:0] - track (0-511) (9 bits)

P3i: OpenP3iProtocolmsd (message sequence data)

24 bytePacket

msd

seqbyte0byte1byte2

This is a much more complicated structure than the previous fields. This provides the ability to split a large piece of data overMany packets of information. The seq(uence) indicator, provides an index into an array of data for the subsequent bytes 0-2.The sequence has a range of 0-255, meaning upto 768 bytes ofData can be transferred over consecutive packets

P3i: OpenP3iProtocolmsd (message sequence data)

So what could we use an additional 768 bytes to transfer ?Firstly bear in mind that a full packet of 768 bytes would take a long time to transmit, so this upper limit may be unrealisticThe normal packet transmit time is 2 seconds, so for 3 bytes / second a full message of 768 byte length would take nearly 9 minutes!

But a defined structure could be filled in much more quicklyEg:Route start: latX2, lngY1Point+1: latX1, lngY2Point+2: latX1, lngY2

This is effectively 24 bytes info, which would be split across 8 packets (24/3), and would therefore take 16 seconds to be reconstructed. But this information does not change and would provide the receiver with information about the pilots intended route. This kind of information is automatically available in skydemon, airnav pro and other tools

Note: what is useful in the extended information ?

P3i: OpenP3iProtocolknots

24 bytePacket

The knots field indicates the ground speed of the Aircraft in knots. As an unsigned 16 bit value, thisGives a range of 0 – 65535 knots

Note: This is a little bit of overkill as the data can represent O – 65535, it may be worthwhile breaking this down into aSmaller structure ofBit[15:11] - reserved (6 bits)Bit[9:0] - track (0-1023) (10 bits)

P3i: OpenP3iProtocolaircraft

24 bytePacket

This field indicates the aircraft type, and has a Range of 0-255, which means we could represent 256 types of aircraft.Groundstation, microlight(flex), microlight(3-axis),Helicopter, paramoter, glider, motor-glider, balloon,Parachute, drone, model aircraft ….Note: is there a list of types of aircraft we could encode?

P3i: OpenP3iProtocolcrc

24 bytePacket

This is a simple cyclic redundancy checkerUsed on the packet data from 0:22 bytesIf the CRC generated locally agrees with theCRC at the end of the packet, the packetIs deemed to be valid, else it is discarded

P3i: OpenP3iProtocolThe plan is for every plane to transmit a single packet of information at about2 second intervals. This is at a data rate of 38.4kb/sThe greater the data rate, the less likely interference, but receiver sensitivity is Likely reduced, consider the over the air bandwidth as a series of trains

P3i: OpenP3iProtocol38400 baud

38400baud = 1bit/26uS24 bytes = 192 bits = 5ms2 second repeat = 2.5% of the bandwidth

2 seconds

This makes the data less likely to corruption

Competitive Analysis• ADSB

– Expensive ?– Cost prohibitive– Limited data Routeplan, Extended Information ?

• FLARM– Expensive (for what you get)– Poor range– Targetted at gliders only ?– Limited data Routeplan, Extended Information ?– Bespoke (expensive) hardware – no modern standard interfaces, uses

RS232, data rate 19.2kb/s too high for Bluetooth Low Energy best case 6kb/s, and very expensive to use Bluetooth Classic (Apple MFI program)

– No support for standard platforms• Iphone• Ipad• android