| |
ZL3AI > APRDIG 26.02.04 19:16l 259 Lines 9198 Bytes #999 (0) @ WW
BID : 2908-ZL3AI
Read: GUEST
Subj: TAPR Digest, Feb 24, 4/6
Path: DB0FHN<DB0RGB<DB0FSG<I4UKI<IK5CKL<IK1ZNW<ZL2TZE<ZL3VML
Sent: 040226/1643Z @:ZL3VML.#80.NZL.OC #:19894 [Chch-NZ] FBB7.00i $:2908-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: Uncompressed vs Compressed formats
From: "Scott Miller" <scott@3xf.com>
Date: Tue, 24 Feb 2004 19:05:59 -0800
X-Message-Number: 29
My encoding is a bit different. Since I'm already storing the lat/lon
values in 32-bit integers as semicircles (2^31/180 degrees) it's easiest to
start from there. Unfortunately the bias used in Base 91 (90-latitude and
180+longitude) adds another step, but oh well. I've precalculated the
number of semicircles per Base 91 unit for each place, and since I can't
afford the space for long division they're subtracted repeatedly.
And this is why I'm not building an OpenTracker2 with anything less than 32k
of Flash. =]
Scott
N1VG
-----Original Message-----
What many people overlook is that the BASE 91 conversion was designed with
multipler constants that kept the result to SINGLE PRECISION if they
*ignore* the LSB. Ignoring the LSB was *intended* for Microcontrollers.
----------------------------------------------------------------------
Subject: Re: APRS Client Survey
From: "Scott Miller" <scott@3xf.com>
Date: Tue, 24 Feb 2004 19:10:10 -0800
X-Message-Number: 30
Woo hoo! I made the list:
APOT01 1
=]
Is that excluding SSIDs? Any chance of getting a station-list-by-tocall
query?
Scott
N1VG
----------------------------------------------------------------------
Subject: Re: FW: APRS Client Survey
From: Steve Dimse <k4hg@tapr.org>
Date: Tue, 24 Feb 2004 22:19:15 -0500
X-Message-Number: 31
On 2/24/04 at 9:24 PM Christensen, Eric <CHRISTENSENE@MAIL.ECU.EDU> sent:
>I guarantee that you WILL see the results of this one... Hey, this could be
>considered extra credit for my Business Statistics class... Hmmm... :)
Hope they teach business people about sampling bias ;-)
In medicine, a self-selected sample like this is considered completely
invalid.
One easy example...APRSdos will almost certainly be under-represented, as
dos cannot connect to the internet, so they would be less likely to have
email capability and therefore unable to find out about your survey.
If someone really wants to get closer to the answer, you either need to do
a random sampling (contact a few thousand hams worldwide, and have them
return a questionaire--too difficult and expensive to happen), or make an
attempt to measure the entire population. Instead of putting the effort
into an invalid sampling, perhaps someone would consider an attempt at
whole-population measuring.
Here is a sample set of the position packets heard from 1000 different
stations (I truncated the packets for size purposes.
http://www.findu.com/1000packets.txt
If anyone develops a program that can analyze these for destination call,
I'll be glad to post packets for the 10 days findU keeps the unique
position list, current numbering over 32000 stations. APRSworld might be
even better for this, as last I heard Jim parsed out the to-calls, findU
does not.
Of course, using this means digging into the TO-CALLs actually used by
client programs, it is possible they are not consistantly enough applied to
allow differentiation between them, but I don't think anyone has ever
looked at the whole spectrum of APRS data.
Even if each client has a unique signature, and you extract stats from the
full sample, there are still potential sources of bias (e.g. are hams in
areas without Igates more likely to use program xyz?), but it will be much
less likely to be biased than the proposed method.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: Uncompressed vs Compressed formats
From: Jeff King <jeff@aerodata.net>
Date: Tue, 24 Feb 2004 22:21:23 -0500
X-Message-Number: 32
On Tue, 24 Feb 2004 21:21:28 -0500, Robert Bruninga wrote:
>>>>Jeff King <jeff@aerodata.net> 2/24/04 7:18:38 PM >>>
>
>>The problem with the APRS compressed format, is it is Base 91, and
>>it is a real pig to code up on a microcontroller. Ask Steve Bragg
>
>>of the HamHud group why he doesn't support the APRS compressed
>>format. He already tried, and it blew his code space budget.
>
>Then I think he missunderstood it.
If anyone misunderstood it, it was his compiler. Then again, did it really?
He showed me a test he ran, on how much it expanded the code. Micro
controllers are alot different then dos or windows programming.
In any case, starting from scratch, OpenTrac is far far better then the Base
91 APRS compressed format IMHO. And it is not entirely clear to me if Base 91
format is widely supported. Remember what you where trying to do when you
devised Base 91.... you wanted a accurate and printable code... you got it,
but it came at a price. Starting from scratch, is a luxury but in this case
it makes the parser/encoder so much easier.
>That should take 1 line of assembler
Can I put that expression on a T-Shirt? You must be related to a boss I once
worked for :-0
I'm copying this to Steve Bragg to see if he has any comments (and I'll
forward your full reply as well).
Regards,
----------------------------------------------------------------------
Subject: Re: FW: APRS Client Survey
From: "Christensen, Eric" <CHRISTENSENE@MAIL.ECU.EDU>
Date: Tue, 24 Feb 2004 22:35:31 -0500
X-Message-Number: 33
You are exactly right, Steve. Unfortunately I don't have the time or money
to go out and do such a large and investigative research project like
that... Hmmm... Maybe if I can get a random sample of the APRS users on
findU (but can you say that 100% of the users are on findU???) I could make
a QSL-style card and send it out for folks to return...
Hmmm...
That may be a future project, but not right now... :)
Eric KF4OTN
-----Original Message-----
From: Steve Dimse [mailto:k4hg@tapr.org]
On 2/24/04 at 9:24 PM Christensen, Eric <CHRISTENSENE@MAIL.ECU.EDU> sent:
>I guarantee that you WILL see the results of this one... Hey, this
>could be considered extra credit for my Business Statistics class...
>Hmmm... :)
Hope they teach business people about sampling bias ;-)
In medicine, a self-selected sample like this is considered completely
invalid.
One easy example...APRSdos will almost certainly be under-represented, as
dos cannot connect to the internet, so they would be less likely to have
email capability and therefore unable to find out about your survey.
If someone really wants to get closer to the answer, you either need to do a
random sampling (contact a few thousand hams worldwide, and have them return
a questionaire--too difficult and expensive to happen), or make an attempt
to measure the entire population. Instead of putting the effort into an
invalid sampling, perhaps someone would consider an attempt at
whole-population measuring.
Here is a sample set of the position packets heard from 1000 different
stations (I truncated the packets for size purposes.
http://www.findu.com/1000packets.txt
If anyone develops a program that can analyze these for destination call,
I'll be glad to post packets for the 10 days findU keeps the unique position
list, current numbering over 32000 stations. APRSworld might be even better
for this, as last I heard Jim parsed out the to-calls, findU does not.
Of course, using this means digging into the TO-CALLs actually used by
client programs, it is possible they are not consistantly enough applied to
allow differentiation between them, but I don't think anyone has ever looked
at the whole spectrum of APRS data.
Even if each client has a unique signature, and you extract stats from the
full sample, there are still potential sources of bias (e.g. are hams in
areas without Igates more likely to use program xyz?), but it will be much
less likely to be biased than the proposed method.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: APRS Client Survey
From: Mark Cheavens <mcheavens@usa.net>
Date: Tue, 24 Feb 2004 21:40:47 -0600
X-Message-Number: 34
What needs to happen is NOT to look at the destination address first, the
query should decode the raw packet (since it already has to for position
information) then the true destination address even in MIC-E packets could
be seen.
Mark Cheavens
KC5EVE
----------------------------------------------------------------------
Subject: RE: APRS Client Survey (this has lots of lines!)
From: "Germino" <mgermino@sbcglobal.net>
Date: Tue, 24 Feb 2004 19:43:07 -0800
X-Message-Number: 35
Off my home station this is what I found. The address is in the same order
as the top 8 on the world list. Looks like there can be a regional bias.
Mike
AD6AA
APRS 26
APU25H 2
APU16N 1
APW251 6
APU25E 0
APT310 8
APU25J 13
APW272 5
*************************************************
>>
>>However, the destination address of APRS is the most common, and,
>>AFAIK, is used by ALL software at some point. Or maybe none. At least, I
>>can't recognize what software defaults to the address of APRS.
>>
>>APRS 3271
>>APU25H 2102
>>APU16N 954
>>APW251 529
>>APU25E 368
>>APT310 353
>>APU25J 346
>>APW272 307
>>APS221 268
>>APD214 233
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
