Architecture
Asv.Gnss follows the Asv.IO protocol and router model. The application composes protocol parsers, features, ports, device discovery, and microservices at startup.
Runtime flow
The usual setup sequence is:
Create a
Protocolwith the required GNSS protocol registrations.Enable router features such as broadcast and endpoint tagging.
Create a router.
Add serial, TCP, UDP, or server ports.
Subscribe to router messages or create a
DeviceExplorer.
Source layout
Directory | Responsibility |
|---|---|
| GNSS device factory registration and device-level integration. |
| Receiver-facing client helpers and service abstractions. |
| Parser modules that are not modeled as the main |
| Protocol definitions, factories, message models, and serializers. |
| Diagnostic command-line workflows. |
| Protocol fixtures and regression tests. |
Extension registration
Protocol registration is exposed through extension methods, for example:
This keeps application startup explicit: only the protocols you register are added to the runtime pipeline.
Stateful file protocols
RINEX uses the same registration, message factory and parser interfaces as byte-stream protocols. A parser instance owns its current file header; factory-created record models receive that context before decoding. Observation type changes in flag-4 events replace the context for later epochs without rewriting earlier messages. Complete() marks EOF and validates the last record. RinexFile handles stream ownership, gzip detection and cancellation for file-oriented callers.