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

RE: [aprsisce] Strange path for repeater object.

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.