Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
The format of the M17 GPS Data
#1
This is a follow up to the previous document which explained how the META field has been used to pass extended callsign and text data, in addition to the existing callsign and voice data. This document should be read in conjunction with the previous document.

For GPS data the Encryption Type is 0b00 as per the other types of extended META data, and the Encryption Subtype is set to 0b01. Unlike the other forms of data previously documented, this data is expected to be dynamic during the course of a transmission and to be transmitted quickly after the GPS data becomes available. To stop the LSF data stream from being overrun with GPS data relative to other data types, a throttle on the amount of GPS data transmitted is needed. The M17 Client sends GPS data every five seconds, for example.

The GPS data fits within one META field, which equates to six audio frames, and takes 240ms to transmit.

For this description C/C++ style array nomenclature is used. The META field is referred to as an array named meta and with an index of 0 referring to the first byte of that array, and therefore the first byte of the META field.

meta[0] is the software/hardware used to generate this GPS data. The current defined values are 0x00 for the M17 Client, and 0x01 for OpenRTX, other hardware and software will be added as they become available. This is used to modify the message added to the APRS message sent to APRS-IS.

meta[1] is the type of station that transmitted the data. 0x00 is for a fixed station, 0x01 is for a mobile station, and 0x02 for a handheld. These are translated into suitable APRS symbols when gated to APRS-IS.

The latitude and longitude are encoded as positive values with their ranges set to +90 to -90 for the latitude, and +180 to -180 for the longitude. The sign i.e. North/South and East/West are encoded separately.

meta[2] is the whole number of degrees of latitude.

meta[3] and meta[4] are the decimal degrees of latitude multiplied by 65535, and stored with the MSB first.

meta[5] is the whole number of degrees of longitude.

meta[6] and meta[7] are the decimal degrees of longitude multiplied by 65535, and stored with the MSB first.

If the latitude is south of the equator then meta[8] is ORed with 0x01. If the longitude is west of the Greenwich meridian then meta[8] is ORed with 0x02.

If altitude data is available from the GPS device then meta[9] and meta[10] contain the whole number of feet above sea level plus 1500 to always make it a positive number. This value is stored MSB first. The reason for using feet is two fold, firstly this is what APRS-IS expects, and secondly there are a little over three feet per metre, and so an integer number of feet gives finer granularity than metres in this context. meta[8] is ORed with 0x04 to indicate that valid altitude data is available.

If speed and bearing data is available from the GPS device then meta[11] and meta[12] contain the whole number of degrees of the bearing which is expected to be between 0 and 360 degrees. This value is stored MSB first. The speed if converted to miles-per-hour and the integer value is stored in meta[13]. The reason for using mps is this is what APRS-IS expects. meta[8] is ORed with 0x08 to indicate that valid speed and bearing data is available.

This is a simple format of the GPS data and doesn't require too much work to convert into, and provides enough flexibility for most cases. This has been tested on-air and successfully gated to APRS-IS, showing a location very close to the position reported by the GPS receiver.
Reply
#2
An example of the first M17 GPS data gated to APRS-IS is included here.


Attached Files
.jpg   M17-GPS.jpg (Size: 113.05 KB / Downloads: 4)
Reply
#3
Hi Jon, 
  Thanks for the precise description of  GPS encoding of data into the M17 digital side channel.  It looks very good. 

I can accept feet for altitude as it is the basis for altitude in the aviation industry and is a wide spread global industry standard. 

Although I have to disagree on the use of MPH as the basis for speed..  SI  units are meter per second.

Directly encoding 1 byte as m/s really does not give the range for normal speed of vehicles. 

Encoding the speed and a fixed float in meters per second  (6 bits for matissa, 2 bits for exponent) 

speed  = mantissa * 10^(exponent + 1 )  m/s 

(Note the plus one in the decoding of the exponent, however that is not really necessary and without it will allow you to track the speed of garden snails as will as F35 fighter jets) 


This give a range of:

0.35mph to 22370 mph
0.563kph to 36000 kph

I do not agree that what APRS-IS uses should be a basis for how we encode the values. There will always be software that takes the encoded speed form m17 and converts it for presentation to APRS-IS or even to the user interface. 

In fact encoding the altitude in meters in a similar manner would also significantly increase the range over which the altitudes can be reported.

Yes this is more complicated than just taking the byte as a integer number, but I do not think an 8 bit integer number can reliably convey the precision and range these quantities needed. 


With regards to device type information, I would consider making source 0 "default", then the other numbers more specific types, because I can guarantee that there will be a lot of devices that have the default set, regardless of whether they are "fixed" "mobile" or "portable".  This situations detracts from the quality the information of those that have taken the time to set their "fixed" type correctly..

Under the current scheme there will be a lot of "fixed" stations traveling 60mph down the freeway, assuming 0 is the default. 



Cheers, 
David
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)