[aprssig] APRS Air Quality Monitoring

[Erik Bacon Beck]

I’m not sure of the right answer here, but I would prefer a solution that allows flexibility for adding future air quality parameters if cheap sensors are developed (NOx, SOx, CO2, CO, etc).

Thanks,

Erik
Sent from my iPhone

> On Oct 13, 2022, at 12:32, Jason KG4WSV <kg4wsv at gmail.com> wrote:
> 
> 
> full disclosure, I'm not interested in air quality sensors in particular, just APRS in general.
> 
>> On Thu, Oct 13, 2022 at 10:11 AM Patrick <winston at winston1.net> wrote:
>> 
>> 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.
> 
> If we're designing for APRS I'd suggest going the opposite direction - put everything in one packet to amortize the per-packet overhead.
> 
> I'd also prefer not to see fixed fields/field lengths.  Make every field optional and define it so order doesn't matter. 
> 
> KG4WSV>APRS:{AQ PM2.5 12.5
> KG4WSV>APRS:{AQ PM2.5 12.5 PM10 37
> KG4WSV>APRS:{AQ ozn 3 PM2.5 12.5 
> 
> 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.
> 
> -Jason
> kg4wsv
> _______________________________________________
> 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/20221013/c0facfe4/attachment.html>