#### Re: Different location on APRSIS32 and APRS.fi

Lynn Deffenbaugh

Mystery solved (I believe). Why didn't you TELL us you had POSITION AMBIGUITY enabled on the Kenwood? Here's the translation:

S x53 83. Lat 3 A=1

5 x35 53. Lat 5 B=0

Q x51 81. Lat 1 C=1

L x4c 76. Lat SPACE! - South

Z x5a 90. Lat SPACE! - +100 lon

L x4c 76. Lat SPACE! - East

So, we have 35 1b.bb (b=space) for position ambiguity to only 10s of minutes.
ABC=101 is In Service

And we've got South and +100 East

' x27

M x4d 77. -28 = 49 + 100 = 149 Degrees

4 x34 52. -28 = 24 Minutes

x1c 28. - 28 = 0 Hundredths

l x6c 108. - 28 = 80 *10 = 800 knots?

x20 32. - 28 = 4 /10 = 0 knots, 400 degrees?

x1c 28. - 28 = 0 = 00 degrees

K x4b 75. = Symbol

&#92; x5c 92. = Table

] x5d 93.

Further, if speed >=800, speed -= 800 or 0 knots
if course >=400, course -=400 or 0 heading

And we end up with 35 1b.bbS 149 24.00E 0 knots, 0 heading, &#92;K symbol (Kenwood).

So, basically anything goes on the position because the ambiguity setting says we really don't know WHERE the station SHOULD be, but it should be somewhere around 10 minutes. So anything between 01 and 19 would be just as good a guess for the actual position.

aprs.fi has 35 15.00S 149 25.00E
aprsis32 has 35 10.00S 149 24.00E

aprs.fi seems to have interpreted the ambiguity in the center of where it might have been, but definitely seems to have missed the longitude by 1 degree. APRSIS32 truncated the ambiguity, so I'm actually going to add a ToDo list item to SHOW the ambiguity as described on http://www.aprs.org/symbols.html quoted below. Then at least we'd KNOW that we don't know WHERE the station actually is!

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

*Ambiguity Plots:* . Since not all positions in APRS are known to the same precision, a significant attribute of all APRS symbols is the provision to show the four ranges of ambiguity of 0.1, 1, 10 and 60 nautical miles. . Notice how the object named GUESSED above is not shown with a symbol, but with a circle. This is because this station is transmitting or entered with a 1/10th mile ambiguity with his position. The station's symbol does show up at large area scales, but once you zoom the map below the scale at which the size of the ambiguity is larger than the "size" of the symbol, then the symbol disappears so that there can be no missinterpretation by the person viewing that there is precision where there is not. These ranges of ambiguity are conveyed just like a written position is conveyed. If a position is only known to the nearest degree (60 nm), then only the degrees are sent. . If the position is only known to the nearest minute, then only the degrees and integer minutes are transmitted. . and So on down to Tenths of a minute. If all digits are known, then the position conveys the full precision inherent in APRS which is to the nearest 100th of a nautical mile or about 60 feet.

*Ambiguity in the Spec:* . There has been lots of confusion over Position Ambiguity caused by the poor wording in the spec that can be incorrectly interpreted as implying a truncation of digits and a lat/long box of ambiguity. . It is not a /truncation/ and it is not a box. . The position field in APRS is a string field, not a numeric field. . One should place in that field by /inclusion/ only the digits the sender wants the receiver to use. . Further the spec implies that this results in a box of ambiguity. . This is wrong. because it would imply vastly different sizes of inprecision at the equator and at the poles. . It is clear that the intent of position ambiguity was a range in nautical miles, since Ambiguity was defined in the LATITUDE field only, where the digits do correspond to Nautical Miles. . And they do give the same circular area everywhere on earth.

*Plotting Position Ambiguity:* . The recommended plot of position ambiguity is shown above for GUESSED. . That is, a circle with a radius of the ambiguity centered on the given position. (Not centered in a box of LAT/LONG) . Further, the symbol may be displayed as long as the size of the symbol is larger than the circle of ambiguity. But on higher resolution zooms, when the size of the circle becomes larger than the size of the symbol, then the symbol should NOT be displayed because it implies a location at the center which is incorrect. Only the circle should be displayed at these zooms. . Further, the "center" location of this circle should be slightly randomized (say within half the range of ambiguity) so that if there are many stations reporiting the same location and ambiguity, that all of their circles will show. . These circles are not intended to be precise sizes or edges of ambiguity, but simply a graphical representation to the viewer that these positions are not well known.

