[aprssig] APRS roadmap planning proposal

Scott Howard showard at nd.edu
Sun Feb 13 13:02:25 EST 2022


Hello everyone,

I'd like to take a stab at synthesizing discussions on the multiple threads
into actionable items, with the goal of coming up with the 3 month goal
with > 50% likelihood of success as was suggested. Below is a summary of
the conversations (IMO), and I think goal #1 below is reasonable to aim for
in 3 months.

In order of apparent priorities:
1) Maintenance of APRS as written.
1.1) Take inventory of all the documents (1.0, 1.1, the proposed 1.2, all
the other notes on aprs.org). Create a public repository of these documents
maintained as a team on something like github. This is a community resource
(not gatekeeping) and a place where several people in a team have commit
access to the new "home" of the APRS specification documents.
1.2) Create a mechanism for assigning and publishing new tocalls or any
other thing that needs active maintenance. (This includes machine readable
version of tocalls.txt). Probably simply github issues/pull requests with
someone verifying that it hasn't been used before.

2) Make APRS as written clearer/easier.
2.1) Possibly publish APRS 1.2 that clearly synthesizes all the errata and
features that are currently in practice. This should be done in an open and
transparent way. IMO, this spec should be published under an open-source
license and essentially be non-controversial (i.e., no changes to practice).
2.2) Organize APRS 1.2 spec documentation around encapsulation based on OSI
layers. This makes it easier to understand, to write software for
(separate libraries/classes/modules for each layer), and to help future
innovations/iterations consider changes to one layer (e.g., new radio
modes) in a way that won't affect others. Such encapsulation makes it easy
to articulate how one is experimenting with FX.25 alongside AX.25, for
example.
2.3) Investigate potential depreciation candidates in the current spec.
Depreciation does not mean "no longer supported." Deprecation just means
"if you're making a new application, please don't use this feature. But
your application should probably be compatible with someone else with
legacy hardware/software using this feature."
2.4) Possibly create a "best practices" guide that is seperate from the
specification document that covers both digipeaters and individual
stations/users.

3) Make APRS extensible in a backwards-compatible way (both on the physical
layer and the presentation/application layers). Rather than trying to "pick
a winner" as to what we should do next (what bands/modes? should we use
something like protobuff?), come up with how APRS can be experimented with
in a way that's compatible with the network. Bob made a huge innovation
getting APRS up and running. Let's keep that legacy moving forward by
allowing others to use APRS as the tool in driving innovation.
3.1) Figure out how to make the physical layer extensible
3.2) Figure out what an extensible presentation/application layer looks
like.
3.3) Is this a new APRS 1.3, or is this just built on top of and using the
existing spec?

I propose that we start off with just #1 above, but keep a list of future
things to think about on the roadmap so they are not lost.

To get this done, we'd need a team of volunteers and someone to organize
them. Volunteers are needed from the software, hardware, and end-user
perspectives (we have had a bunch step forward covering all of that
already!) Since the goal is to serve the community, IMO everything should
be done in the open with opportunity for public feedback - so there's
opportunities for people to casually inspect what's happening.

For coordinator (at least for #1), I'd nominate Hessu because of his
perspective and expertise in the APRS ecosystem. However, I don't want to
volunteer him if he's busy with all the work in maintaining a bunch of the
APRS infrastructure. If no one else is interested, I'd volunteer to
coordinate #1 above. (I put my background below as an introduction). But if
there is anyone else that is well positioned to coordinate, then I'm happy
to help out any way I can - I don't want to step on any toes.

What are people's thoughts about the above roadmap and beginning
coordinating #1?

Cheers,
Scott (KD9PDP)

Background: university professor in electrical engineering. Presented at
DCC in 2020 on packet based image transfer that's robust to packet loss
(compatible with APRS, but not intended for use on the APRS network).
Faculty advisor to the student club developing a cubesat. As part of that I
have helped them with 2 HAB launches and designed the software and hardware
for APRS telemetry during flight (modified lightAPRS to include custom
telemetry payloads, and designed+fabricated fast key-off digital mode PCBs
so students could use low-power HTs to test APRS with direwolf.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220213/9b3af5f8/attachment.html>


More information about the aprssig mailing list