[aprssig] Yag Tracker

[Lynn W. Deffenbaugh (Mr)]

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):

{ "APK0xx", "Kenwood THD7's", PLATFORM_KENWOOD_D7 },
{ "APK003", "Kenwood TH-D72", PLATFORM_KENWOOD_D72 },
{ "APK1xx", "Kenwood D700's", PLATFORM_KENWOOD_D700 },
{ "APK102", "Kenwood D710", PLATFORM_KENWOOD_D710 },
{ "APKRAM", "KRAMstuff.com" },

is my implementation of

  APK  APK0xx  Kenwood TH-D7's
       APK003  Kenwood TH-D72
       APK1xx  Kenwood D700's
       APR102  Kenwood D710
       APKRAM  KRAMstuff.com - Mark. G7LEU

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.

This implementation would have no issue with any of the proposed toCalls 
for the YagTracker.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32


On 1/3/2012 11:30 PM, Greg Dolkas wrote:
> ok, thanks for clarifying.  It would be interesting to know what's 
> actually in use.
>
> 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).
>
> Greg  KO6TH
>
>
> On Tue, Jan 3, 2012 at 7:28 AM, Bob Bruninga <bruninga at usna.edu 
> <mailto:bruninga at usna.edu>> wrote:
>
>     > If APY*** is already given to Yaesu, then APYT**
>     > can't be given to the YAG Tracker,
>     > What does Yaesu "own"...
>
>     TOCALLs are assigned on an equitable basis with sharing where
>     needed.  A
>     decade ago APKxxx, APIxxx  and APYxxx were listed for Kenwood,
>     Icom and
>     Yaesu long before they ever had any radios.  Those were only
>     placeholders.
>     Over time there have been so many applications written, that we
>     have found
>     it necessary to share many such large blocks. Kenwood does not even
>     exclusively have APK, only APK#xx where # is numeric.
>
>     If someone will capture for me all of the existing APYxxx packets
>     currently
>     seen, then we can see if there is an obvious sub block.
>
>     Jason suggests: "OK, lets go with APRYTx"
>
>     I wonder though, if APRRYx would be better since RPC electronics
>     already has
>     APRRxx?
>
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at tapr.org <mailto:aprssig at tapr.org>
>     https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120104/4c4c50f3/attachment.html>