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

Packet collision avoidance and Telemetry Delay

Expand Messages
  • Tony Komljanec
    Telemetry from solar powered OT2 digi VA3PLA http://aprs.fi/?c=raw&call=VA3PLA is having a really hard time getting through to distant repeaters.  I suspect
    Message 1 of 3 , Jul 7, 2013
    • 0 Attachment
      Telemetry from solar powered OT2 digi VA3PLA http://aprs.fi/?c=raw&call=VA3PLA is 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  
    • James Ewen
      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
      Message 2 of 3 , 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
      • Tony Komljanec
        Thanks for the response James.  I did search and find your previous discussion on this matter and how you resolved this telemetry issue.  Fortunately you
        Message 3 of 3 , Jul 10, 2013
        • 0 Attachment
          Thanks for the response James.  I did search and find your previous discussion on this matter and how you resolved this telemetry issue.  Fortunately you have control over your area digi's and can modify the quiet time to receive both consecutive posit and telemetry messages from the OT2. 
           
          I have to depend on 3 distant digi's controlled by others all in differnet directions, so no ability to modify them.  Since my digi is solar powered, I started this endevour at only 5W.  At that power the opportunity to get cobbered is very high.  I have a 30W mobile amp that I'll apply soon to improve my odds. 
           
          From the raw received packets, it is evident that only the OT2 scripted and autonomous messages are getting through.  We can go days without any posit or telemetry packet being successful.  OT2 sends them out together and it seems neither gets received successfully.  Almost like any error in the entire stream of 2 packets will cause both to be lost.  I'll adjust this to do telemetry every other posit to see if more posits get through.  Won't help telemetry though. 
           
          Ultimately, being able to trigger a telemetry packet from the OT2 script would resolve the issue.  Or placing a gap between consecutive packets sent by OT2.  Would Scott even consider this?  He has moved on to newer product.  
           
          Regards,
           
          Tony K
          VE3TK
        Your message has been successfully submitted and would be delivered to recipients shortly.