[aprssig] APRS-IS and metadata

Scott Miller scott at opentrac.org
Thu Aug 17 18:26:03 EDT 2023


Please no! Let's stop doing that without some planning and coordination. 
There are /so/ many (sometimes incompatible) little extensions out 
there. I'm guilty of introducing a number of them myself.

I'm experiencing that all again with EchoLink right now, having to 
capture packets and pick them apart and figure out that to /this/ 
client, this field means this but only if this other field is zero, but 
to another client that's something else, unless maybe it saw the other 
end use a field differently and then it changes...

Scott
N1VG

On 8/17/2023 2:52 PM, Bob Poortinga wrote:
> Nothing prevents you from using the free text comment section of an 
> APRS position report, object, or status packet for your own needs. 
> Create a software parsable format that is distinct (e.g. starting the 
> comment with "&&") and stuff your meta data there.
>
> Bob W9IZ
>
>
> On Thu, Aug 17, 2023, 4:14 AM Borja Marcos <ea2ekh at gmail.com> wrote:
>
>     Hi,
>
>     I am new to the list, I hope this is the right place to discuss
>     this issue. This is not a complete proposal, of course,
>     just a “weather balloon” ;)
>
>     As many members will be aware, there is an effort underway to use
>     LoRa modulation on 433 MHz for
>     APRS. There are several open source projects which, as a plus, are
>     based on dirt cheap and easy to obtain
>     hardware,
>
>     https://github.com/richonguzman/LoRa_APRS_Tracker
>     https://github.com/dl9sau/TTGO-T-Beam-LoRa-APRS
>     https://github.com/lora-aprs/LoRa_APRS_iGate
>
>     There is also one commercial product available, picoAPRS LoRa. It
>     is more pricey, but, well, all of us know
>     that developing and supporting an actual product is hard.
>
>     http://www.db1nto.de/index_en.php
>
>     All of it is a bit ad-hoc now with no agreed standards (as far as
>     I know). While some of the developers have
>     agree informally to use APL?? device IDs for LoRa based equipment,
>     not every developer is following that
>     rule,
>
>     As far as I know there are also other modems/phys used with APRS.
>     For example VARA on HF.
>
>     I think it would be great to add some metadata to the databses
>     used by the APRS mapping applications including,
>     as a minimum, a modem/phy identification (and frequency, which
>     could be useful for HF) so that they can be
>     more useful to study/check certain kinds of APRS activity.
>
>     Right now, for example, there are dashboards relying just on
>     APL??? device IDs.
>
>     http://lora.ham-radio-op.net/?center=43.3508,-3.0499&zoom=12
>     <http://lora.ham-radio-op.net/?center=43.3508,-3.0499&zoom=12>
>
>     Another interesting possibility offered by a more flexible
>     database model could be adding some metadata specific
>     to certain modems. As an example, LoRa chips can provide RSSI and
>     SNR data which could prove valuable for
>     propagation/coverage studies.
>
>     What do you think?
>
>
>     73,
>
>
>     Borja Marcos / EA2EKH
>
>
>
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at lists.tapr.org
>     http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20230817/843a2d8d/attachment.html>


More information about the aprssig mailing list