Feature request: DAO extension

[dl9rdz]

Would it be possible to add support for high-precision positions based on the APRS DAO extension (as defined in http://www.aprs.org/datum.txt)?

[ab0oo]

Probably so. Let me look at it, and I'll get back to you. I've been useless with JAVAPRSLib for a year or two, but I need to get back to it. Do you have the time/skills to take it on? John Gorkos

…

On 9/12/19 10:01 AM, dl9rdz wrote: Would it be possible to add support for high-precision positions based on the APRS DAO extension (as defined in http://www.aprs.org/datum.txt)? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9?email_source=notifications&email_token=AAC7HEKY4GJE7KPOKAPUQ2TQJJYX7A5CNFSM4IWHEPGKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HLBNWSQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC7HELIHSWAZ7V74A7M4KDQJJYX7ANCNFSM4IWHEPGA>.

[dl9rdz]

Time is a bit scarce the next two weeks due to travelling, but I can try to contribute.
For parsing APRS strings it should be rather straight forward without needing any API changes, but for encoding positions its a design decision if/how to extend the API such that packets can be generated with and without DAO extension.

[dl9rdz]

I put some draft code here: https://github.com/dl9rdz/javAPRSlib, but its not yet fully tested.
I suggest to use the positionAmbiguity to control the DAO extension (when parsing, the code sets positionAmbiguity to -1 for single precision DAO and -2 for radix91 DAO; when encoding packets, DAO field is generated if positionAmbiguity is set to -1 or -2).