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

[spam8mybrain]

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).
Andrew, KA2DDO 

-------- 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.
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:
messagingitem-in-msg
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")
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/d55ea9aa/attachment.html>