(this is not actually an "issue", simply a suggestion)
I propose one the of 14 available message types be defined as a high resolution position message.
There are two successful example/proof-of-concept flights in the air now using this ET definition:
{ "name": "grid_char7", "unit": "digit", "lowValue": 0, "highValue": 9, "stepSize": 1 }, { "name": "grid_char8", "unit": "digit", "lowValue": 0, "highValue": 9, "stepSize": 1 }, { "name": "grid_char9", "unit": "alpha", "lowValue": 0, "highValue": 23, "stepSize": 1 }, { "name": "grid_char10", "unit": "alpha", "lowValue": 0, "highValue": 23, "stepSize": 1 }, { "name": "since_boot", "unit": "minutes10", "lowValue": 0, "highValue": 100, "stepSize": 1 }, { "name": "since_gps_lock", "unit": "minutes10", "lowValue": 0, "highValue": 100, "stepSize": 1 },
It uses less than 16 bits of the payload to send an additional 4 Maidenhead grid characters. This provides a positional resolution of approximately 25 meters.
The Maidenhead grid overall is not ideal, but this approach is logical and efficient because the callsign and basic-telemetry messages already provide the 6 character locator. Trying to provide enhanced resolution by sending fractional or decimal portions of raw latitude/longitude values would either have lower resolution or use more than 16 bits.
The example above is not applicable to all tracker types, my recomendation is only the grid characters, the remainder of the payload is open to discussion. For example, something like this:
(this is not actually an "issue", simply a suggestion)
I propose one the of 14 available message types be defined as a high resolution position message.
There are two successful example/proof-of-concept flights in the air now using this ET definition:
{ "name": "grid_char7", "unit": "digit", "lowValue": 0, "highValue": 9, "stepSize": 1 }, { "name": "grid_char8", "unit": "digit", "lowValue": 0, "highValue": 9, "stepSize": 1 }, { "name": "grid_char9", "unit": "alpha", "lowValue": 0, "highValue": 23, "stepSize": 1 }, { "name": "grid_char10", "unit": "alpha", "lowValue": 0, "highValue": 23, "stepSize": 1 }, { "name": "since_boot", "unit": "minutes10", "lowValue": 0, "highValue": 100, "stepSize": 1 }, { "name": "since_gps_lock", "unit": "minutes10", "lowValue": 0, "highValue": 100, "stepSize": 1 },It uses less than 16 bits of the payload to send an additional 4 Maidenhead grid characters. This provides a positional resolution of approximately 25 meters.
The Maidenhead grid overall is not ideal, but this approach is logical and efficient because the callsign and basic-telemetry messages already provide the 6 character locator. Trying to provide enhanced resolution by sending fractional or decimal portions of raw latitude/longitude values would either have lower resolution or use more than 16 bits.
The example above is not applicable to all tracker types, my recomendation is only the grid characters, the remainder of the payload is open to discussion. For example, something like this: