[aprssig] Designating HOME Igates
Robert Bruninga bruninga at usna.eduSat Jun 18 00:55:39 UTC 2005
- Previous message: [aprssig] Designating HOME Igates
- Next message: [aprssig] Designating HOME Igates
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>> I disagree. >> Every APRS operator has a home area, and >>being able to have the system deliver his >>traveling packets effeciently back to his "home" >>should be a significant part of the job of APRS. > >Why? The operators in our coverage area would >rather not have somebody beaconing on our >RF frequency... regardless of whether that person >is "from" here. If the person is driving locally and then leaves for a trip he still is one person in your area and I think in most friendly APRS areas, the locals like to keep up with each other as they travel. The load on the local network doesnt change whether he is local or driving across the USA. > And your "plan" does nothing to enforce those >packets to be from a formerly "local" station >(because you can't do it). My original plan did. I had proposed that the request for "HOME" could only be made locally on RF before the person left. But that seemed restrictive, but could still be an option for paranoid areas. >As I said, if your goal is so your unlicensed spouse >can go in and look at your home station to see where >you are, read the regulations regarding broadcasting >to the general public. Not at all. APRS users in our area are a friendly bunch and like to keep up with each other (that's why we have radios and APRS). WHen one of us is travelling its nice to use APRS to include them still in the "local" net... With IRLP and ECHOlink and APRS, then, seeing where they are, and that they ARE mobile at the time, makes for easy to arrange (via APRS) a voice QSO too. But only if you can see him on your mobile... (which requires the HOME function that I want to see in APRS)... >As I pointed out, your "plan" cannot work in the >current APRS-IS network nor should it. APRS >was never designed for the operator to "deliver" >his packets to an arbitrary area It most certainly was designed to have that capability (not for routine operations, but for the occassional need).... And it works well for those who are willing to take the time to understand what a digi path is... > (note that the "destination" field in the AX.25 >packet is not used to indicate a destination). No but the path does. I agree that these days with overloaded networks, such activity beyond a few hops is of little value, but that still does not eliminate the "need" for a station to be able to direct his packets "home"... Hence do it via IGates which give the capability unlimited range... >After designing APRS, you tried to add all types >of source routing (SSID, UI-Flood, UI-Trace, etc.) Not true. Source routing was always inherent in AX.25, and APRS only overlayed on top of that. APRS primarily focused on one-to-all local distribution, but no where did it make any attempt to eliminate the ability for source routing over a given, chosen path. In fact, such paths were encouraged for anything beyond 2 hops. Though again, these days, with the load it is of no practical value on RF. That is why the APRS-IS should do it for us if needed by a traveler far from home. > The AX.25 UI protocol is a "multicast" protocol >best suited to local RF operations. Yet, you consistently >try putting a "but" into these facts by saying >"I want my packets to be heard over there, too." You missunderstand the issue. I have no desire to send my packets willy-nilly all over the place. I want to be able to send them HOME to my LOCAL OPERATING area where I am a participating member of a LOCAL RF net. That is why the APRS-IS which is NOT RF should get my traveling packts back here if I want so that it remains a LOCAL RF issue. >This is where most of the congestion problems >originate today: people trying to get their packets >"over there". True, and I agree, but that has NOTHING to do with getting them back HOME. There is a big difference between getting them "over there" and getting them HOME to my local area (without bothering everyone inbetween)... This concept of HOME makes absolutely no impact on the local RF network. If I am home, my packets are on RF at home. If I am on a rare trip, my packets could still get HOME if I select the home option. There is no added burden on the local RF net at all. In fact, it could be said to be less, since via the IGate, my packets should only go one h op not 2... >As I said, if you want to communicate with a specific >station, send a message to them. My experience is that the IGates do not check for the succcess of their local-courtesy-position packet and onlyh send it once every 30 minutes if the QSO continues. If the first position packet collides then you wont see them. And that is why this technique does not work. If the IGate, made sure to LISTEN to verify that the courtesy position packet got out, then this technique would be much more useful. I have had very little success with it. Especially in poorly set up IGates.. >If you want to send bulletins, weather, posits, or >whatever to our area just because you can, thank >goodness the IGate authors had the foresight to >keep you from doing that. Absolutely agree there. But that is not what we are tallking about. We are talking about adding the concept of "HOME" destination for a travelers packets far from home. And I'd be happy if the IGate would filter it down to no more than once per 5 minutes just to be safe too... >APRS is a broadcast protocol, not a point-to-point >protocol. Don't try to make it a point-to-point protocol >because you will fail just as miserably as your >attempt to make AX.25 a routing protocol. Not trying to do either. Just trying to get the IGates to recognize the concept of a HOME IGate for travelers away from home. ANd finding a way to do it so that it is not a management burden on the IGate operators. That is all. de Wb4APR, Bob
- Previous message: [aprssig] Designating HOME Igates
- Next message: [aprssig] Designating HOME Igates
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the aprssig mailing list
