<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
APRSISCE/32 translates toCalls to Platforms via a lookup table that
prefers more specific and then resolves down to less specific
supporting both N (numeric) and X (alphanumeric) wildcards. For
instance (last matching entry wins):<br>
<br>
{ "APK0xx", "Kenwood THD7's", PLATFORM_KENWOOD_D7 },<br>
{ "APK003", "Kenwood TH-D72", PLATFORM_KENWOOD_D72 },<br>
{ "APK1xx", "Kenwood D700's", PLATFORM_KENWOOD_D700 },<br>
{ "APK102", "Kenwood D710", PLATFORM_KENWOOD_D710 },<br>
{ "APKRAM", "KRAMstuff.com" },<br>
<br>
is my implementation of <br>
<br>
APK APK0xx Kenwood TH-D7's<br>
APK003 Kenwood TH-D72<br>
APK1xx Kenwood D700's<br>
APR102 Kenwood D710<br>
APKRAM KRAMstuff.com - Mark. G7LEU<br>
<br>
So you see, the standard has already defined specific sub-sets of
the generic APK definition for "Kenwood" where one of them is not
even Kenwood, but KRAM.<br>
<br>
This implementation would have no issue with any of the proposed
toCalls for the YagTracker.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
<br>
<br>
On 1/3/2012 11:30 PM, Greg Dolkas wrote:
<blockquote
cite="mid:CAHrzzApNsxu1J4_xWciMKBGOKhf96FckvKd8Nzvsp6h221P-bQ@mail.gmail.com"
type="cite">ok, thanks for clarifying. It would be interesting to
know what's actually in use.<br>
<br>
But the other side of the question was what currently is
implemented on the server side. Is there existing software out
there that has all three characters wildcarded? If so, then we
can re-define to our heart's content, but the new allocations will
be mis-decoded until the software changes (if it's still
supported).<br>
<br>
Greg KO6TH<br>
<br>
<br>
<div class="gmail_quote">On Tue, Jan 3, 2012 at 7:28 AM, Bob
Bruninga <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:bruninga@usna.edu">bruninga@usna.edu</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left:1px solid
rgb(204,204,204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
> If APY*** is already given to Yaesu, then APYT**<br>
> can't be given to the YAG Tracker, <br>
> What does Yaesu "own"...<br>
<br>
TOCALLs are assigned on an equitable basis with sharing where
needed. A<br>
decade ago APKxxx, APIxxx and APYxxx were listed for Kenwood,
Icom and<br>
Yaesu long before they ever had any radios. Those were only
placeholders.<br>
Over time there have been so many applications written, that
we have found<br>
it necessary to share many such large blocks. Kenwood does not
even<br>
exclusively have APK, only APK#xx where # is numeric.<br>
<br>
If someone will capture for me all of the existing APYxxx
packets currently<br>
seen, then we can see if there is an obvious sub block.<br>
<br>
Jason suggests: "OK, lets go with APRYTx"<br>
<br>
I wonder though, if APRRYx would be better since RPC
electronics already has<br>
APRRxx?<br>
<br>
<br>
_______________________________________________<br>
aprssig mailing list<br>
<a moz-do-not-send="true" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a><br>
<a moz-do-not-send="true"
href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig"
target="_blank">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@tapr.org">aprssig@tapr.org</a>
<a class="moz-txt-link-freetext" href="https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
<br>
</body>
</html>