Skip to content

Capability: a receive-only IGate #206

Closed
2 of 2 issues completed
Closed

Description

@gx1400

Goal: aprscli serve can upload what its TNCs hear to APRS-IS as a receive-only IGate, with the gating rules and q-constructs APRS-IS expects. The gateway already reads TNCs and holds an APRS-IS login, so most of the work is the rules.

This starts AprsNet.IGate with the RF-to-internet direction. 0.7.0 adds the internet-to-RF direction that makes it a full IGate.

Receive-only IGates are known to break messaging: stations nearby think they can be reached through the IGate, but messages never come back to them on RF. The docs say so, and point to the two-way IGate in 0.7.0.

Done when:

  • a live run with a verified login uploads packets heard on RF, and they show on aprs.fi with qAO (aprs-is.net: receive-only IGates use qAO, not qAR) and the IGate's call;
  • the IGate beacons its own position to APRS-IS, as IGates are expected to;
  • it is in a release.

Activity

  1. added this to the 0.6.0-alpha.1 milestone on Oct 17, 2026
  2. added
    capabilityA release goal; its sub-issues are the work
    priority: mediumPlanned for the milestone, after the high ones
    on Oct 17, 2026
  3. added
    blocks: AprsMapBlocks an AprsMap feature issue; see its milestone in APRS-NET/AprsMap
    on Oct 20, 2026
  4. gx1400 commented on Oct 21, 2026

    @gx1400
    ContributorAuthor

    Done: the gating rules (#207) and aprscli serve --igate checked live (#208).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    blocks: AprsMapBlocks an AprsMap feature issue; see its milestone in APRS-NET/AprsMapcapabilityA release goal; its sub-issues are the workpriority: mediumPlanned for the milestone, after the high ones

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions