[aprssig] APRS-IS and metadata

[Borja Marcos]

> On 17 Aug 2023, at 10:46, Lynn W Deffenbaugh (Mr) <KJ4ERJ at arrl.net> wrote:
> 
> Are you asking for something like this?
> 
> https://github.com/aprsorg/aprs-deviceid
> 
> It exists and is the new repository replacing Bob's old non-parseable ToCall list (http://www.aprs.org/aprs11/tocalls.txt) and adding additional meta-data about the platforms.

Not really. 

Let me present a use case for the metadata I am suggesting.

Imagine that I want to build an APRS map of LoRa (or VARA HF) actiivty. For LoRa, what some guys are doing (for example, the Spanish map)
is querying the database for messages with an APL??? device identifier. Which has been informally agreed to identify APRS LoRa equipment.

However, this scheme has several limitations:

First: What does the device identifier actually identify? Imagine I am using a mobile phone running APRSDroid or APRS.Fi and using a KISS TNC
over LoRa. The device identifier does identify only one of the devices involved, not both. So the fact that the transmission was made through
LoRa would be missed. 

Second: Some developers have agreed on this scheme, but it is still an ad-hoc approach. 

Third: As I explained before, there is relevant information that is actually discarded now. What was the frequency? What was the modulation
employed? (FSK, LoRa, VARA…). Also there are interesting parameters that would be useful as metadata.

Take LoRa, for instance. It is a complex modulation scheme that offers several parameters. You can define a “time spread” (SF) in order to
increase robustness, there is a “coding" parameter that adds forward error correction and of course the bandwidth parameter for the 
spread spectrum transmission. 

If these parameters were available in the databases used for the maps construction we could conduct experiments comparing coverage depending
on these parameters. Adding some more metadata such as packet transmission length (which varies depending on SF) we might estimate 
channel busy time, etc.

All of this information would not be transmitted over the air, so there would be no changes to the APRS protocol. However, iGates themselves,
which of course have the “knowledge” of these parameters, would add them as metadata when forwarding information to the APRS-IS databases.

So, I could build a map with, say, “give me the packets heard within the last 24 hours with these parameters: (PHY=lora, bw=125, coding=5,sf=12).

Such an enriched dataset can even be useful for academic purposes, imagine a student using this data for a MSc dissertation.

And bear in mind that, LoRa being proprietary (although cheap and easy to implement) maybe other schemes will appear. Which makes it
more important to begin to define that metadata.


Hope it’s clearer now ;)


Cheers,





Borja - EA2EKH