Discussion:
odd siting in these here parts
MJ Inabnit
2014-08-30 03:52:40 UTC
Permalink
I can't image why, but aprs.fi shows my car going 600MPH through town.
Is it a joke?

Here's the screen shots. . .

What happened?

tnx, 73

j
--
wishing you well
Jaye, ke6sls--via the acer w/thunderchicken3
Javier Henderson
2014-09-14 14:55:09 UTC
Permalink
I can't image why, but aprs.fi shows my car going 600MPH through town. Is it a joke?
Here's the screen shots. . .
What happened?
You’ve gone quantum.

-jav k4jh
Steve Noskowicz
2014-09-14 15:10:48 UTC
Permalink
Nah. His flux capacitor went into entrainment..That's usually due to vibration causing one of the arms going past the Bernoulli Limit. Tighten the mounting bolts.

73, Steve, K9DCI


________________________________
From: Javier Henderson <javier-PoBB8/***@public.gmane.org>
To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Sent: Sunday, September 14, 2014 9:55 AM
Subject: Re: [aprssig] odd siting in these here parts
I can't image why, but aprs.fi shows my car going 600MPH through town. Is it a joke?
Here's the screen shots. . .
What happened?
You’ve gone quantum.

-jav k4jh
Steve
2014-09-14 15:49:35 UTC
Permalink
Are you in a rush to get to the beach? I had a GPS in my truck that
reported to my office. I got a call because it said I was doing 190 mph
on the mass turnpike. I was going just below 65 mph at the time I spoke
to the boss and asked him if he thought I could go 190 mph in a 6
cylinder Chevy work van with ladders on the roof..He hung up. Steve kb1chu
Post by MJ Inabnit
I can't image why, but aprs.fi shows my car going 600MPH through
town. Is it a joke?
Here's the screen shots. . .
What happened?
tnx, 73
j
_______________________________________________
aprssig mailing list
http://www.tapr.org/mailman/listinfo/aprssig
Keith VE7GDH
2014-09-14 15:54:10 UTC
Permalink
MJ KE6SLS wrote...
Post by MJ Inabnit
I can't image why, but aprs.fi shows my car going 600MPH
through town. Is it a joke?
No. The site aprs.fi is just going by the data received.
Hessu - please read to the end.

While you might occasionally go quantum from time to time,
or your flux capacitor needs adjusting (I have some for sale
pon eBay if you can't get it back in adjustment) there are
other possible explanations.

2014-09-07 14:50:38 PDT:
KE6SLS-9>T0TWUU,WIDE1-1,WIDE2-1,qAR,KE6SLS
:`4&tl!l>/`"3l}146.700MHz T103 -060 Electric cowboy-Waahoo_"

and then after another 14 beacons (that made it to an
iGate) comes this one which looks familiar...

2014-09-07 15:44:04 PDT:
KE6SLS-9>T0TWUU,KE6HEC-3*,WIDE1*,KE6NVU*,WIDE2*,qAR,W6DWY
:`4&tl!l>/ [Rate limited (< 5 sec)]

While it is possible that your GPS is putting out bogus
data sometimes, or if it's possible, your FTM-350 has been
told to use data from the GPS when it doesn't have a valid
fix (no idea of the FTM-350 is capable of that), in this
particular instance, you are dealing with a delayed packet.

The two beacons that I pasted above are (ALMOST) one and
the same beacon. The second one didn't include the frequency
and the comment... 146.700MHz T103 -060 Electric cowboy-Waahoo_"
The first one was heard direct and gated by KE6SLS. The
delayed on was digipeated by KE6HEC-3 and KE6NVU and finally
gated by W6DWY. Either of the digis or the iGate could have
introduced the delay. You could study the raw data for a while
and eventually which was responsible. The two beacons aren't
identical, because the delayed one didn't include the comment,
but the likelihood of two beacons 55 minutes apart having
identical positions is somewhat low.

MJ - while you might be an electric cowboy in the habit of
saying "wahooooo" all of the time, sending it with (almost)
every single beacon makes your beacons much longer. This
reduces time slots available for others, and lessens the
chance of your own beacons from being decoded. Perhaps you
could tell the FTM-350 to just send it every 10 beacons
or whatever.

Digging further, I was gong too say that it appears that you
are using the same callsign-SSID for an "XASTIR-Raspberry Pi Igate"
and that the solution is to use a different SSID for each station,
but see below!

http://aprs.fi/?c=raw&call=KE6SLS-9&limit=100&view=decoded

2014-09-06 11:11:45 PDT:
KE6SLS-9>T0TXRU,WIDE1-1,WIDE2-1,qAR,KE6SLS
:`4a,lR<0x1c>>/`"4'}147.000MHz T103 +060 Electric cowboy-Waahoo_"
type: location
format: mice
srccallsign: KE6SLS-9
dstcallsign: T0TXRU
latitude: 40.80416666666667 °
longitude: -124.1526666666667 °
course: 0 °
speed: 9.26 km/h
altitude: 16 m
symboltable: /
symbolcode: >
mbits: 101
posresolution: 18.52 m
posambiguity: 0
comment: `147.000MHz T103 +060 Electric cowboy-Waahoo_"

The comment in the following one appears to be truncated. I
don't know if aprs.fi truncated it, or if it happened before
it made it to the APRS-IS.

2014-09-06 11:11:47 PDT:
KE6SLS-9>T0TXRW,KE6HEC-3*,WIDE1*,KE6NVU*,WIDE2*,qAR,W6DWY
:`4a.l]w>/`"4&}147.000MHz T103 +060 Electric cowboy-
[Rate limited (< 5 sec)]
type: location
format: mice
srccallsign: KE6SLS-9
dstcallsign: T0TXRW
latitude: 40.8045 °
longitude: -124.153 °
course: 191 °
speed: 11.112 km/h
altitude: 15 m
symboltable: /
symbolcode: >
mbits: 101
posresolution: 18.52 m
posambiguity: 0
comment: `147.000MHz T103 +060 Electric cowboy-

2014-09-06 11:13:36 PDT:
KE6SLS-9>T0TXRW,WIDE1-1,WIDE2-1,qAR,KE6SLS
:`4a,lJk>/`"4/}147.000MHz T103 +060 Electric cowboy-Waahoo_"
type: location
format: mice
srccallsign: KE6SLS-9
dstcallsign: T0TXRW
latitude: 40.8045 °
longitude: -124.1526666666667 °
course: 279 °
speed: 7.407999999999999 km/h
altitude: 24 m
symboltable: /
symbolcode: >
mbits: 101
posresolution: 18.52 m
posambiguity: 0
comment: `147.000MHz T103 +060 Electric cowboy-Waahoo_"

later...

2014-09-06 11:20:15 PDT:
KE6SLS-9>T0TWWY,WIDE1-1,WIDE2-1,qAR,KE6SLS
:`4&Nl|g>/`"3{}147.000MHz T103 +060 Electric cowboy-Waahoo_"
type: location
format: mice
srccallsign: KE6SLS-9
dstcallsign: T0TWWY
latitude: 40.7965 °
longitude: -124.175 °
course: 275 °
speed: 16.668 km/h
altitude: 9 m
symboltable: /
symbolcode: >
mbits: 101
posresolution: 18.52 m
posambiguity: 0
comment: `147.000MHz T103 +060 Electric cowboy-Waahoo_"

Then comes the beacon comment that makes it look like you are
running an XASIR Raspberry Pi IGate.

2014-09-06 11:20:39 PDT:
KE6SLS-9>T0TXRW,KE6SLS,KE6NVU,WIDE2*,qAR,W6DWY
:`4a.l]w>/`"4&}147.<0x03><0xf0>=4203.13N/12417.74WxXASTIR-Raspberry Pi
Igate | Brookings, OR [Duplicate position packet]
type: location
format: mice
srccallsign: KE6SLS-9
dstcallsign: T0TXRW
latitude: 40.8045 °
longitude: -124.153 °
course: 191 °
speed: 11.112 km/h
altitude: 15 m
symboltable: /
symbolcode: >
mbits: 101
posresolution: 18.52 m
posambiguity: 0
comment: `147.<0xf0>=4203.13N/12417.74WxXASTIR-Raspberry Pi Igate |
Brookings, OR

I was going to ask if you were running an XASTIR Raspberry Pi IGate,
or is that coming from somewhere else, but I see that it's the latter.

http://aprs.fi/?c=raw&call=W6DWY&limit=5

2014-09-13 04:56:00 PDT:
W6DWY>APX200,TCPIP*,qAC,THIRD
:=4203.13N/12417.74WxXASTIR-Raspberry Pi Igate | Brookings, OR

While it is entirely possible that you are at times seeing the effects
of delayed packets (caused by a digi or IGate) you are also seeing
the results of an IGate altering your beacons, merging your own
beacon with something generated by the Raspberry Pi IGate.

Hessu - are you watching this? Could this be happening at aprs.fi,
or is it happening back at the R Pi IGate? I suspect the latter,
but perhaps you could come up with an answer.
--
73 Keith VE7GDH
UI-View32
www.ui-view.net
Steve Dimse
2014-09-14 16:47:54 UTC
Permalink
Post by Keith VE7GDH
Hessu - are you watching this? Could this be happening at aprs.fi,
or is it happening back at the R Pi IGate? I suspect the latter,
but perhaps you could come up with an answer.
It is not unusual to see merged packets like this on the APRS Internet System. This particular packet also appears on findU, so it is not a problem in aprs.fi

Steve K4HG
Keith VE7GDH
2014-09-14 17:50:15 UTC
Permalink
Steve K4HG wrote…
Post by Steve Dimse
It is not unusual to see merged packets like this on the APRS Internet System. This particular packet also appears on findU, so it is not a problem in aprs.fi
I should have looked there! Yes, if you are seeing it there too, the XASTIR Raspberry PI IGate must be responsible for mangling the packet.

--
73 Keith VE7GDH
UI-View32
www.ui-view.net
Heikki Hannikainen
2014-09-15 06:19:31 UTC
Permalink
Post by Steve Dimse
Post by Keith VE7GDH
Hessu - are you watching this? Could this be happening at aprs.fi,
or is it happening back at the R Pi IGate? I suspect the latter,
but perhaps you could come up with an answer.
It is not unusual to see merged packets like this on the APRS Internet
System. This particular packet also appears on findU, so it is not a
problem in aprs.fi
Right, it's really very common, and the phenomenon has been there as long
as I've been around. At one point I ran a second APRS-IS packet log
collector client (netcat), which was completely different and independent
of aprs.fi code, just to log the APRS-IS stream to a file with as little
and as simple code as possible, to make sure the merged packets are coming
from the IS and not in my code.

I have a little bit of code on aprs.fi that tries to catch some of these
(looks for double Q constructs and other parts of the packet headers
appearing twice), but with some luck the merging happens so nicely that
it's not possible detect reliably.

Maybe I should at some point try to add some code in aprsc to detect and
count these (but probably not drop), and try to triangulate which clients
they're coming from.

- Hessu

andrewemt
2014-09-14 19:45:10 UTC
Permalink
I've seen these sorts of messages before, and they seem to be due to buffer overruns in some station's receive code. I had horrible overrun issues when first writing an APRS client due to the highly inefficient API's in Microsoft Windows and then Java on top of it, where I actually lost sequences of characters between adjacent frames on a busy channel, such that the end of one frame and the beginning of the next was lost.

This shouldn't be an issue for I-gates, because TCP/IP networking can back-pressure over-fast senders; it's generally only a problem for RF receivers in poorly written clients on slow computers. Are there any really badly-written I-gates with buffer overrun problems (or I-gate clients who use non-blocking sockets to busy APRS-IS servers)?

Andrew, KA2DDO

-------- Original message --------
From: Keith VE7GDH <ve7gdh-***@public.gmane.org>
Date:09/14/2014 13:50 (GMT-05:00)
To: TAPR APRS Mailing List <aprssig-***@public.gmane.org>
Cc:
Subject: Re: [aprssig] odd siting in these here parts

Steve K4HG wrote

Post by Steve Dimse
It is not unusual to see merged packets like this on the APRS Internet System. This particular packet also appears on findU, so it is not a problem in aprs.fi
I should have looked there! Yes, if you are seeing it there too, the XASTIR Raspberry PI IGate must be responsible for mangling the packet.

--
73 Keith VE7GDH
UI-View32
www.ui-view.net
Loading...