[aprssig] Consecutive Packet Send

Mon Nov 22 22:54:22 EST 2021

On Randy's statement that "If the digipeater is correctly configured, it 
will TX *at the instant it sees the end of packet flag*" - a TNC should 
never be knowingly transmitting over another signal. How do you decide 
when a signal is present? Typically that's done one of three ways:

1. SQL/COR signal from the receiver indicating a good carrier
2. Receiver squelch with energy detect (VOX)
3. Modem is locked and receiving valid data

In none of those cases can the channel be assumed clear immediately 
after a flag. There's some variation in how #3 is implemented but for 
the OpenTracker series they all go by clock recovery status - each bit 
transition is expected to fall within a certain time window, and if a 
set number of transitions occur outside of the defined window, lock is 
considered lost and this is passed on to the carrier detect system which 
handles any configured delays.

If you really think super-fast turnaround after the end of a packet is 
important, I think that's the way to do it. It's sufficient to wait just 
one or two byte times after the last flag. If you're still getting bits 
at the expected times, the sender is probably still sending. If it's all 
noise, it's probably safe to assume it's done.

I'm pretty sure there are some implementations that don't do a 
contiguous Bell 202 signal between packets - they might have some dead 
time, or restart the modulator at a default phase value with each packet 
- but I think it's fair to impose some requirements on transmitters. If 
you want your back-to-back packets to go through, you make sure they're 
seamless. Anything else is just wasting half the benefit of the 
back-to-back packets anyway, because the receiving side has to go 
through clock sync again.

APRS is terribly inefficient already. Let's not make inefficiency a 
requirement.

Scott
N1VG

On 11/21/2021 11:35 AM, Kenneth Finnegan wrote:
> On Thu, Sep 23, 2021 at 7:14 AM Randy Love <rlove31 at gmail.com> wrote:
>
>     Sadly tho, most digipeaters are not configured properly.
>
>
> A slightly different take on this is that there's a large contingent 
> of operators that think this fratricide theory is nonsense. I haven't 
> seen any robust justification that this actually works other than "you 
> know, FM capture effect is a thing so this should work in theory"
>
> There's just so many different scenarios where being able to transmit 
> more than one packet at a time is desirable that regardless 
> of fratricide actually working, I don't subscribe to it actually being 
> helpful:
> 1. Sharing the same TX delay for position and telemetry
> 2. Sharing the same TX delay for ACK and reply message
> 3. Sharing the same TX delay for multi-line messages or bulletins 
> because the message length limit is so ungodly short because of the 
> IBM PC screen width limits
> 4. Sharing the same TX delay for several digipeated packets which have 
> queued up while waiting for CSMA/CA to grab the channel
>
> The fact that Kenwood only shows the last posit on the display is a 
> bad reason to try and get stations to transmit multiple packets with 
> "slight breaks" between them. Fine, so now the Kenwood updates the 
> display five times at.... some fast interval and you still can only 
> read the last posit sent.
>
> The fact that we expect stations to transmit single packets at a time, 
> but then don't actually document some lower limit on packet interval 
> or required idle time between transmitting packets in the spec means 
> it isn't actually going to happen. When a TNC receives five packets to 
> send to RF, what is it supposed to do? Dump all five of them in a 
> single data stream, or buffer up the additional packets and introduce 
> one or several seconds of delay per packet in the transmit queue?
>
> The fact that some stations don't have enough buffer space to handle 
> more than one packet at a time sounds like a problem we shouldn't 
> still be accommodating in APRS routing behavior in 2021. Fine for deaf 
> trackers, but if a digipeater can't handle more than one packet at a 
> time, then it sounds like the digipeater needs better hardware. I 
> suspect that many modems also don't handle two packets sharing the 
> same flag byte between them because the receive state machine isn't 
> implemented correctly to handle that, but that should also be 
> something that is documented/tested so we can start improving the 
> situation or at least be aware of it instead of just assuming 
> multiple-packet transmissions shouldn't be happening.
> --
> Kenneth Finnegan, W6KWF
> http://blog.thelifeofkenneth.com/
>
>
> On Thu, Sep 23, 2021 at 7:14 AM Randy Love <rlove31 at gmail.com> wrote:
>
>     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
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at lists.tapr.org
>     http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20211122/5a272331/attachment.html>