Hi James, Thanks for the detailed (and patient) explanation of what I can expect out of my APRS station. I think I mostly understand and will let things stay as they are. I was confusing raw packets with packets passed from RF to Internet. I expected to see the data being sent from my station to APRS-IS to show up in the raw packets.
And sorry for the long delay, between the holiday and some 'issues' at work, I'm just starting to get back to having some time to play around a little. Thanks again! Norman KC9NVN -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of James Ewen Sent: Sunday, May 30, 2010 10:58 AM To: Xastir - APRS client software discussion Subject: Re: [Xastir] Still have questions if all is working correctly On Sat, May 29, 2010 at 9:06 AM, Norman Heyen <[email protected]> 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 _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir _______________________________________________ Xastir mailing list [email protected] http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