Lynn W. Deffenbaugh wrote:

aprs.fi has 35 15.00S 149 25.00E
aprsis32 has 35 10.00S 149 24.00E

That's a pretty big (and visible) difference, I agree. Now, we can only assume that the 710 is correct because it's got the GPS.

aprs.fi has one of your 710 packets as:
2010-03-09 11:24:19 UTC: VK2JNG-12>S5QLZL,VK1RGI-1*,WIDE2-2,qAR,VK1KCM-5:'M4<0x1c>l <0x1c>K&#92;]146.950MHz G'Day to all APRS users.=
type: location
srccallsign: VK2JNG-12
dstcallsign: S5QLZL
latitude: -35.25 longitude: 149.4166666666667 course: 0 speed: 0 km/h
symboltable: &#92;
symbolcode: K
mbits: 101
posresolution: 18520 m
posambiguity: 3
comment: ]146.950MHz G'Day to all APRS users.=

or

*2010-03-09 11:24:19 UTC VK2JNG-12 <http://aprs.fi/?c=raw&limit=&view=hex&call=VK2JNG-12>: 95 bytes*
0x00 V K 2 J N G - 1 2 > S 5 Q L Z L , V K 1 R G I - 1 * , W I D E 2 564b324a4e472d31323e5335514c5a4c2c564b315247492d312a2c5749444532
0x20 - 2 , q A R , V K 1 K C M - 5 : ' M 4 1cl 1cK &#92; ] 1 4 6 . 9 5 2d322c7141522c564b314b434d2d353a274d341c6c201c4b5c5d3134362e3935
0x40 0 M H z G ' D a y t o a l l A P R S u s e r s . = 304d487a2020472744617920746f20616c6c20415052532075736572732e3d

My parser for the same packet gives:

MicE(1) VK2JNG-12 (146.950MHz}G'Day to all APRS users.=)
MicE VK2JNG-12 (146.950MHz}G'Day to all APRS users.=)
Converting rx_lat(3510.00) rx_lon(14924.00)
src:VK2JNG-12 obj: dst:S5QLZL Comment:146.950MHz}G'Day to all APRS users.= Platform:
Hop[0] = VK2JNG-12
Hop[1] = S5QLZL
Hop[2] = VK1RGI-1*
Hop[3] = WIDE2-2
Hop[4] = qAR
Hop[5] = VK1KCM-5

It is apparent to my (programmer) eyes, that aprs.fi and my parser (based on open source Tracker2 code) came up with a different interpretation of the Mic-E packet from the 710. I'll be diving into the packet with the spec in hand to do a manual conversion and will get back to you later with the results.

Lynn (D) - KJ4ERJ - Thankful for this report so one of us can fix things!

PS. I'm acting on the assumption that aprs.fi is showing the location that you know to be correct because you're there, right?

jandgandjochem wrote:

That is correct. Beacons were sent from Kenwood 710 as stated in my first message.

The locations for the beacons of the Kenwood 710 in aprs.fi and aprsis32 differ a fair bit.

I have emailed you a screen clip showing both the APRS.fi and APRSIS32 maps.

I did not have you email address but took it from aprssig.tapr.

Also sent a message to your call via APRS (-12)

If you did not receive the email with the attachement then pls email me.

I was not able to attach the file using Yahoo.

Cheers,
Gerard
VK2JNG

--- In aprsisce@yahoogroups.com, "Lynn W. Deffenbaugh" <kj4erj@...> wrote:

I just looked at VK2JNG-12 raw packets and do not see any beacons that originated from APRISCE or APRSIS32, only from the Kenwood in Mic-E. Therefore we've got no guess as to where the client is showing you relative to where aprs.fi is showing the Kenwood.

Are you running the two systems as the same -SSID? That's usually not a good idea, but I suspect it is not the case here or we would see both beacons in aprs.fi's raw packets.

Lynn (D) - KJ4ERJ

jandgandjochem wrote:

Hi all,
Just noticed that my location for VK2JNG-12 is showing different on the above mentioned maps.

Beacons are transmitted from the same 710 transceiver.

Gerard
VK2JNG

Join APRSISCE@groups.io to automatically receive all group messages.