[aprssig] Making APRS text messages longer

[Kenneth Finnegan]

I have already done the math.

https://github.com/PhirePhly/aprs_notes/blob/master/APRS_MTU.md

The maximum payload length for APRS messages is 197 bytes.
--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/


On Wed, Nov 24, 2021 at 12:43 PM Heikki Hannikainen <hessu at hes.iki.fi>
wrote:

> On Sun, 21 Nov 2021, Kenneth Finnegan wrote:
>
> > 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
>
> This is actually something I'd like to improve a bit. The limit indeed is
> way too short, and we should figure a way to increase it for modern
> software without breaking a lot of things. I bump into the limit every
> time I do messaging and it is slightly annoying.
>
> Something like: APRS devices/software supporting a Long Messages feature
> shall accept message packets of up to 255 bytes. The total length of the
> recipient field, message id, reply-ack id, and the delimiters and packet
> format identifier characeter, must not exceed 255 bytes.
>
> 27 bytes (with a message-id, and a reply-ack id):
>
> :N0CALL-14:Hello{msgid}rack
>
> 28 bytes (after UTF-8 encoding, "ö" is 2 bytes):
>
> :N0CALL-14:Hellö{msgid}rack
>
> The maximum message payload length, in characters, depends on language and
> the length of the message-IDs. When a user enters a message, the sending
> application shall try encoding the message, taking into account the
> maximum length of the message-ID which may be used, and limit the message
> length accordingly.
>
> If a very long message is split into multiple APRS messages, care must be
> taken to perform the splitting on a character boundary, or a word
> boundary. If splitting would be done at an arbitrary byte offset, a
> multibyte Unicode character could be broken into multiple messages,
> preventing UTF-8 decoding.
>
> Then we can add a field in the APRS device identification database [1] to
> mark devices supporting Long Messages, and other software using the
> database will know that the recipient will accept them.  It won't have
> backwards compatibility for older versions of such devices which do not
> yet support Long Messages, when a newer version does, but I suppose we can
> live with that. Just upgrade the thing.
>
> Alternatively, we'd have to somehow do in-band signaling of support for
> this feature, perhaps by abusing the message-id contents somehow, and it'd
> only enable long messages after the first message. And still there would
> be some risk that it'd get enabled accidentally for a recipient which
> doesn't accept them.
>
> [1]: https://github.com/hessu/aprs-deviceid
>
>    - Hessu
> _______________________________________________
> 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/20211124/b806c359/attachment.html>