[aprssig] Maximum APRS Packet Lengths

[Steve Dimse]

> On Nov 29, 2016, at 1:12 AM, Kenneth Finnegan <kennethfinnegan2007 at gmail.com> wrote:
> 
> 3. Where did all of these different lengths for comment fields come from?!
> 
Perhaps there was some actual math involved (like Bob fitting a list into an 80 character screen), but knowing Bob they might just be something like "67 characters seems about right for message length". They date back far enough that most if not all were set by Bob alone when he was the sole developer.

> 4. Do we want to consider loosening up the maximum packet length for some of these data types? 
> 
Before I'd even consider this discussion I'd want to see some proof that there is a need. If APRS has survived for twenty five years with these limits what exactly is the problem? The negative effects of having 255 byte packets floating around on RF are real, I'd want to see a demonstrated need before even considering an expansion.

> 5. Does anyone happen to know the actual length limits on messaging for various devices out in the wild already?
> 
You break a lot more than devices. Since every APRS client has at its heart a database whether using an actual database manager or code of its own, each and every piece of APRS is at risk in such a proposal. 

The decision to store data in fixed or variable length records is something faced by everyone that writes APRS software. Storing messages in an array of say 70 character strings is very efficient in terms of programming time and CPU cycles, you know that the 25th message starts 24*70 bytes into the array and that a new message can easily reuse the slot of an obsolete message. The trade-off is you waste bytes of RAM and/or disk with short messages. If you go to variable length storage then you need to keep an index of the start of every message and you must perform more complicated garbage collection to reuse storage. You save bytes and lose cycles as well as introducing more complexity, hence more programming time and debugging. My guess is most people make the same decision I did, to use fixed length records, so findU breaks if the message length increases. It certainly can be updated, but if I spend that effort I need for there to be a good reason. I've never heard it.

Steve K4HG