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

Path's with APRSIS32

Expand Messages
  • ptompkins1976
    I ve dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path
    Message 1 of 6 , Nov 8, 2013
    I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.


    Is that correct?
    So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

    Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).  If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

    Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

    I'm sorry for all my newbie questions.

    Phillip
    KD7QOT

  • Lynn W Deffenbaugh (Mr)
    ... Yes, that is correct. Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path
    Message 2 of 6 , Nov 8, 2013
      On 11/8/2013 12:41 PM, ptompkins@... wrote:
      I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

      Is that correct?

      Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

      So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

      Yes.


      Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

      Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




      If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

      No, it's "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

      Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


      Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

      Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


      I'm sorry for all my newbie questions.

      Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

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



      Phillip
      KD7QOT


    • Lynn W Deffenbaugh (Mr)
      (Corrected NOT smart enough) ... Yes, that is correct. Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects
      Message 3 of 6 , Nov 8, 2013
        (Corrected NOT smart enough)

        On 11/8/2013 12:41 PM, ptompkins@... wrote:
        I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

        Is that correct?

        Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

        So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

        Yes.


        Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

        Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




        If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

        No, it's not "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

        Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


        Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

        Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


        I'm sorry for all my newbie questions.

        Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

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



        Phillip
        KD7QOT


      • Rob Giuliano
        Wouldn t the path show as a group of callsigns that have been inserted to replace WIDEn-N or any other Alias? EXAMPLE:  
        Message 4 of 6 , Nov 8, 2013
          Wouldn't the path show as a group of callsigns that have been inserted to replace WIDEn-N or any other Alias?
           
          EXAMPLE:
            ECET5W,W8OAK-14,CHLSEA*,WIDE2-1,qAR,W8HHF-15:`o51lJb>/]"7>}=
          Which probably came from: 
            ECET5W,WIDE1-1,WIDE2-2,qAR,W8OAK-15:`o51lJb>/]"7>}=
          if you only get the second part that shows callsigns and aliases, how can you know what the original part was?
          On the other hand, if you reversed it and sent via:
             CHLSEA, W8OAK-14
          How can you be sure those station WILL "respond to" (digi) of its callsign-ssid that was inserted.
          They may only digi off WIDEn-N.
             Even if each station does, it doesn't mean it was the most efficient path, just the "last successful" path.
             A closer station may have been overwhelmed by another local packet at that particular time.
           
          It would make sense that the BEST method would be to send with a given "generic" path and take advantage of
           
          Robert Giuliano
          KB8RCO


          ---------------------------------------------

          From: Lynn W Deffenbaugh (Mr) <kj4erj@...>
          To: aprsisce@yahoogroups.com
          Sent: Friday, November 8, 2013 1:59 PM
          Subject: Re: [aprsisce] Path's with APRSIS32

          (Corrected NOT smart enough)

          On 11/8/2013 12:41 PM, ptompkins@... wrote:
          I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

          Is that correct?

          Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

          So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

          Yes.


          Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

          Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




          If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

          No, it's not "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

          Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


          Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

          Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


          I'm sorry for all my newbie questions.

          Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

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




          Phillip
          KD7QOT




        • Lynn W Deffenbaugh (Mr)
          In a perfect world where every digipeater inserted its callsign, decremented the alias s -SSID and marked it used if the result is zero, then you would be able
          Message 5 of 6 , Nov 8, 2013
            In a perfect world where every digipeater inserted its callsign, decremented the alias's -SSID and marked it used if the result is zero, then you would be able to use a packet's path to know everything it did.  You could even determine what the original -SSID was (WIDE2-2 vs WIDE2-1 for instance) by counting the digipeaters appearing before it and after the previous alias.

            But we don't live in a perfect world.

            Consider your first example:  ECET52,W8OAK-14,CHLSEA*,WIDE2-1,qAR,W8HHF-15.  What alias did W8OAK-14 replace?  Or did this packet start out with a WIDE2-3?  There's no way to know.

            Your second example, ECET52,WIDE1-1,WIDE2-2,qAR,W8OAK-15 is easier.  W8OAK-15 heard it direct.  Unless, of course, there's a seriously non-standard digipeater in the area that simply repeats every packet it hears unchanged (yes, there are some out there that do that).

            As you pointed out, reversing the digipeaters in a path is problematic as well.  What's an alias and what's a digipeater?  Especially with things like CHLSEA in the mix coupled with some new stuff apparently going on overseas like WIPIW4-5, ITA3-3, POEE2*, TEST2-2, VFR1-1, ILAZ1-1.  These are actual path components detected by APRSISCE/32 as being "possible aliases".

            You can see what APRSISCE/32 considers a possible alias by looking at Configure / Aliases / Possible and scrolling down through the menu. Those have all appeared at one time or another as a path component in a received packet and match Bob's definition of an alias as "ends in a digit" with an optional -SSID.  If you do look at this menu, be careful because if you select one from the Possible list, it will make it a defined "Known" alias which affects which portions of packet's paths are ignored and/or processed when doing the Screen / Paths / Appearance lines.

            By the same token, it is important that you have all of the known aliases in use in your area defined in Configure / Aliases / Known or there will be holes in the above-mentioned path lines where the "digipeater" (the unknown alias) is not a known station and therefore not plottable as a line.

            Bottom line: a message or ack is no different than a locally generated beacon and will be transmitted using the same configured path until I implement QSO-specific path entry.

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

            On 11/8/2013 3:21 PM, Rob Giuliano wrote:
            Wouldn't the path show as a group of callsigns that have been inserted to replace WIDEn-N or any other Alias?
             
            EXAMPLE:
              ECET5W,W8OAK-14,CHLSEA*,WIDE2-1,qAR,W8HHF-15:`o51lJb>/]"7>}=
            Which probably came from: 
              ECET5W,WIDE1-1,WIDE2-2,qAR,W8OAK-15:`o51lJb>/]"7>}=
            if you only get the second part that shows callsigns and aliases, how can you know what the original part was?
            On the other hand, if you reversed it and sent via:
               CHLSEA, W8OAK-14
            How can you be sure those station WILL "respond to" (digi) of its callsign-ssid that was inserted.
            They may only digi off WIDEn-N.
               Even if each station does, it doesn't mean it was the most efficient path, just the "last successful" path.
               A closer station may have been overwhelmed by another local packet at that particular time.
             
            It would make sense that the BEST method would be to send with a given "generic" path and take advantage of
             
            Robert Giuliano
            KB8RCO


            ---------------------------------------------

            From: Lynn W Deffenbaugh (Mr) <kj4erj@...>
            To: aprsisce@yahoogroups.com
            Sent: Friday, November 8, 2013 1:59 PM
            Subject: Re: [aprsisce] Path's with APRSIS32

            (Corrected NOT smart enough)

            On 11/8/2013 12:41 PM, ptompkins@... wrote:
            I've dug around the manual and such and I did see a reference from a post from last year which stated that the path a message takes over RF is the same path that is defined as the Beacon.

            Is that correct?

            Yes, that is correct.  Currently, everything transmitted by APRSISCE/32 uses the Configure / Beacon / Path except for objects which have a per-object path definition which defaults to the Configure / Beacon / Path when the object is first created.

            So if my "Configure" / "Beacon" / "Path" is WIDE1-1,WIDE2-1 that is where my default messages over RF go correct?

            Yes.


            Next question, in the attached screenshot I see a line which shows how the packet got to me (Really cool BTW!).

            Yes, and you can see even more than just this one path line if you use Screen / Paths / Appearance and play around with the various settings in there.  For instance, here are all of the Direct and First hops of packets sent by N4GVA-2, an aerial photographer who did a flight diagonally across Florida this morning.  And balloonatics still insist that they need to have a path when they fly, but that's another soapbox.




            If I try to talk to that station is the software smart enough to know the path to send the packet or will it go the same path as the message path (Which I believe to be the Beacon path which I have WIDE1-1,WIDE2-2).

            No, it's not "smart enough" and I suspect that neither are you or anyone else unless you've spent a good deal of time studying your local RF network.  There was an extensive discussion in the aprssig recently about "reversing" the received path for APRS messages, but IMHO it's just not possible given the variety of digipeaters out there and random levels of WIDEn-N support (not to mention SSn-N which replaces rather than inserting callsigns).  Even if a message is received with SS7-3 in the path, that doesn't mean that an SS4-4 is necessary to respond.  The original message may have only been an SS7-4 but there's no way to tell.  And reversing the used digipeaters isn't a good idea either because the fact that A hears B hears C doesn't mean that C hears B hears A.

            Eventually there will be a per-Chat path specification that will control the path used for messages and acks within that particular QSO, but for now Configure / Beacon / Path is the only game in the APRSISCE/32 town.


            Finally, how many times will a message try to transmit before it gives up over RF because of no replied ACK. ?

            Only as many as necessary or until the software give up!  But then it will try again for another batch of retries until it REALLY gives up.  But then, you can manually trigger another set and another set and another set until either an ack is received or you manually cancel that pending message.  Please read http://aprsisce.wikidot.com/message-retries for additional details.


            I'm sorry for all my newbie questions.

            Questions are good.  It means that someone's actually using the software!   Ask anytime.  But please be aware that sometimes the answer may only be a link to a Wiki page.

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




            Phillip
            KD7QOT





          • James Ewen
            On Fri, Nov 8, 2013 at 11:59 AM, Lynn W Deffenbaugh (Mr) ... else ... Anyone using APRS *SHOULD* study the local RF network, and understand
            Message 6 of 6 , Nov 8, 2013
              On Fri, Nov 8, 2013 at 11:59 AM, Lynn W Deffenbaugh (Mr) <kj4erj@...> wrote:

              > No, it's not "smart enough" and I suspect that neither are you or anyone else
              > unless you've spent a good deal of time studying your local RF network.  

              Anyone using APRS *SHOULD* study the local RF network, and understand the topology of their local network. From the knowledge gained there, they will know what an appropriate path would be to use in their area. Watching the local RF network teaches you which digipeaters can which other digipeaters. You learn the paths that packets can travel, and just how far a packet will travel based on the number of hops used.

              People that do not invest the time in learning this information about their local network can easily become a burden to their network by using paths that cover too much area, or putting out too many packets, and clogging their local network.

              You don't just fire up the HF rig, crank the amplifier to full power and start yapping away... (at least you shouldn't). You should be listening, and understanding the propagation characteristics so you don't clobber other people, and have a better chance of getting a signal into the desired area. Hop requests in APRS are equivalent to the power setting on HF. You use as little as required to get the communications desired completed. There's no need to push 1000 watts to talk to your buddy 3 miles away.

              *IF* all APRS digipeaters were set up properly, responding to the same ALIASES in the proper and consistent manner, it is extremely simple to do some forensic investigation into the packets received. Not only is there evidence showing the digipeaters used, but also the original hop request.

              However due to people not investing the time to understand the application of APRS and how digipeaters are supposed to work, and just slapping something together, as well as non-compliant digipeating rules in hardware and software based digipeaters. You can have a look at the common digipeating concepts used by APRS here: http://aprsisce.wikidot.com/doc:digipeating

              When non-compliant digipeating rules are invoked, it can make it difficult to be able to reverse decode the path the packet traversed to get to the destination. It is possible to be able to build an efficient "shortest return route" path be knowing the location of the desired end station, and having a "network neighbors" list (or map). You basically create a routing list which contains the digipeaters required to get a packet from the origin to the desired destination.

              Because APRS is a best effort network, and in some cases a severely overloaded, or poorly implemented network, it can be difficult to ensure that the path chosen will get the information to the desired end point. Add into that the vagaries of VHF propagation, where paths can exist at one point in time, and not a few minutes later, it becomes difficult to be able to truly build an accurate and reliable map.

              It takes a lot of statistical averaging of observations of the network to really get a good grasp of which digipeaters can hear each other on a regular an reliable basis. There are add-ons that have been developed to try and measure the network health and reliability. Using these concepts and programs, it is possible to get a better understanding of what you are seeing, and how the local network is performing.

              Lynn's routines that show the paths a packet *may* have taken help visualize your local network, but there's no way to know if the path between point A and point B carried a single packet during a brief ducting event, or if it is a highly reliable path between both points. The observer needs to watch the activity and make those kinds of determinations. It also can't know that a non-compliant midpoint digipeater never inserted it's callsign, and that what appears to be a valid path from point A to point C actually passed through point B enroute.

              It's these kind of issues that make Lynn pull his hair out and declare that no one is smart enough to know how to build a reverse path to get a packet back to the origin. You need a fair bit of statistical averaging, long term observation, deductive reasoning, and sometimes some basic gut-feelings to figure out what is happening.

              I have been doing APRS network observation and path analysis for nearly 2 decades, and I can spend hours trying to decipher the information found in a packet. Sometimes you have to dig through packets from neighboring stations looking for the evidence you need to be able to back up your theory on where the packet may have gone if you are dealing with non-compliant digipeaters in the mix. Quite often there is no way to prove anything conclusively, but through conjecture and circumstantial evidence, you can come to a most likely conclusion.

              Looking for i-gates causing delayed packet delivery to the internet also requires a bit of detective work. I spent countless hours gathering evidence to back up my claims that it was the i-gates that were delaying the packet delivery, not digipeaters hanging onto packets on the RF channel. There were a handful of us that shared information back and forth for a number of weeks, defending our theories and concepts before we finally tracked the issue down to the Kantronics firmware bug that causes the delays. 

              If you watch for long enough, you can build yourself a very complicated network map, but you can decipher the information provided enough to learn how your local network actually works.

              Inline image 1

              --
              James
              VE6SRV
            Your message has been successfully submitted and would be delivered to recipients shortly.