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

15725Re: [tracker2] Packet collision avoidance and Telemetry Delay

Expand Messages
  • James Ewen
    Jul 7, 2013
    • 0 Attachment
      I too have observed similar issues. I have a digi on a hill south of
      Fort McMurray that sends telemetry after each position report. A
      second digipeater in Fort McMurray digipeats the position packet while
      the first site is sending telemetry, making it very difficult for the
      i-gate in Fort McMurray to hear the telemetry packets.

      My work around was to delay the digipeating on the FTMAC machine so
      that it didn't try to digipeat when the STONEY machine was sending
      telemetry.

      This goes against the packet fratricide concept built into APRS by
      design, but through many years of observation I have come to the
      conclusion that the packet fratricide concept does not play out well
      on the flat prairie. There's far too much overlapping area of
      contention to allow FM capture to work.

      In areas where terrain obstruction allows for rapid signal level
      transitions, packet fratricide may work, but not out here.

      Using higher power in an effort to beat other signals into submission
      is a less than desirable technique, but many people utilize the
      technique. (One recent user bragged about using 150 watts on their
      APRS rig... I run at 5 watts hitting digis out to about 40 miles on
      the flats easily around here)

      A better option would be to not send the packets so close together,
      and that would be up to Scott to correct in the firmware.

      Another preferable option would be to support compressed telemetry
      appended to the position packet, making one short packet instead of
      two packets. Again, a firmware change.



      On 7/7/13, Tony Komljanec <tkomljan@...> wrote:
      > Telemetry from solar powered OT2 digi VA3PLA
      > http://aprs.fi/?c=raw&call=VA3PLA%c2%a0is having a really hard time getting
      > through to distant repeaters.  I suspect that this is because the OT2
      > combines the telemetry packet with one of the other position packets.  The
      > issue was observed in urban area's as well.   Consistently it is the
      > telemetry packet that gets clobbered by digi's that are dutifully repeating
      > OT2's concurrent packets.   Position packet could be made shorter, as these
      > are getting clobbered too.  Consistently, the scripted messages (sent on
      > their own) seem to get through just fine as evident in the raw log.
      >
      > I'll be increasing the TX power to assist getting through more often (fight
      > other traffic with more power).  Are there any other settings on an OT2 that
      > would allow independent telemetry packets without combining position?
      >  Scripting issuance of a telemetry packet should have this effect of
      > generating them independent of posit?
      >
      > Would this be resolved if Scott M inserting a mandatory quiet time between
      > OT2 generated concurrent packets instead of letting them loose without any
      > gap?
      >
      > There has been previous discussion about "viscous delay" and means to reduce
      > redundant digi's and traffic.  From what I'm seeing, telemetry success would
      > improve just by separating it from other OT autonomously generated packets.
      >
      > Advice graciously accepted.
      >
      > Tony K
      > VE3TK

      --
      Sent from my mobile device

      James
      VE6SRV
    • Show all 3 messages in this topic