[aprssig] Making APRS text messages longer

[Kenneth Finnegan]

On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <bruninga at usna.edu> wrote:

> APRS messaging was designed for single line AND paragraph messaging.
> Just sent multiple lines that are NUMBERED and the APRS client on receipt
> is supposed to store them in sequence.


What? Where does the APRS spec ever say that clients are supposed to store
messages in a particular sequence?

Do you mean for messages with message identifiers, or just messages with
numbers at the beginning of each line?

--
Kenneth Finnegan
http://blog.thelifeofkenneth.com/


On Thu, Nov 25, 2021 at 7:52 AM Robert Bruninga <bruninga at usna.edu> wrote:

> The problem is the 50,000 Kenwoods and Yaesu APRS radios that
> could not display these messages.
>
> APRS messaging was designed for single line AND paragraph messaging.
> Just sent multiple lines that are NUMBERED and the APRS client on receipt
> is supposed to store them in sequence.  This is certainly supposed to work
> for Builletins and Announcements.  BLN1, BLN2, BLN3 etgc...
>  Not sure if it works for messages with line numbers
> bob wb4apr
> On Wed, Nov 24, 2021 at 3: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
>
> _______________________________________________
> 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/20211125/07786bcf/attachment.html>