Loading ...
Sorry, an error occurred while loading the content.

Re: [aprsisce] Object Paths

Expand Messages
  • Lynn W Deffenbaugh (Mr)
    ... Not based on what I m seeing from http://aprs.fi/?c=raw&call=VA3CC-14&limit=1000&view=normal (handy station that routine travels from Canada to El Paso
    Message 1 of 16 , May 10, 2013
    • 0 Attachment
      On 5/10/2013 1:16 PM, Robert Bruninga wrote:
      >>> I cannot see the paths used for these objects, because the APRS-IS
      >>> strips the path when heard by an IGate, but if they are anything other
      >> Please educate me Bob. How does "the APRS-IS strip the path
      >> when heard by an IGate"?
      > I thought that everything after the last-digipeated-used was stripped. So
      > that if a packet had 4 hops and was heard on the first one, that all the
      > path after the first one was stripped, then the QAR construct and callsign
      > of the IGATE was inserted?

      Not based on what I'm seeing from
      http://aprs.fi/?c=raw&call=VA3CC-14&limit=1000&view=normal (handy
      station that routine travels from Canada to El Paso criss-crossing the
      continental USA).

      2013-05-07 05:38:44 EDT: VA3CC-14>S6UT2Q,WIDE1-1,WIDE2-2,qAR,KG4LVA-1:`r60!6<0x1f>u/]"5U}Heading to El Pas
      2013-05-07 01:57:44 EDT: VA3CC-14>T0QU6P,WA4ZKO-15,WIDE1*,WIDE2-2,qAR,WA4ZKO-2:`p&<0x7f>!?ku/]"7#}Heading to El Paso
      2013-05-07 01:59:00 EDT: VA3CC-14>T0QU6P,WA4ZKO-15,WIDE1,KB9GYO-3,W8BLV,WIDE2*,qAR,W8GUC:`p&<0x7f>!?ku/]"7#}Heading to El Paso


      > Maybe things have changed... (above my overly protective rock ;-)

      Been that way for as long as I've been into APRS. I'm very familiar
      with that because I started out with path analysis from simply the
      global APRS-IS feed. At least, provided that all of the involved
      digipeaters are properly configured and WIDEn-N capable.

      Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
    • Tony VE6MVP
      At 07:20 AM 2013-05-10, Robert Bruninga wrote: (I m not on the APRSSIG TAPR mailing list but I m awaiting moderation. I had a long posting on the APRS
      Message 2 of 16 , May 10, 2013
      • 0 Attachment
        At 07:20 AM 2013-05-10, Robert Bruninga wrote:

        (I'm not on the APRSSIG TAPR mailing list but I'm awaiting moderation.   I had a long posting on the APRS mailing list with a subject of Repeater objects via WIDE2-1? on the 24th of February on this topic however I only received one answer.  I also decided to change the subject of this posting.)

        I figured mentioning that path for that particular object would be "interesting."  <smile>  These digis mentioned in that have been setup by very competent operators.   I just turned my igate back on so you can, possibly, get a better feel for what I'm doing rather than looking in older history.   http://aprs.fi/info/a/VA6OO

        Background

        My mobile Nuvi 350 attached to an OpenTracker2 displays the packets it hears from the digis including my own packets.   As a result of watching the display being updated over the last year as I drive around and reviewing APRS.FI after a trip I've come to the conclusion that while the digi's can hear my packets for about 50 or 60 kms I can only reliably hear those packets for about 25-35 kms.  

        Given that the object is only transmitted every ten minutes the traveller might be within 10 kms of the repeater before they see the object, such as a repeater, on their screen.  They could've been working that repeater for another 40 or 60 kms away if they had seen the repeater object sooner.

        Therefore, in my opinion, some objects such as repeater objects, should be one hop digipeated by the various digipeaters around the object.  So the traveller has the object in their device memory and on their screen not too long before they enter that repeater object range.    But they are still well out of range of hearing the object on the digi.

        Details

        You can best see this area I reside in by http://aprs.fi/#!addr=edgerton%2C%20ab and zooming out and repositioning the screen so you can see the VA6OO and VE6CIC igates as well as the ALIANC and PROVST digipeaters.

        The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW

        Now for this particular repeater,   http://aprs.fi/info/a/145.29-RW , I am to the north and east of it.   I can't reliably hear all four digipeaters.   The first digi on the list is my closest digi and to the north of that repeater.   The second digi is to the NE of that repeater which I can reliably hit but it's main purpose in the list is to get my repeater object packet to the third and fourth repeaters. The third digi on the list is to the east of that repeater while the fourth digi on the list is on the west of that repeater.   So basically the packets are travelling in a ring or box   around the repeater.

        By not using a WIDE2-1 or WIDE2-2 I don't "leak" the repeater object info to the north or west of me to adjacent digis which would be way out of range of the repeater.

        Misc

        Also we have a very lightly loaded network out here so we can experiment a little without causing congestion in the nearby city which is three hops away.

        I think I know which station you mean is generating 26 objects.   I think he is currently only generating a number of repeater objects and about two or three of other objects on a regular basis and I somewhat disagree with one or two of them but I can see his point on those as well in an ARES situation.

        That said it was very nice that the one repeater 145.250-R  was digiipeated with a path of some sort.  I was travelling into Stettler and had forgotten to record that local linked repeater frequency ahead of time.  I was mentally kicking myself when I looked over at my Nuvi 350 and there was the object.  So I entered the frequency on my radio and was happily chatting with someone.

        Finally we only have two APRS igates in my rural two hop area.  I'm running mine, VA6OO, most of the time but do play around with satellite once in a while.  So it would probably be better for the other igate operator, who is closer to that repeater, to create this particular repeater object.   But I feel that his path should be the same as mine, so that adjacent digis will see that particular repeater object. 

        Tony VA6OO

        > I have one repeater object where I specify the four digipeaters
        > path to ensure the APRS object covers the area of the voice
        > repeater but no where else.  If you care the path is
        VERMLN,LLOYD,PROVST,ALIANC)

        I'm sorry to jump in here with lead feet, (and am not following the
        thread) but on the face of it, I fear that path violates the most
        fundamental principles of the LOCAL INFO and FREQ objects:
        http://aprs.org/localinfo.html

        1) The object is not sourced *at* the digis, but *via* the digis
        2) This source cannot hear what the digis hear, and so it has a higher
        probability of collision with all other area packet sources.
        3) Only the digis are supposed to source these objects and only
        *direct*since they will ONLY TX when the channel is clear and *only* the
        digis know when the channel is clear.
        4) Digipeating normally doubles the channel loading for this kind of info
        5) But in this case Digipeating via 4 hops *quintuples* the channel
        loading for bjects which are supposed to be invisible to user load.
        6) Two of those digis do not show PHG data so it is impossible to analyze
        the network from the maps

        Zooming into the area I see some other frightening situations with one
        station originating at least 26 such objects!*!

        Now, no one likes advice from afar, But -if- all these objects are being
        transmitted as recommended at 10 minute intervals (the value to mobiles
        driving into the area) then that local network would be nearly saturated
        with nothing but these objects with no room for anything else.

        I cannot see the paths used for these objects, because the APRS-IS strips
        the path when heard by an IGate, but if they are anything other than
        *direct* and if they are sourced anywhere other than at the digi's
        themselves, then they are not properly implemented in accordance with the
        design of Frequency (repeater) objects.

        On the other hand, I value these kinds of objects very highly, and if
        abusing the network is the only way to work around lethargig DIGI
        operators, then so be it. But it is not the right way to do things. And
        certainly 4 hops is the worst thing. If the network must be so abused
        because the digi operators will not set up their digis to serve travelers,
        then at least originate the object Central to the 4 digis so that only a
        *single* time slot can hit all 4 digis at once.

        Again, I could very well be taking things all wrong. So in that case just
        ignore me and consider this a sermon to the choir...

        Bob, WB4aPR
      • Robert Bruninga
        Tony, Thanks for the very informative info. But I fear this technique sets bad example… ... We agree completely in ever digi putting out the info, but
        Message 3 of 16 , May 10, 2013
        • 0 Attachment

          Tony,

           

          Thanks for the very informative info.  But I fear this technique sets  bad example…

           

          > Therefore, in my opinion, some objects such as repeater objects,

          > should be one hop digipeated by the various digipeaters around the object.

           

          We agree completely in ever digi putting out the info, but every DIGi should source this info, and most digipeaters have BEACON room for 2 or 3 of them.  And I do like to see this local info…, but the objects should be “sourced” by those 4 digipeaters with a direct path (no hops) so that the DIGI only transmits them when the channel is clear.  Only the digipeaters can hear their “input area” and so only they can add this info to the channel so  they do not  collide with any user packets at all.

           

          Sourcing them at one place and having them bounce around to all 4 digis takes up 5 times as much channel capacity.  And none of those packets are guaranteed not to collide with user packets.  But if they are –sourced- at the digi, then the collision potential is zero.

           

          > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW

           

          Again, that is 5 times the channel QRM compared to the way these objects are supposed to be designed so that they have zero impact on users by having no path and being sourced at each digi.

           

          >  So basically the packets are travelling in a ring or box   around the repeater.

          But that is the worst possible method generating 5 times the channel load.  The total amount of QRM being generated is as if these beacons were every 2 minutes if you count the total time slots involved.  When sourced at the digis, the time slots count is actually ZERO since the digis will only originate the packet (no hops) when the channel is clear.  So although I keep saying it is 5 times larger, it is really infinitely larger QRM because 5 times larger than nothing is infinite.

           

          > Also we have a very lightly loaded network out here

           

          True, but it sets a bad example and these things tend to get entrenched and hard to correct later.

           

          Thanks for putting out this info.  I wish more people did it.  But I worry that this is setting a bad example.  My web page that describes all this is on http://aprs.org/localinfo.html

           

          Hope that helps…

           

          Thanks,

          Bob, Wb4APR

        • Adam Mahnke
          One problem is that some Digi owners are unwilling/able to get this information programmed into the Digis. Some of us that have APRS stations, but may not have
          Message 4 of 16 , May 10, 2013
          • 0 Attachment
            One problem is that some Digi owners are unwilling/able to get this information programmed into the Digis. Some of us that have APRS stations, but may not have access to the "Best" digi to house this information, can still use that digi to amplify the object out to the public.

            Just my .02

            Adam
            KC2ANT


            To: aprsisce@yahoogroups.com
            CC: bruninga@...
            From: bruninga@...
            Date: Fri, 10 May 2013 19:00:25 -0400
            Subject: RE: [aprsisce] Strange path for repeater object.

             

            Tony,

             

            Thanks for the very informative info.  But I fear this technique sets  bad example…

             

            > Therefore, in my opinion, some objects such as repeater objects,

            > should be one hop digipeated by the various digipeaters around the object.

             

            We agree completely in ever digi putting out the info, but every DIGi should source this info, and most digipeaters have BEACON room for 2 or 3 of them.  And I do like to see this local info…, but the objects should be “sourced” by those 4 digipeaters with a direct path (no hops) so that the DIGI only transmits them when the channel is clear.  Only the digipeaters can hear their “input area” and so only they can add this info to the channel so  they do not  collide with any user packets at all.

             

            Sourcing them at one place and having them bounce around to all 4 digis takes up 5 times as much channel capacity.  And none of those packets are guaranteed not to collide with user packets.  But if they are –sourced- at the digi, then the collision potential is zero.

             

            > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW

             

            Again, that is 5 times the channel QRM compared to the way these objects are supposed to be designed so that they have zero impact on users by having no path and being sourced at each digi.

             

            >  So basically the packets are travelling in a ring or box   around the repeater.

            But that is the worst possible method generating 5 times the channel load.  The total amount of QRM being generated is as if these beacons were every 2 minutes if you count the total time slots involved.  When sourced at the digis, the time slots count is actually ZERO since the digis will only originate the packet (no hops) when the channel is clear.  So although I keep saying it is 5 times larger, it is really infinitely larger QRM because 5 times larger than nothing is infinite.

             

            > Also we have a very lightly loaded network out here

             

            True, but it sets a bad example and these things tend to get entrenched and hard to correct later.

             

            Thanks for putting out this info.  I wish more people did it.  But I worry that this is setting a bad example.  My web page that describes all this is on http://aprs.org/localinfo.html

             

            Hope that helps…

             

            Thanks,

            Bob, Wb4APR


          • Tony VE6MVP
            At 05:00 PM 2013-05-10, Robert Bruninga wrote: Given that you suggest sourcing the packets at each of the four digipeaters around that repeater object in
            Message 5 of 16 , May 10, 2013
            • 0 Attachment
              At 05:00 PM 2013-05-10, Robert Bruninga wrote:

              Given that you suggest sourcing the packets at each of the four digipeaters around that repeater object in question makes a lot more sense.  I must admit I was thinking in terms of only the single "closest" digi to the repeater.   Blind spot on my part.   <smile>   And when I review your web page I'm thinking you might want to add a sentence along those lines.   My conceited attitude is that if I miss something other folks likely will be missing the same concept.

              BTW the digis in question are up to 30 or 40 kms from the repeater object.

              I'll talk to the folks who run those digis and we'll see what we can do.

              Tony



               

              Tony,

               

              Thanks for the very informative info.  But I fear this technique sets  bad example…

               

              > Therefore, in my opinion, some objects such as repeater objects,

              > should be one hop digipeated by the various digipeaters around the object.

               

              We agree completely in ever digi putting out the info, but every DIGi should source this info, and most digipeaters have BEACON room for 2 or 3 of them.  And I do like to see this local info…, but the objects should be “sourced” by those 4 digipeaters with a direct path (no hops) so that the DIGI only transmits them when the channel is clear.  Only the digipeaters can hear their “input area” and so only they can add this info to the channel so  they do not  collide with any user packets at all.

               

              Sourcing them at one place and having them bounce around to all 4 digis takes up 5 times as much channel capacity.  And none of those packets are guaranteed not to collide with user packets.  But if they are –sourced- at the digi, then the collision potential is zero.

               

              > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW

               

              Again, that is 5 times the channel QRM compared to the way these objects are supposed to be designed so that they have zero impact on users by having no path and being sourced at each digi.

               

              >  So basically the packets are travelling in a ring or box   around the repeater.

              But that is the worst possible method generating 5 times the channel load.  The total amount of QRM being generated is as if these beacons were every 2 minutes if you count the total time slots involved.  When sourced at the digis, the time slots count is actually ZERO since the digis will only originate the packet (no hops) when the channel is clear.  So although I keep saying it is 5 times larger, it is really infinitely larger QRM because 5 times larger than nothing is infinite.

               

              > Also we have a very lightly loaded network out here…

               

              True, but it sets a bad example and these things tend to get entrenched and hard to correct later.

               

              Thanks for putting out this info.  I wish more people did it.  But I worry that this is setting a bad example.  My web page that describes all this is on http://aprs.org/localinfo.html

               

              Hope that helps…

               

              Thanks,

              Bob, Wb4APR
            • Robert Bruninga
              Yes, the concept is that **every** APRS digipeter has the responsibility to source this info about the best repeaters in its footprint –to- its own users in
              Message 6 of 16 , May 10, 2013
              • 0 Attachment

                Yes, the concept is that *every* APRS digipeter has the responsibility to source this info about the best repeaters in its footprint –to- its own users in its own footprint. (since the New –N pareadigm solidified in 2004 now almost a decade ago)…  Notice, this info goes to the footprint of the digi, not the –footprint- of the repeater being infoed.

                 

                Conversely, There is nothing more irritating that getting freq objects about repeaters a hundred miles away that are impossible to hit (from the area whre I just received the packet).  The reason it is irritating, is that when one see’s one  pop up on the front panel of the radio one should –assume- he can hit it.  I just hit tune, and make a call.  7 times out of 10 my call is unsuccessful because the repeater is actually a hundred miles away and is being improperly flooded all over the place.

                 

                The reason this is so irritating, is because we must be concerned with driver safety.  The function is supposed to be a one-button QSY function.  Yet, 7 tiumes out of 10, I cant hit it, and they I begin *unsafely* poking round on the radio to try to figure out why…

                 

                Bob, WB4aPR

                 

                From: aprsisce@yahoogroups.com [mailto:aprsisce@yahoogroups.com] On Behalf Of Tony VE6MVP
                Sent: Friday, May 10, 2013 7:20 PM
                To: aprsisce@yahoogroups.com
                Cc: bruninga@...
                Subject: RE: [aprsisce] Strange path for repeater object.

                 



                At 05:00 PM 2013-05-10, Robert Bruninga wrote:

                Given that you suggest sourcing the packets at each of the four digipeaters around that repeater object in question makes a lot more sense.  I must admit I was thinking in terms of only the single "closest" digi to the repeater.   Blind spot on my part.   <smile>   And when I review your web page I'm thinking you might want to add a sentence along those lines.   My conceited attitude is that if I miss something other folks likely will be missing the same concept.

                BTW the digis in question are up to 30 or 40 kms from the repeater object.

                I'll talk to the folks who run those digis and we'll see what we can do.

                Tony




                 

                Tony,

                 

                Thanks for the very informative info.  But I fear this technique sets  bad example…

                 

                > Therefore, in my opinion, some objects such as repeater objects,

                > should be one hop digipeated by the various digipeaters around the object.

                 

                We agree completely in ever digi putting out the info, but every DIGi should source this info, and most digipeaters have BEACON room for 2 or 3 of them.  And I do like to see this local info…, but the objects should be “sourced” by those 4 digipeaters with a direct path (no hops) so that the DIGI only transmits them when the channel is clear.  Only the digipeaters can hear their “input area” and so only they can add this info to the channel so  they do not  collide with any user packets at all.

                 

                Sourcing them at one place and having them bounce around to all 4 digis takes up 5 times as much channel capacity.  And none of those packets are guaranteed not to collide with user packets.  But if they are –sourced- at the digi, then the collision potential is zero.

                 

                > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW

                 

                Again, that is 5 times the channel QRM compared to the way these objects are supposed to be designed so that they have zero impact on users by having no path and being sourced at each digi.

                 

                >  So basically the packets are travelling in a ring or box   around the repeater.

                But that is the worst possible method generating 5 times the channel load.  The total amount of QRM being generated is as if these beacons were every 2 minutes if you count the total time slots involved.  When sourced at the digis, the time slots count is actually ZERO since the digis will only originate the packet (no hops) when the channel is clear.  So although I keep saying it is 5 times larger, it is really infinitely larger QRM because 5 times larger than nothing is infinite.

                 

                > Also we have a very lightly loaded network out here…

                 

                True, but it sets a bad example and these things tend to get entrenched and hard to correct later.

                 

                Thanks for putting out this info.  I wish more people did it.  But I worry that this is setting a bad example.  My web page that describes all this is on http://aprs.org/localinfo.html

                 

                Hope that helps…

                 

                Thanks,

                Bob, Wb4APR




              • Tony VE6MVP
                At 05:44 PM 2013-05-10, Robert Bruninga wrote: Agreed, however do note that because I was not using WIDEx-x in the strange paths the repeater object was not
                Message 7 of 16 , May 11, 2013
                • 0 Attachment
                  At 05:44 PM 2013-05-10, Robert Bruninga wrote:

                  Agreed, however do note that because I was not using WIDEx-x in the strange paths the repeater object was not "leaking" outside it's intended path.

                  Also you can sort the objects by distance rather than arrival time in the D710.    That said I suspect on my next long distance trip, which will be in a few days, I'm going to leave my Nuvi 350/OT2 displaying received objects sorted by distance and the D710 sorted by arrival time.    Of course most of the time I will be in rural Alberta so I'll be fortunate if there are any objects other than digis and repeaters in my top 5 list.  <smile>    And there will almost certainly be 20 or 50 mile stretches where I won't be hearing anything.

                  Hmm, I gotta RTFM the D710 manual and figure out how to display the frequency on the APRS comment screen.

                  And, now that I think about it, I think I'm going to have them both doing Smart Beaconing, with two different SSIDs for much of the trip and do a subjective comparison of the difference between 5 and 50 watts output on most of my trip.   For about an hour or two I'll be near a large city, Calgary, where I'll probably turn one off just to minimize congestion on the local frequency.

                  Tony

                  Conversely, There is nothing more irritating that getting freq objects about repeaters a hundred miles away that are impossible to hit (from the area whre I just received the packet).  The reason it is irritating, is that when one see’s one  pop up on the front panel of the radio one should –assume- he can hit it.  I just hit tune, and make a call.  7 times out of 10 my call is unsuccessful because the repeater is actually a hundred miles away and is being improperly flooded all over the place.

                  The reason this is so irritating, is because we must be concerned with driver safety.  The function is supposed to be a one-button QSY function.  Yet, 7 tiumes out of 10, I cant hit it, and they I begin *unsafely* poking round on the radio to try to figure out why…

                   

                  Bob, WB4aPR

                   

                  From: aprsisce@yahoogroups.com [ mailto:aprsisce@yahoogroups.com] On Behalf Of Tony VE6MVP
                  Sent: Friday, May 10, 2013 7:20 PM
                  To: aprsisce@yahoogroups.com
                  Cc: bruninga@...
                  Subject: RE: [aprsisce] Strange path for repeater object.

                   



                  At 05:00 PM 2013-05-10, Robert Bruninga wrote:

                  Given that you suggest sourcing the packets at each of the four digipeaters around that repeater object in question makes a lot more sense.  I must admit I was thinking in terms of only the single "closest" digi to the repeater.   Blind spot on my part.   <smile>   And when I review your web page I'm thinking you might want to add a sentence along those lines.   My conceited attitude is that if I miss something other folks likely will be missing the same concept.

                  BTW the digis in question are up to 30 or 40 kms from the repeater object.

                  I'll talk to the folks who run those digis and we'll see what we can do.

                  Tony




                   

                  Tony,

                   

                  Thanks for the very informative info.  But I fear this technique sets  bad example…

                   

                  > Therefore, in my opinion, some objects such as repeater objects,

                  > should be one hop digipeated by the various digipeaters around the object.

                   

                  We agree completely in ever digi putting out the info, but every DIGi should source this info, and most digipeaters have BEACON room for 2 or 3 of them.  And I do like to see this local info…, but the objects should be “sourced” by those 4 digipeaters with a direct path (no hops) so that the DIGI only transmits them when the channel is clear.  Only the digipeaters can hear their “input area” and so only they can add this info to the channel so  they do not  collide with any user packets at all.

                   

                  Sourcing them at one place and having them bounce around to all 4 digis takes up 5 times as much channel capacity.  And none of those packets are guaranteed not to collide with user packets.  But if they are –sourced- at the digi, then the collision potential is zero.

                   

                  > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW

                   

                  Again, that is 5 times the channel QRM compared to the way these objects are supposed to be designed so that they have zero impact on users by having no path and being sourced at each digi.

                   

                  >  So basically the packets are travelling in a ring or box   around the repeater.

                  But that is the worst possible method generating 5 times the channel load.  The total amount of QRM being generated is as if these beacons were every 2 minutes if you count the total time slots involved.  When sourced at the digis, the time slots count is actually ZERO since the digis will only originate the packet (no hops) when the channel is clear.  So although I keep saying it is 5 times larger, it is really infinitely larger QRM because 5 times larger than nothing is infinite.

                   

                  > Also we have a very lightly loaded network out here…

                   

                  True, but it sets a bad example and these things tend to get entrenched and hard to correct later.

                   

                  Thanks for putting out this info.  I wish more people did it.  But I worry that this is setting a bad example.  My web page that describes all this is on http://aprs.org/localinfo.html

                   

                  Hope that helps…

                   

                  Thanks,

                  Bob, Wb4APR





                  Content-Type: image/jpeg; name="image001.jpg"
                  Content-ID: <image001.jpg@01CE4DB6.C18441E0>
                  X-Attachment-Id: 60be21587efde609_0.1

                • James Ewen
                  On Fri, May 10, 2013 at 1:36 PM, Lynn W Deffenbaugh (Mr) ... I think Bob may have concluded that the path elements are stripped out by observing packets from
                  Message 8 of 16 , May 12, 2013
                  • 0 Attachment
                    On Fri, May 10, 2013 at 1:36 PM, Lynn W Deffenbaugh (Mr)
                    <kj4erj@...> wrote:

                    >> Maybe things have changed... (above my overly protective rock ;-)
                    >
                    > Been that way for as long as I've been into APRS. I'm very familiar
                    > with that because I started out with path analysis from simply the
                    > global APRS-IS feed. At least, provided that all of the involved
                    > digipeaters are properly configured and WIDEn-N capable.

                    I think Bob may have concluded that the path elements are stripped out
                    by observing packets from Tony...

                    Tony stated that he was using a 4 hop specified path, but looking at
                    the APRS-IS packets, you sometimes aren't able to see that.

                    Here's an example fresh off the network:

                    Looking at the feed seen at aprs.fi, I see this:

                    09:56:44 MDT: VA6OO>APWW10,TCPIP*,qAC,T2CSNGRAD:;145.29-RW*111111z5245.44N/11032.87WrVE6RWC
                    Sask Alta Radio Club

                    Yet when observed via other entry points, including Tony's own
                    station, you can see the full requested path.

                    16:06:46.019 [0]VA6OO>APWW10,VERMLN*,LLOYD,PROVST,ALIANC,qAR,LAMONT:;145.29-RW*111111z5245.44N/11032.87WrVE6RWC
                    Sask Alta Radio Club
                    16:06:47.856 [1]VA6OO>APWW10,VERMLN*,LLOYD,PROVST,ALIANC,qAR,VA6OO:;145.29-RW*111111z5245.44N/11032.87WrVE6RWC
                    Sask Alta Radio Club
                    16:06:48.004 [2]VA6OO>APWW10,VERMLN,LLOYD*,PROVST,ALIANC,qAR,VA6OO:;145.29-RW*111111z5245.44N/11032.87WrVE6RWC
                    Sask Alta Radio Club
                    16:06:55.026 [3]VA6OO>APWW10,VERMLN*,LLOYD*,PROVST*,ALIANC*,qAR,VE6CIC:;145.29-RW*111111z5245.44N/11032.87WrVE6RWC
                    Sask Alta Radio Club

                    When APRSISCE/32 sends packets directly to the APRS-IS stream, the RF
                    path is not included. I'm not sure if that happens with other programs
                    or not. I've never spent the time to see if it is true.

                    Regardless, that might be the source of Bob's observation.

                    --
                    James
                    VE6SRV
                  • James Ewen
                    ... The chances of collision potential are not zero in an APRS network. If you have a single digipeater that can hear EVERY user station, the digipeater will
                    Message 9 of 16 , May 12, 2013
                    • 0 Attachment
                      On Fri, May 10, 2013 at 5:00 PM, Robert Bruninga <bruninga@...> wrote:

                      > We agree completely in ever digi putting out the info, but every DIGi
                      > should source this info, and most digipeaters have BEACON room for 2 or 3 of
                      > them. And I do like to see this local info…, but the objects should be
                      > “sourced” by those 4 digipeaters with a direct path (no hops) so that the
                      > DIGI only transmits them when the channel is clear. Only the digipeaters
                      > can hear their “input area” and so only they can add this info to the
                      > channel so they do not collide with any user packets at all.
                      >
                      > Sourcing them at one place and having them bounce around to all 4 digis
                      > takes up 5 times as much channel capacity. And none of those packets are
                      > guaranteed not to collide with user packets. But if they are –sourced- at
                      > the digi, then the collision potential is zero.

                      The chances of collision potential are not zero in an APRS network.

                      If you have a single digipeater that can hear EVERY user station, the
                      digipeater will attempt to send the packet during a time when no other
                      stations are transmitting. Even in this scenario there is a remote
                      possibility that a user station may key up exactly at the same time
                      that the digipeater keys up. Regular user stations are supposed to
                      have a random hold off time to keep them from clobbering each other,
                      and the digipeaters are supposed to key up right away. But if a user
                      station decides to key up and waits it's random amount of time, and as
                      that hold off expires, the digipeater decides to send the repeater
                      object, a collision can result.

                      Now add in a bunch of digipeaters surrounding the original digipeater.
                      The digi sourcing the repeater object can not tell if the remote
                      digipeaters are hearing incoming packets or have a clear channel, so
                      there's the chance of the voice object colliding with a user packet
                      trying to get into one of the remote digipeaters.

                      I agree that sourcing the packets at the digipeater has a lesser
                      chance of creating collisions on the network, and using a zero hop
                      path reduces the network load much more than a user trying to send the
                      packets around the area with a multi-hop path, but to say that the
                      collision potential is zero is misleading.

                      > > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW
                      >
                      > Again, that is 5 times the channel QRM compared to the way these objects
                      > are supposed to be designed so that they have zero impact on users by having
                      > no path and being sourced at each digi.

                      4 times the load... there's always a source packet whether from a user
                      station, or from a digipeater. Again, trying to imply that a packet
                      sourced by a digipeater has zero impact on the users is misleading. If
                      the user can hear the packet, it has an impact. That packet has used
                      up airtime, and is heard by all stations within range, including all
                      surrounding digipeaters.

                      > > So basically the packets are travelling in a ring or box around the
                      > > repeater.
                      >
                      > But that is the worst possible method generating 5 times the channel load.

                      Again I would disagree... there are far worse methods available. Trust
                      me, let the users play and you'll find out! If Tony were to use the
                      path WIDE2-2, the packets would travel much further and cause more
                      network load than his specified 4 hop path.

                      > The total amount of QRM being generated is as if these beacons were every 2
                      > minutes if you count the total time slots involved. When sourced at the
                      > digis, the time slots count is actually ZERO since the digis will only
                      > originate the packet (no hops) when the channel is clear. So although I
                      > keep saying it is 5 times larger, it is really infinitely larger QRM because
                      > 5 times larger than nothing is infinite.

                      Again, a misleading analysis. There is no possible way to send a
                      packet out that takes up zero airtime. A packet sourced from a user
                      station is no different than a packet sourced from a digipeater. The
                      user station waits until it hears a clear channel before transmitting.
                      A digipeater waits until it hears a clear channel before transmitting.
                      Each station can only ensure clear channel occupancy within the area
                      it can hear directly.

                      The concern is that a packet sourced by a home station may clobber
                      another home or mobile user trying to access the nearby digipeater.
                      When a packet is sourced by a digipeater, it too has the same
                      potential to clobber packets from other users on surrounding
                      digipeaters.

                      The biggest difference is that when sourced from a home station asking
                      for a digipeat by the local digipeater, the packet needs to be on the
                      air two times to get the same coverage area as when that packet is
                      sourced by the digipeater. (Given that the digipeater covers a larger
                      area than the home station is capable of covering.)

                      >> Also we have a very lightly loaded network out here…
                      >
                      > True, but it sets a bad example and these things tend to get entrenched
                      > and hard to correct later.

                      This I agree with wholeheartedly. We should all strive to operate as
                      efficiently as possible.

                      > Thanks for putting out this info. I wish more people did it. But I worry
                      > that this is setting a bad example. My web page that describes all this is
                      > on http://aprs.org/localinfo.html

                      Accurate observation and explanation of the operations of the packet
                      radio network would go a long way towards getting people up to speed.
                      Unfortunately many people don't take the time to learn and understand
                      the intricacies of all of the inner workings of the APRS network.

                      There are also a number of concepts touted as being the panacea of
                      APRS network operations that just don't work in the real world.

                      The concept of APRS and its use is my favourite aspect of amateur
                      radio. I have far more time and money invested into APRS than all
                      other aspects of amateur radio combined. I love it, but there are a
                      lot of basic misconceptions floating around and being espoused as the
                      gospel when they are misleading at best.

                      --
                      James
                      VE6SRV
                    • Lynn W Deffenbaugh (Mr)
                      ... Per http://www.aprs-is.net/Connecting.aspx ... Nothing in there about unless you re also transmitting on RF . So client-generated packets directly
                      Message 10 of 16 , May 12, 2013
                      • 0 Attachment
                        On 5/12/2013 12:18 PM, James Ewen wrote:
                        > When APRSISCE/32 sends packets directly to the APRS-IS stream, the RF
                        > path is not included. I'm not sure if that happens with other programs
                        > or not. I've never spent the time to see if it is true. Regardless,
                        > that might be the source of Bob's observation.

                        Per http://www.aprs-is.net/Connecting.aspx

                        > Packets originating from the client should only have TCPIP* in the
                        > path, nothing more or less (AE5PL-TS>APRS,TCPIP*:my packet).

                        Nothing in there about "unless you're also transmitting on RF". So
                        client-generated packets directly injected to the APRS-IS will only
                        contain a path of TCPIP*. The same packet transmitted on RF will
                        contain the configured RF path. Eventually, each RF port will have the
                        ability to specify its own path for transmitted packets and the Chat
                        interface will also allow a local override of the default RF path.

                        Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

                        PS. And that's yet another reason to run single-RF-port instances. If
                        you override the path in the Chat, which port did you intend it to use
                        that path on? Or just how complicated are we going to make this?
                      • James Ewen
                        On Sun, May 12, 2013 at 11:30 AM, Lynn W Deffenbaugh (Mr) ... So that s as per the APRS-IS interface specification. Yet another reason why one should not base
                        Message 11 of 16 , May 12, 2013
                        • 0 Attachment
                          On Sun, May 12, 2013 at 11:30 AM, Lynn W Deffenbaugh (Mr)
                          <kj4erj@...> wrote:

                          >> Packets originating from the client should only have TCPIP* in the
                          >> path, nothing more or less (AE5PL-TS>APRS,TCPIP*:my packet).
                          >
                          > Nothing in there about "unless you're also transmitting on RF". So
                          > client-generated packets directly injected to the APRS-IS will only
                          > contain a path of TCPIP*. The same packet transmitted on RF will
                          > contain the configured RF path.

                          So that's as per the APRS-IS interface specification.

                          Yet another reason why one should not base observations of the APRS-RF
                          network on data seen on the internet.

                          Everyday you learn a little more! Thanks Lynn.

                          --
                          James
                          VE6SRV
                        • Tony VE6MVP
                          ... When I think about this a bit, and after reading James comment, I m going to disagree with your 5 times comment. Because I specifically directed that
                          Message 12 of 16 , May 12, 2013
                          • 0 Attachment
                            At 05:00 PM 2013-05-10, Robert Bruninga wrote:

                            Sourcing them at one place and having them bounce around to all 4 digis takes up 5 times as much channel capacity.  And none of those packets are guaranteed not to collide with user packets.  But if they are –sourced- at the digi, then the collision potential is zero.

                            > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object 145.29-RW

                            Again, that is 5 times the channel QRM compared to the way these objects are supposed to be designed so that they have zero impact on users by having no path and being sourced at each digi.

                            When I think about this a bit, and after reading James comment, I'm going to disagree with your 5 times comment.  Because I specifically directed that packet to go from digi to digi, rather than using a WIDE2-2 the only extra QRM is the initial packet from my home station.   So it's 20% extra QRM rather than five times.    After that it's one digi hearing the next digi.

                            My home station can hear the first two digis and likely the other two digis could hear a carrier and static when I transmitted my initial packet.   So that initial packet could wipe out other packets for the first two digis.   The two remoter digis would hear a local packet much sooner than my packet due to the FM capture effect.

                            Furthermore, when I think about it, there is no real reason why the VERMLN digi owner couldn't put in exactly the same path I specified.    That way there is only one digi to update should the repeater object require changes rather than having to update four digis.   Or am I mistaken?

                            Hmm, ok, my thinking is slightly flawed in that an adjacent digi could wipe out another packet being received by an adjacent digi which the first digi can't hear.   But that could happen no matter where the repeater object is sourced.

                            Lynn, we're getting pretty far off the topic of APRSIS32.  OTOH we're firmly on the topic of APRS so ....

                            I quite enjoy these technical discussions and understanding what all happens at a deeper level than running the configuration program and dumping my packets to the APRSIS network.  Even if I'm wrong.  <smile>   So long as my understanding increases.

                            Tony
                          • Tony VE6MVP
                            ... And there is a reasonable chance, on a WIDE2-2 path, that my packet wouldn t make it to the fourth digi. Most of the time my home station only hears the
                            Message 13 of 16 , May 12, 2013
                            • 0 Attachment
                              At 10:52 AM 2013-05-12, James Ewen wrote:

                              >> > The path VERMLN,LLOYD,PROVST,ALIANC is for repeater object
                              145.29-RW

                              >If Tony were to use the
                              >path WIDE2-2, the packets would travel much further and cause
                              more
                              >network load than his specified 4 hop path.

                              And there is a reasonable chance, on a WIDE2-2 path, that my packet wouldn't make it to the fourth digi.   Most of the time my home station only hears the first two digis reliably.    And VERMLN and LLOYD can't reliably hear ALIANC.  At least I don't think so.  

                              So if VERMLN digis the packet and PROVST hears the VERMLN packet and digis the VERMLN packet then ALIANC will hear the packet.  But if VERMLN digis the packet, then LLOYD and then PROVST the ALIANC won't hear my packet because the two hops will be used by at PROVST.

                              And, of course, the WIDE2-2 means that my packet is going to head off north and west where we don't need it.

                              >Accurate observation and explanation of the operations of the
                              packet
                              >radio network would go a long way towards getting people up to
                              speed.
                              >Unfortunately many people don't take the time to learn and
                              understand
                              >the intricacies of all of the inner workings of the APRS
                              network.

                              And that is, of course, true in every endeavor of life.  <smile>  It's up to the fanatics, and in James case I mean that in the kindest way, to educate the others when they see a problem.   After all it's it's ten thousand fanatics that built up Wikipedia and Open Street Map, etc, etc,

                              >The concept of APRS and its use is my favourite aspect of
                              amateur
                              >radio. I have far more time and money invested into APRS than
                              all
                              >other aspects of amateur radio combined.

                              I can vouch for that.  James VE6SRV has lot of digis scattered around the central and northern chunk of the province.   As well as Curtis VE6AEW.

                              Tony
                            Your message has been successfully submitted and would be delivered to recipients shortly.