[aprssig] APRS-IS and metadata

Fri Oct 13 19:20:23 EDT 2023

On 8/17/23 00:35, Borja Marcos 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
>
> 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

What's preventing you from just using The Things Network software, or 
just using the open source TTN stack?  Here's a sample of a 
location/tracking packet I sent a few days ago, via TTN:

{
   "end_device_ids": {
     "device_id": "eui-70b3d57ed006140d",
     "application_ids": {
       "application_id": "ab0oo-tracker"
     },
     "dev_eui": "70B3D57ED006140D",
     "dev_addr": "260C5D1B"
   },
   "correlation_ids": [
     "as:up:01HC7YY1AHCWKFENXSQEMFMKSR",
     "gs:conn:01HA2N0WKM169HZQ37BEAG8795",
     "gs:up:host:01HA2N0WQVT7VC902QNBP82G9J",
     "gs:uplink:01HC7YY140G1FW1KV1DXD6TJH5",
     "ns:uplink:01HC7YY142KRTCS742CDB97C4G",
"rpc:/ttn.lorawan.v3.GsNs/HandleUplink:01HC7YY1426JR9RWDWKHJAXSZ6",
"rpc:/ttn.lorawan.v3.NsAs/HandleUplink:01HC7YY1AGEKKKG89NJ8AA9HB5"
   ],
   "received_at": "2023-10-08T15:36:44.624598686Z",
   "uplink_message": {
     "f_port": 10,
     "f_cnt": 15888,
     "frm_payload": "uhpGS2d0AFwZAw==",
     "decoded_payload": {
       "altitude": 92,
       "hdop": 2.5,
       "latitude": 40.853419950808274,
       "longitude": -73.96295869129649,
       "sats": 3
     },
     "rx_metadata": [
       {
         "gateway_ids": {
           "gateway_id": "fngw-10001",
           "eui": "343632383C006E00"
         },
         "time": "2023-10-08T15:36:04.404246Z",
         "timestamp": 1200052764,
         "rssi": -97,
         "channel_rssi": -97,
         "snr": 4.75,
         "location": {
           "latitude": 40.81536406600895,
           "longitude": -73.95029980339051,
           "altitude": 80,
           "source": "SOURCE_REGISTRY"
         },
         "uplink_token": 
"ChgKFgoKZm5ndy0xMDAwMRIINDYyODwAbgAQnLSdvAQaDAiMmYupBhCiudPGASDg+t/F9ryVBA==",
         "channel_index": 4,
         "received_at": "2023-10-08T15:36:44.378675638Z"
       }
     ],
     "settings": {
       "data_rate": {
         "lora": {
           "bandwidth": 125000,
           "spreading_factor": 7,
           "coding_rate": "4/5"
         }
       },
       "frequency": "904700000",
       "timestamp": 1200052764,
       "time": "2023-10-08T15:36:04.404246Z"
     },
     "received_at": "2023-10-08T15:36:44.418225651Z",
     "consumed_airtime": "0.061696s",
     "locations": {
       "frm-payload": {
         "latitude": 40.853419950808274,
         "longitude": -73.96295869129649,
         "altitude": 92,
         "source": "SOURCE_GPS"
       }
     },
     "network_ids": {
       "net_id": "000013",
       "tenant_id": "ttn",
       "cluster_id": "nam1",
       "cluster_address": "nam1.cloud.thethings.network"
     }
   }
}

You can see, it's got ALL the goodies in it:  where I was, what my 
modulation scheme/rate was, who heard me, where THEY were, what my RSSI 
and on-air time was, everything.  If this is what you're asking for in 
terms of meta-data, it's all already out there. Just use it.

BUT, you'll notice that even TTN only offers 24 hours of uplink data 
storage, and even then you have to request it on a per-device basis.  
That kind of data eats hard drives like a fat kid eats birthday cake.  I 
think a lot of this data is really cool, and some of this data could be 
used to make compelling graphs, maps with lines, etc.  You could do all 
kind of cool stuff with it if you could store it...

... BUT:  this isn't what APRS is really about, is it?  It's a tactical 
information system designed to be widely interoperable, stand-alone 
(i.e. no infrastructure needed), and usable in a peer-to-peer 
environment.  All of the add-ons for internet mapping, and 
range-analysis, and path discovery, that's all been added on by geeks 
like me looking to extract cool info and pretty pictures.  Ham radio is 
supposed to work when All Else Fails. Adding tons of level of 
complexity, and meta-data, and things not essential to getting data from 
point A to point B just put that "Works When Nothing Else Does" at risk, 
and that's not what Bob's intention was (IMHO).

There are lots of nails out there, and lots of different hammers and 
other tools.  Pick the one you like and build away, but don't try to use 
the APRS hammer to put in complex security head screws...

de AB0OO
John Gorkos

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xA4025CE04AE176ED_and_old_rev.asc
Type: application/pgp-keys
Size: 2346 bytes
Desc: OpenPGP public key
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20231013/13c07df7/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20231013/13c07df7/attachment.sig>