[aprssig] Part 2: APRS device identifiers (tocalls) in YAML, XML and JSON

[Robert Bruninga]

problm is, it only fits in 6 bytes of a TOCALL.  Not sure then, how you can
add to it.
bob

On Sat, Mar 19, 2016 at 11:41 AM, Andrew Pavlin via aprssig <
aprssig at tapr.org> wrote:

> Greetings, all.
>
> 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 at
> http://www.tapr.org/pipermail/aprssig/2013-October/042435.html 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:
>
>    - messaging
>    - item-in-msg
>
> I am proposing to add the feature subtags:
>
>    - digipeater (for multi-function software)
>    - I-gate
>    - Tx (for receive-only software?)
>    - Rx (for transmit-only trackers?)
>    - QRU-client
>    - QRU-server
>    - telemetry-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)
>    - telecommand
>    - timeslot (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")
> http://www.ka2ddo.org/ka2ddo/YAAC.html
>
> P.S. To get things started, the feature subtags for YAAC (assuming we keep
> the above definitions) are:
>
> messaging
> item-in-msg
> digipeater: configurable
> I-gate: configurable
> QRU-client
> QRU-server: configurable
> Wx: configurable
> query
> directed_query
> timeslot: configurable
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> http://www.tapr.org/mailman/listinfo/aprssig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20160319/56edbb55/attachment.html>