[iz0qwm]

What this adds

Add parser support for the proposed Drone Sky Check centralized Remote ID feeder:

• Recognize OGNDSC as beacon_type=dsc.
• Parse the optional dscT token into dsc_time_source and dsc_time_reconstructed.
• Preserve ordinary position parsing when the token is absent, and preserve all existing feeder behavior.

The four codes describe original-device, GNSS-clock, network-clock or other reconstruction provenance. They do not assert numerical time accuracy. Unknown, malformed or multiple tokens leave the optional fields absent; the raw comment is retained.

Validation

Full suite: 87 passed, 2 skipped, with Python 3.12 and ogn-parser 0.3.15. The 17 added cases cover the four codes, absent/malformed/ambiguous tokens, isolation from existing feeders, sent/received paths and optional altitude/motion. Protocol examples also parse with this implementation. Dependencies and the upstream protocol corpus pin are unchanged.

Companion Draft PR: glidernet/ogn-aprs-protocol#53

OGNDSC and dscT are submitted for normal protocol review; the extension is optional. Test fixtures are synthetic and unallocated. No live OGN test or Production activation is part of this change.

[Meisterschueler]

Mainly for performance reasons with version v2, the parser was switched from a Python-based approach — dst_call sensitive and relying on regular expressions — to a parser implemented in Rust. Consequently, there is no longer any dst_call-specific code, nor are there any regular expressions. I have no desire to return to the previous state...
See here: https://github.com/glidernet/python-ogn-client/blob/master/parser_v2_migration.md

[iz0qwm]

Hi Meisterschueler,

Thank you for the clarification and for pointing me to the v2 migration documentation.

I understand now that our PR was targeting the legacy Python parser architecture, which is no longer appropriate.

I certainly don't want to reintroduce destination-specific regular expressions or compromise the performance improvements of the Rust parser.

I'll review ogn-parser-rs and evaluate whether any changes are actually needed to support OGNDSC and the optional dscT field, following the current architecture.

In parallel, I'll proceed with controlled feeder testing on OGN TEST using the protocol specification now merged in PR #53.

Thanks again for your feedback and for the work on the new parser!

[Meisterschueler]

@iz0qwm: regarding ogn-parser-rs: please check if this special word (dscT) also applies to any other beacon type. It would be beneficial for the change if it were applicable to various types of beacons (not just OGNDSC beacons).

[iz0qwm]

Hi @Meisterschueler ,

I've completed the analysis of ogn-parser-rs, and your suggestion makes sense.

The dscT field describes measurement timestamp provenance rather than a DSC-specific property, so it can also be useful for other position beacon types.

I've prepared a local Rust implementation that handles the four existing codes (O/G/N/R) independently of dst_call, without regular expressions or changes to the existing timestamp interpretation.

The current parser already preserves dscT as unparsed comment data, so this enhancement is not required for our initial OGN TEST feeder validation.

The Rust patch still needs compilation, tests and performance verification before I submit it upstream.

Thank you for pointing us in this direction!