[aprssig] Maximum APRS Packet Lengths
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Tue Nov 29 08:41:56 CST 2016
If you've ever experimented with actual ARPS messaging over the 2m
frequency anywhere except sitting in the driveway next to the IGate's
tower, you'd realize that longer messages and/or APRS packets in general
is not such a good idea. Remember, there's no error correction in AX.25,
only an error-detecting checksum. This means that even a single bit hit
trashes the entire packet. Longer in this case, is decidedly not better.
And when you throw digipeats into the mix, the stack against longer
packets makes even more sense.
This is why APRSISCE/32 allows the entry of longer messages to send, but
internally word-wraps them to fit within the max message limit. They
are then queued to send back-to-back, but only as acks are recevied
providing a throttle of sorts. You might have to be quick to read the
entire multi-line message as it is received on an APRS radio's small
screen, but it works.
As for multi-byte characters, I'm not at all sure any more if I handle
splitting those properly/safely or if I just split bytes. I'll confess
that I don't even know enough about them to even formulate and execute a
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 11/29/2016 8:55 AM, Robert Bruninga wrote:
>> APRS Message contents are limited to 67...
>> ... is way less than 214...
> Because the probability of delivery success for a 214 long packet is only
> 30% of the shorter 67 byte packet. Unacceptable.
> APRS was designed for short packets to keep the channel more reliable for
> Bob, WB4APR
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig