Re: [tracker2] Packet collision avoidance and Telemetry Delay
- 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
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
- 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 KVE3TK