<div dir="ltr">I have already done the math. <div><br></div><div><a href="https://github.com/PhirePhly/aprs_notes/blob/master/APRS_MTU.md">https://github.com/PhirePhly/aprs_notes/blob/master/APRS_MTU.md</a></div><div><br></div><div>The maximum payload length for APRS messages is 197 bytes.<br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">--<br>Kenneth Finnegan<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 24, 2021 at 12:43 PM Heikki Hannikainen <<a href="mailto:hessu@hes.iki.fi">hessu@hes.iki.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 21 Nov 2021, Kenneth Finnegan wrote:<br>
<br>
> 3. Sharing the same TX delay for multi-line messages or bulletins <br>
> because the message length limit is so ungodly short because of the IBM <br>
> PC screen width limits<br>
<br>
This is actually something I'd like to improve a bit. The limit indeed is <br>
way too short, and we should figure a way to increase it for modern <br>
software without breaking a lot of things. I bump into the limit every <br>
time I do messaging and it is slightly annoying.<br>
<br>
Something like: APRS devices/software supporting a Long Messages feature <br>
shall accept message packets of up to 255 bytes. The total length of the <br>
recipient field, message id, reply-ack id, and the delimiters and packet <br>
format identifier characeter, must not exceed 255 bytes.<br>
<br>
27 bytes (with a message-id, and a reply-ack id):<br>
<br>
:N0CALL-14:Hello{msgid}rack<br>
<br>
28 bytes (after UTF-8 encoding, "ö" is 2 bytes):<br>
<br>
:N0CALL-14:Hellö{msgid}rack<br>
<br>
The maximum message payload length, in characters, depends on language and <br>
the length of the message-IDs. When a user enters a message, the sending <br>
application shall try encoding the message, taking into account the <br>
maximum length of the message-ID which may be used, and limit the message <br>
length accordingly.<br>
<br>
If a very long message is split into multiple APRS messages, care must be <br>
taken to perform the splitting on a character boundary, or a word <br>
boundary. If splitting would be done at an arbitrary byte offset, a <br>
multibyte Unicode character could be broken into multiple messages, <br>
preventing UTF-8 decoding.<br>
<br>
Then we can add a field in the APRS device identification database [1] to <br>
mark devices supporting Long Messages, and other software using the <br>
database will know that the recipient will accept them.  It won't have <br>
backwards compatibility for older versions of such devices which do not <br>
yet support Long Messages, when a newer version does, but I suppose we can <br>
live with that. Just upgrade the thing.<br>
<br>
Alternatively, we'd have to somehow do in-band signaling of support for <br>
this feature, perhaps by abusing the message-id contents somehow, and it'd <br>
only enable long messages after the first message. And still there would <br>
be some risk that it'd get enabled accidentally for a recipient which <br>
doesn't accept them.<br>
<br>
[1]: <a href="https://github.com/hessu/aprs-deviceid" rel="noreferrer" target="_blank">https://github.com/hessu/aprs-deviceid</a><br>
<br>
   - Hessu<br>
_______________________________________________<br>
aprssig mailing list<br>
<a href="mailto:aprssig@lists.tapr.org" target="_blank">aprssig@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/aprssig_lists.tapr.org</a><br>
</blockquote></div>