<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div style="" class="allowTextSelection" role="document"> </div><span class="_rw_b" tabindex="-1"><span tabindex="-1" class="_rw_8"><span class="_pe_l _pe_A _pe_w1 bidi _pe_Z ms-font-s _pe_M allowTextSelection"></span></span></span>Greetings, all.<span class="_rw_b" tabindex="-1"><span tabindex="-1" class="_rw_8"><span class="_pe_l _pe_A _pe_w1 bidi _pe_Z ms-font-s _pe_M allowTextSelection"></span></span></span>
<div id="yui_3_16_0_ym18_1_1458400728365_3928"><br>
</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3891">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 <a href="http://www.tapr.org/pipermail/aprssig/2013-October/042435.html" target="_blank" title="Ctrl+Click or tap to follow the link" id="LPlnk208999">http://www.tapr.org/pipermail/aprssig/2013-October/042435.html</a>
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.</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3980"><br>
</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3981">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.</div>
<div><br>
</div>
<div>So far, I see he has provided the feature subtags:</div>
<ul><li>messaging</li><li>item-in-msg</li></ul>
<div>I am proposing to add the feature subtags:</div>
<ul><li>digipeater (for multi-function software)</li><li>I-gate</li><li>Tx (for receive-only software?)</li><li>Rx (for transmit-only trackers?)</li><li>QRU-client</li><li>QRU-server</li><li>telemetry-Tx
(values could identify what type of telemetry data is sent [such as
voltage and temperature by a Byonics TinyTrak 4])</li><li>Wx or weather (for a station with weather sensors, especially a multi-function station that does more than report weather)</li><li>sensor (value would identify what type of sensor, other than weather station sensors or a GPS)</li><li>query (answers broadcast queries)</li><li>directed_query (answers directed queries, value might be list of query commands answered)<br>
</li><li>telecommand</li><li>timeslot (capable of transmitting in
assigned and configured timeslots to reduce collisions, rather than just
CSMA random access)<br>
</li><li>gps (if one is included in the hardware or configurable in the software)</li></ul>
<div>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.</div>
<div><br>
</div>
<div>Just my $.02.</div>
<div><br>
</div>
<div>Andrew Pavlin, KA2DDO</div>
<div>author of YAAC ("Yet Another APRS Client")</div>
<div><a href="http://www.ka2ddo.org/ka2ddo/YAAC.html" target="_blank">http://www.ka2ddo.org/ka2ddo/YAAC.html</a><br>
</div>
<div><br>
</div>
<div>P.S. To get things started, the feature subtags for YAAC (assuming we keep the above definitions) are:</div>
<div><br>
</div>
<div>messaging</div>
<div>item-in-msg</div>
<div>digipeater: configurable</div>
<div>I-gate: configurable</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3988">QRU-client</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3987">QRU-server: configurable</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3986">Wx: configurable</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3989">query</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3990">directed_query</div>
<div id="yui_3_16_0_ym18_1_1458400728365_3991">timeslot: configurable</div><div dir="ltr">
</div></div></body></html>