15725Re: [tracker2] Packet collision avoidance and Telemetry Delay
- Jul 7, 2013I 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
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
> 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
Sent from my mobile device
- << Previous post in topic Next post in topic >>