<div dir="ltr">So I was chatting with some other APRS developers, and we got talking about the Maximum Transmission Unit (MTU) used for APRS and maximum APRS message length, particularly while considering UTF-8. Like usual, I started digging into it, and have come back up with more questions than answers... (You guys missed these from when I was working on my thesis, right?)<div><br></div><div>A summary of my digging is posted here: <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><br><div><br></div><div>So I ask myself, what is the maximum length for an APRS packet?</div><div><br></div><div>An APRS packet needs to fit inside the Information Field of an AX.25 UI packet, which is 1-256 bytes long in the context of APRS (It seems like AX.25 allows for zero length information fields, but I'd vote for not allowing zero length APRS packets inside of the Information Field, and APRS101.PDF lists 1-256).</div><div><br></div><div>So 256 is an upper limit, but there's also the risk that an APRS packet will get I-gated, and then be RF-gated somewhere else, at which point it needs to be encapsulated as a third-party packet. The way I see it, a third-party packet looks something like this:</div><div>}[SRCCALL]>[TNCID],[NETWORKID],[IGATECALL]*:[PACKET PAYLOAD]<br></div><div><br></div><div>The original APRS101.PDF document seems to encourage that you include all of the originally used path before the NETWORKID, but that seems to have gone out of vogue and only the fields shown above are included, from what I've seen.</div><div><br></div><div>Adding those up, we get 1+9+1+9+1+9+1+9+2 = 42 overhead for encapsulation in a third-party packet assuming you only include those four callsigns (SRCCALL, TNCID, NETWORKID, IGATECALL). 256 - 42 = 214! So the way I figure, 214 is the real MTU for APRS packets. I had always kind of assumed that this kind of encapsulation was the driver behind the length limits on things like APRS messages, but that doesn't seem to be the case.</div><div><br></div><div>APRS Message contents are limited to 67; add in the addressing and you get up to 84.</div><div>:[DESTCALL+PADDING]:[MESSAGE]{[MESSAGEID]<br></div><div>1+9+1+67+1+5 = 84<br></div><div><br></div><div>84 is way less than 214... Where in the world did this 67 come from? Even including 8 digipeater hops in the third party header, I still haven't been able to justify why we constrain the APRS messages so badly.</div><div><br></div><div>So then I ask the question of what the maximum length is for other packet formats, and continue digging:</div><div><br></div><div><div> * Location packets - 1+8+1+9+1+43 = 63</div><div> * Time stamped location - 1+7+8+1+9+1+7+36 = 70</div><div> * NMEA position - 1+209 = 210</div><div> * DF Report - 1+8+1+9+1+7+8+28 = 63</div><div> * DF Report w/ time - 1+7+8+1+9+1+7+8+28 = 70</div><div> * Compressed location - 1+1+4+4+1+2+1+40 = 54</div><div> * Compressed location w/ time - 1+7+1+4+4+1+2+1+40 = 61</div><div> * Object - 1+9+1+7+8+1+9+1+43 = 80</div><div> * Compressed object - 1+9+1+7+13+43 = 74</div><div> * PARM. - 1+9+1+5+7+7+6+6+5+6+5+4+4+4+3+3+3 = 79 (THIS IS LONGER THAN 67!)</div><div> * BITS. - 1+9+1+5+8+23 = 47</div><div> * Status report - 1+7+62 = 70</div></div><div><br></div><div>Man did that NOT help. Where in the world did these numbers come from?! Why are some comment fields limited to 43, where others are 28 or 40?</div><div><br></div><div>My favorite is the PARM. and UNIT. telemetry formatters which specify a 68 byte long message contents, which exceeds the 67 limit clearly documented for the ':' data type payload.</div><div><br></div><div>So then there's the question of what actual APRS devices do. I know that many TNCs support way less than 256 byte long APRS packets, since some of them only HAVE 256 bytes of RAM. That being said, they're already deficient since many of these packets + third party encapsulation exceed the TNC's capabilities. Checking Xastir and APRSdroid, they both enforce 67 byte limits, but APRSdroid interestingly will ack and display a 220 byte message sent to it, as will EMAIL-2... I can even send a message from Xastir with MORE than 67 bytes in it using multi-byte characters, since it seems to be enforcing 67 *characters*. Unsurprisingly, it would seem that Xastir does not handle rendering the extended character sets well either... APRSdroid did handle what gibberish I sent at it over APRS Messages from a telnet client (§,×,Δ, etc), which makes sense coming from Georg.</div><div><br></div><div>So my questions:</div><div><br></div><div>1. Do we still want RF-gates including consumed hops in third-party packets, or is that deprecated in favor of the "}[SRCCALL]>[TNCID],[NETWORKID],[IGATECALL]*:" 42 byte format? (If we're going to clarify that as being deprecated, we should probably include AEA format while we're at it)</div><div><br></div><div>2. Are there any other Network IDs in actual use except for TCPIP for APRS-IS? (Remember that TCPXX is already deprecated)</div><div><br></div><div>3. Where did all of these different lengths for comment fields come from?!</div><div><br></div><div>4. Do we want to consider loosening up the maximum packet length for some of these data types? </div><div><br></div><div>The way I figure, we could support 197 byte messages for APRS Messages. This is going to break sending long-winded messages to many devices, but 67 is awfully restrictive compared to modern features like SMS... Clearly new software is deliberately constraining fields based on the spec. I'll need to test length limits on the D700 I've got sitting on my bench. </div><div><br></div><div>5. Does anyone happen to know the actual length limits on messaging for various devices out in the wild already?</div><div><br></div><div>6. If not messaging, do we want to loosen some of the comment fields? 23 bytes for the BITS. Project Title seems like a strong contender for first to consider. Remember that we're talking about bytes here, not characters; many non-English languages using UTF-8 can burn through 23 bytes very quickly, so I'm talking about making Project Titles allowed up to something CRAZY like 190 so length just isn't an issue anymore.</div><div><br></div><div>7. Where did this 67 character limit on messages come from?! This really bothers me now.</div><div><br></div><div><br><div><div><div class="gmail_signature">--<br>Kenneth Finnegan, W6KWF<br><a href="http://blog.thelifeofkenneth.com/" target="_blank">http://blog.thelifeofkenneth.com/</a></div></div>
</div></div></div></div>