[aprssig] Part 2: APRS device identifiers (tocalls) in YAML, XML and JSON
spam8mybrain at yahoo.com
Sat Mar 19 17:49:32 EDT 2016
No, not to the tocall itself, but in Hessu's XML and JSON databases that associates make, model, and capabilities with each tocall. For example, by identifying APK003 as a Kenwood TH-D72, you can then infer stations using that tocall are capable of text messaging, and theoretically could be configured as a digipeater (but isn't out-of-the-box).
-------- Original message --------
From: Robert Bruninga <bruninga at usna.edu>
Date: 03/19/2016 1:40 PM (GMT-05:00)
To: Andrew Pavlin <spam8mybrain at yahoo.com>, TAPR APRS Mailing List <aprssig at tapr.org>
Subject: Re: [aprssig] Part 2: APRS device identifiers (tocalls) in YAML, XML and JSON
problm is, it only fits in 6 bytes of a TOCALL. Not sure then, how you can add to it.
On Sat, Mar 19, 2016 at 11:41 AM, Andrew Pavlin via aprssig <aprssig at tapr.org> wrote:
I was delighted to see that Hessu is still keeping his YAML, XML, and
JSON dumps of the APRS tocall database up to date (see thread starting
for details of what I'm typing about). However, I'm wondering if it
could be improved beyond the basic station "class" to add more
information about hardware or software capabilities.
I'm thinking of optional attributes describing specific capabilities
of the hardware/software, where the attribute is simply missing if Hessu
doesn't know and the device/software creator won't tell him, and exists
with suitable values if Hessu (and helping friends) do know. Hessu has
already defined a "features" subtag and missing attributes here means
the feature either doesn't exist on the specified hardware or software
or it is unknown whether it exists(per my previous statement). I suppose
this is OK, but clarifying this ambiguity by adding optional subvalues
to the feature names to say "configurable" (user has to explicitly turn
it on, not there by default) or "always" (can't be turned off) or "no"
or "never" (for features normally expected but not available, such as
receiving on a transmit-only tracker) might be useful. His classes are
useful, but don't necessarily describe all of what a particular device
or program can do. For example, KJ4ERJ's APRSIS32 program is listed as
class "software", but it is capable of functioning as an I-gate if
configured to do so.
So far, I see he has provided the feature subtags:
I am proposing to add the feature subtags:
digipeater (for multi-function software)I-gateTx (for receive-only software?)Rx (for transmit-only trackers?)QRU-clientQRU-servertelemetry-Tx
(values could identify what type of telemetry data is sent [such as
voltage and temperature by a Byonics TinyTrak 4])Wx or weather (for a station with weather sensors, especially a multi-function station that does more than report weather)sensor (value would identify what type of sensor, other than weather station sensors or a GPS)query (answers broadcast queries)directed_query (answers directed queries, value might be list of query commands answered)
telecommandtimeslot (capable of transmitting in
assigned and configured timeslots to reduce collisions, rather than just
CSMA random access)
gps (if one is included in the hardware or configurable in the software)
This additional information might help software authors better figure
out what functions to enable for a particular remote station. For
example, there's no point in giving a user the option to ask for the
heard station list on a transmit-only tracker that won't hear anything,
let alone the query to list what it heard.
Just my $.02.
Andrew Pavlin, KA2DDO
author of YAAC ("Yet Another APRS Client")
P.S. To get things started, the feature subtags for YAAC (assuming we keep the above definitions) are:
aprssig mailing list
aprssig at tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig