<div dir="ltr"><div dir="ltr"><div dir="ltr" class="gmail_attr">On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</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">APRS messaging was designed for single line AND paragraph messaging.<br>Just sent multiple lines that are NUMBERED and the APRS client on receipt<br>is supposed to store them in sequence.</blockquote><div><br></div><div>What? Where does the APRS spec ever say that clients are supposed to store messages in a particular sequence?</div><div><br></div><div>Do you mean for messages with message identifiers, or just messages with numbers at the beginning of each line?</div><div> </div><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><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <<a href="mailto:bruninga@usna.edu">bruninga@usna.edu</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">The problem is the 50,000 Kenwoods and Yaesu APRS radios that<br>
could not display these messages.<br>
<br>
APRS messaging was designed for single line AND paragraph messaging.<br>
Just sent multiple lines that are NUMBERED and the APRS client on receipt<br>
is supposed to store them in sequence.  This is certainly supposed to work<br>
for Builletins and Announcements.  BLN1, BLN2, BLN3 etgc...<br>
 Not sure if it works for messages with line numbers<br>
bob wb4apr<br>
On Wed, Nov 24, 2021 at 3:43 PM Heikki Hannikainen <<a href="mailto:hessu@hes.iki.fi" target="_blank">hessu@hes.iki.fi</a>> wrote:<br>
><br>
> 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>
<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></div>