<div dir="ltr"><div>full disclosure, I'm not interested in air quality sensors in particular, just APRS in general.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 13, 2022 at 10:11 AM Patrick <<a href="mailto:winston@winston1.net">winston@winston1.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br></div><div dir="auto">I would suggest rather than specific layout with fields for a fixed list of data, it may be better to have a message that transmits one data type per packet but multiple packets that can be sent for a range for additional data.</div></div></blockquote><div><br></div><div>If we're designing for APRS I'd suggest going the opposite direction - put everything in one packet to amortize the per-packet overhead.</div><div><br></div><div>I'd also prefer not to see fixed fields/field lengths.  Make every field optional and define it so order doesn't matter. </div><div><br></div><div>KG4WSV>APRS:{AQ PM2.5 12.5<br>KG4WSV>APRS:{AQ PM2.5 12.5 PM10 37<br>KG4WSV>APRS:{AQ ozn 3 PM2.5 12.5 </div><div><br></div><div>Parser shall be required to ignore field names it does not recognize and accept remaining data as valid. This allows for expansion without invalidating existing parsers.<br><br class="gmail-Apple-interchange-newline"></div></div><div dir="ltr" class="gmail_signature">-Jason<br>kg4wsv</div></div>