It's examples like this that illustrate some of the holes in APRS documentation, especially in the area of documentation targeted to the new user.
I think Lynn's observation of the two layers of APRS communications (RF and Internet) was both helpful and confusing at the same time. It was helpful in clarifying the two types of APRS uses (to send packets by RF to other HAMs and to get packets into the APRS-IS). At the same time, it was confusing in that it's challenging to try to optimize for one without sacrificing the other (at least insofar as I understand how things work). For RF coverage (i.e. to be picked up by other RF stations), the goal is to go out as far as necessary to get picked up by someone else on the road. I understand the logic in the reference Lynn provided below however, I can also see why someone would want to "add a little extra" (i.e. use WIDE2-2 instead of WIDE2-1) "just to be on the safe side." (The APRS version of "adding a little just for grandma.") The problem is there's no easy way for someone to know if that's actually helping or hindering the situation, depending on how many digipeaters you actually hit as you travel. It would help if that resulted in your packets reaching some form of civilization or fellow traveller but it could hinder if the extra hops result in QRM so neither your packet or other colliding packets are heard. For I-gating, all you need is to be heard by a station that's connected to the internet. Unfortunately, it's difficult for a traveler to know how many hops they'll need (or watts of TX power) to reach one. Of course if you want to reach both the internet AND other RF stations, optimizing for RF station coverage can result in lots of internet dupes (which is probably why the dupes are filtered). Some ideas... The path simulator. While I can understand how some HAMs might see a challenge in pinging as many stations as possible, I think the vast majority would rather be good citizens. The fact that any such slamming activity would be public (and very visible by using the same tool) should be enough for things to work themselves out naturally. Worst case, filter the offender's call sign from being digipeated. I don't think that'd be necessary (too often, anyway). An I-gate database that you could download to your GPS as waypoints. Then, though profile switching you could expand or contract your path accordingly. I don't know, but you might even be able to make that a script. (e.g if there's an i-gate within X miles, use profile 1, else, use profile 2). Some sort of feedback to the APRS mobile. This wouldn't work for the TX-only beacons, but for smarter mobile units like the Tracker2, set it up so that if the tracker hears it's call sign being repeated by a digipeater it knows it's packets are being received and rebroadcast so it switches to a short path (WIDE2-1, for example). If it doesn't, it bumps it up a notch to WIDE2-2. What would be even better would be some sort of flag in the digipeated packet that says it's already been sent to the Internet. That way: a) the sending station would know that it's packet had made it to the internet and b) other Igates that pick up the digipeated packet would also know. Finally, on the QRM reduction wish list, would be some way to get feedback to use for adjusting the radio transmitter power. This, of course, requires a suitable interface on the radio to adjust TX power. What would happen, the APRS tracker would listen for its own packets being digipeated (as above) and then dial down the power as needed. There are a number of ways to figure out the best power: trial and error being the brute force approach, another might be to include a received signal strength value in the digipeated packet and the tracker could raise or lower the power of subsequent transmissions based on that value. If the tracker doesn't hear its packet, then it just uses the longest path and the most power. If it does, it trims things down as needed. Anyway, these are just some casual thoughts for a Friday morning. 73 --bob K7RBW --- In [email protected], "Lynn W. Deffenbaugh (Mr)" <ldeff...@...> wrote: > > James Ewen wrote: > > The usual recommended national path would be the best bet... wandering > > off into the unknown and choosing a long path just in case is probably > > not the best bet. No matter what, you're going to find holes in the > > APRS network coverage. > > > > http://www.aprs.org/newN/APRSpaths.gif > from: http://www.aprs.org/fix14439.html > > Lynn (D) - KJ4ERJ >
