[Xastir] Still have questions if all is working correctly

[James Ewen]

On Sat, May 29, 2010 at 9:06 AM, Norman Heyen <n.heyen at comcast.net> wrote:

> I think I see what you are saying but I still don't see why there aren't
> more raw packets for my station.

That would be because you are only sending position reports once every
30 minutes. No one out there is going to magically create packets for
you. 8)

> If I look at another local station, say
> N9QIP, I see there are:
> (a) lots more packets sent out. I don't think he is configured to beacon
> randomly every few seconds

Okay, so you're going to look at a station that is doing silly things,
and try and replicate what he's doing, rather than continue doing what
you are, which is playing nicely with others...

It looks like N9QIP probably has a packet written to one of his LT
buffers that gets sent every 30 minutes, offset by 4 minutes. He's
running UI-View, which is probably sending the same packet every 30
minutes offset by 2 minutes. (Which would explain why there are
identical 2 packets sent 2 minutes apart every 30 minutes. (It's been
a while, but I think you can tell UI-View to write your position
report to the TNC LT buffer, which probably happened in this case, and
the operator doesn't realize that the double beacons are happening)

UI-View is also sending out an advertising packet (status text)
>221202zUI-View32 V2.03, that does nothing except tell us what version
of software he was running just after midnight on the 22nd.

He's also sending a packet that tells us how many messages and
locations he's heard in the last hour.

> (b) many of the packets contain station ID's where it looks like there is a
> path involved. Examples are like these:
> 2010-05-29 00:04:27 CDT:
> N9QIP>APU25N,K9ESV-3*,qAR,W9MKS-15:>221202zUI-View32 V2.03
> 2010-05-29 01:34:24 CDT:
> N9QIP>APU25N,K9ABC-1,K9ESV-3*,qAS,K9IJ:=4320.16NI08923.41W&PHG6550/ - N9QIP
> I-GATE {UIV32N}

Well, he's connected directly to the internet, so all of these SHOULD
get to the APRS-IS stream through his connection well before they can
be sent over the air at 1200 baud, let alone be digipeated, and then
injected by another station. The most logical explanation I can come
up with is that his internet connection has the hiccups... for some
reason there was enough delay between his home station and the APRS-IS
stream that someone else beat him to the punch.

> While it looks like I'm doing my part, I don't understand why the traffic I
> must be sending to APRS-IS isn't showing up. Shouldn't there be a packet
> recorded for everything that I send to APRS-IS?

Yes there is... http://aprs.fi/?c=raw&call=KC9NVN

> When I go to the 'station tracing' mode on APRS.FI (where you can hover the
> mouse over a station and see the path traced out - not sure what it is
> really called), I can see that several stations go from one to another and
> finally terminate at my station. But there is no evidence of that in the raw
> packets seen. My Xastir monitor window is pretty busy, a new line every few
> seconds, so something seems to be happening. But I don't see the red
> transmit LED come on.

Okay, we need a little APRS primer session... First off, looking at
your station on the map, you are advertising that you are a WIDE1-1
fill-in digipeater. Are you configured to act upon a hop alias of
WIDE1-1? If so, the only time your station will key up and retransmit
any incoming packet will be when the next to-be-digipeated path
statement is WIDE1-1. If there's anything else in the next
to-be-digipeated path statement, you will simply listen to it, and
(since you are configured as an i-gate) send it to the APRS-IS.

I found a station in your area that hopped around a little bit, and
was gated by your station.

2010-05-29 16:44:39 MDT:
N66AP>T2SW9S,N9QIP-6*,KA9BAB-13*,WIDE2*,qAR,KC9NVN:`u?vsTS'/"9O}KD0FPN
RV6A

Let's analyse this packet, but first realize that this is a seriously
BAD example of APRS operations. This is an aircraft flying in your
area. This packet is from when he was doing a circuit at the Monroe
Municipal Airport. He was at 1000 feet ASL, running a path of
WIDE1-1,WIDE2-1. Aircraft should NEVER run WIDE1-1. WIDE1-1 is
designed to help low powered stations get into the network. I don't
care how low power your radio is, when you are over 500 feet in the
air, you're going to get into a digipeater, you don't need help from a
home fill-in. Airborne stations should at most run WIDE2-1. (Off that
soapbox!)

So, back to the packet. N9QIP-6 acted upon the WIDE1-1, replacing that
with it's callsign, and then KA9BAB-13 used up the WIDE2-1, inserting
it's callsign, and then marking the WIDE2* path as used up. At that
point, you heard the packet, and gated it to the internet. (BTW,
N9QIP-6 is running UIDIGI, but not doing proper callsign
insertion/replacement)

So, you CAN see that there is evidence in the raw packets that you are
gating stations. The evidence is in the raw packets of the stations
that you are gating, not in YOUR raw packets.

I'm not going to try and find a packet showing you acting upon a
WIDE1-1 path request, simply because your station appears to be
running very well, and I would need to find a situation where your
internet connection screwed up, and someone else gated the packet.
When your station hears someone asking for a WIDE1-1 hop, it will key
up and retransmit that packet (assuming that you are configured to do
that properly), but it will also gate the packet it heard (without
your callsign inserted yet), so it would look like you never acted
upon the packet from the evidence seen on the APRS-IS stream.

> Is it because I'm sort of isolated and there just isn't anyone else to
> receive packets? It is almost like getting to APRS-IS is the end game, the
> final goal. But I don't think that is how APRS is supposed to work.

The APRS-IS stream is not the end game... for some, it might be
though. Some people might just want to get packets to the APRS-IS so
their family can see where they are.

The problem is that you are still thinking that you will be able to
see EVERYTHING on the APRS-IS stream. Remember what I told you last
time. The APRS-IS stream is HEAVILY FILTERED... HEAVILY FILTERED.

Only the first copy of ANY packet sent to the APRS-IS is kept, all
others are ignored. Take a look at N66AP's track for an example:
http://aprs.fi/?call=N66AP

Look at the last 24 hours, and zoom out to get a good look. See how
many digipeaters he hit, and how many i-gates pushed data to the
APRS-IS during that trip. When you hover over a single dot, you only
see one line showing the path the packet took. There are many cases
where the line goes dozens of miles to a digipeater, passing 4 or 5
closer digipeaters, or even an i-gate or 2... Does this mean that
those stations never heard the packet? Probably not... maybe one or
two might have missed it due to a closer station clobbering his
packet, but you can be pretty sure that just about all the stations
within 50 or 60 miles heard his packet. The digipeaters all acted upon
the packet, and the i-gates forwarded the packet to the APRS-IS. But
the only thing we see on the APRS-IS stream is the first copy of that
packet, that perhaps went through a digipeater located 50 miles away,
which was heard by an i-gate 30 miles from there... the other slow
pokes don't show.

The fact that we see these long distance paths over multiple hops are
really amazing, since you would think that a close igate hearing the
packet direct should be able to get the packet to the APRS-IS stream
much faster.

If the APRS-IS stream didn't filter, you would end up seeing a huge
spiderweb of paths as the packets ricochet around the RF network,
especially from airborne stations running WIDE1-1,WIDE2-1 or worse!

> Again, thanks for the detailed explanation and your patience leading me out
> of the realm of APRS mystery...

It's no mystery... just plain old logic. Computers just do what they
are told, it's the silly humans that screw it all up and make it look
more mysterious than it is.

James
VE6SRV