[aprssig] Consecutive Packet Send

[Randy Love]

Define 'slight breaks', please.

If the digipeater is correctly configured, it will TX *at the instant it
sees the end of packet flag*.
There should be minimal tx delay, only enough to handle the time it takes
the transmitter to come up and stabilize, before the digipeater sends the
packet it is to digipeat. It is up to other stations on the channel to
listen before transmitting, but the digipeaters are meant to clobber each
other on the caveat that although they might hear each other, most uses
will be close enough to one or the other digipeaters to have FM capture to
cover the one farther away.

Sadly tho, most digipeaters are not configured properly.

Randy
WF5X


On Wed, Sep 22, 2021 at 7:01 PM Eric H. Christensen <eric at aehe.us> wrote:

> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Monday, September 20th, 2021 at 1:07 PM, Randy Love <rlove31 at gmail.com>
> wrote:
>
> > The burst method may not be compatible with local digipeaters... or some
> TNC's even.
> >
> > Some digipeaters transmit the split second they see an end-of-packet
> indicator under the assumption that the tx is done since the packet is
> completed. That would cause the digipeater to collide with the rest of your
> long packet that you are sending as a burst.
> >
> > This is done on purpose to induce the packet fratricide that is
> necessary for peak performance of APRS digipeating. (i.e. the digipeater
> will only be colliding with other digipeaters transmitting the same packet )
>
> So I understand this *but*...
>
> ...here's what I'm seeing in practice.  My i-gate sends out weather alerts
> for my local area to a path of WIDE2-1.  I just watched a thunderstorm
> warning go out that contained three packets.  These three packets went out
> with only slight breaks in between, hardly any time for the digipeater to
> retransmit before the next packet came out leading to a collision.  I've
> seen similar results when transmitting messages and telemetry parameters,
> too, meaning that at least half of the packets are being wasted and delayed.
>
> --Eric WG3K
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20210923/9119e2f7/attachment.html>