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

Re: [aprsisce] Object Paths

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