[aprssig] Yag Tracker

[Lynn W. Deffenbaugh (Mr)]

Based on about 7 days of full feed, here's the following packet counts 
for APK toCalls.

APK001 	64
APK002 	96
APK003 	1164
APK01 	1
APK101 	3869
APK102 	58024
APK-2 	1
APK391 	1
APKALL 	8
APKD70 	1
APKPC3 	3003
APKRAM 	8413


I've attached a CSV file of all of the accumulated toCalls from my 
database as well.  There's some pretty strange stuff out there.

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

PS.  APRSISCE:

APWM06 	160
APWM07 	373
APWM08 	109189


APRSIS32:

APWW01 	3
APWW02 	18
APWW03 	3
APWW05 	2369
APWW06 	3328
APWW07 	11770
APWW08 	618303
APWW08-2 	1
APWW08-5 	1
APWW08-6 	1
APWW08-9 	1
APWW08PIP 	1


UI-View by comparison (only the main APU25N and corrupted variants):

APU25N 	3127718
APU25N-1 	3742
APU25N-4 	1
APU25U-2 	1



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/e04a88dd/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: toCalls.csv
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120104/e04a88dd/attachment.csv>