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

22887RE: [aprsisce] Strange path for repeater object.

Expand Messages
  • Tony VE6MVP
    May 12, 2013
      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.

    • Show all 16 messages in this topic