[aprssig] Chemical sensors

[Kevin Brown - KC0CZI]

As a member of a haz mat response team:

*IF* something like this does come forward, the format needs to have a
sufficient number of bits to provide the granularity of the results
transmitted needed.  

The positional information of the sensors is very important.

Lastly, the format ought to be something that can be fed into the plume
modeling software applications that are out there and/or the predominate GIS
applications.

Knowing where the sensors are, ensuring the datastream follows or can be
output into the existing format used by the modelers, and providing seamless
connectivity to the models are three big things that ought to be done if
this is to really be a useful application for anyone beyond experimenters.
If we want to provide APRS as a useful application to our served agencies -
the tests are much more specific.

RAE systems already transmits their telemetry through a product called
Rae-link and it's generally found in the 2.4 Ghz spectrum.  I've not tried
to dissect the format.  Most of the precision weather stations sold to haz
mat teams also provide a serial data stream that can then be connected to
the modelers.  Again, I've not dissected the format.

To be sure, those systems and accompanying applications will always be more
important than APRS when we're in the field - until such a time as the
technologies can actually be blended, our APRS participation is strictly
limited to the capabilities of the D700 on-board.

Whatever happens here ought to be extremely conscious of it's worth to
served agencies.


-----Original Message-----
From: aprssig-bounces at lists.tapr.org [mailto:aprssig-bounces at lists.tapr.org]
On Behalf Of Robert Bruninga
Sent: Friday, October 08, 2004 7:47 PM
To: aprssig at lists.tapr.org
Subject: Re: [aprssig] Chemical sensors


>>> spider at rivcom.net 10/8/04 7:58:40 PM >>>
>I think it needs to go way beyond the spec and into a new relm.

Yes, that is what the Experimental Extension set was set aside for...

>I would  suggest this sort a telemetry packet that could also
>contain weather sensors....

Disagree.  The current spec allows for WX data, so we should continue to
send WX data in APRS WX format so that everyone can still see WX as WX.

>We waist a lot of space in a packet  dealing with locations.... which 
>is NOT necessary for sensor data.....for the vast majority of sensors.

Wow, I sure would like to know what sensor is of any value whatsoever, if
you dont know where it is???

Keep it simple.  Put WX data in the WX packet, and invent
a new format for Sensor data.  But by all means the position should be
included.  And it only takes 3 bytes (if you use the Mic-E format).  But
dont use the Mic-E identifier so that these new packets dont all get thrown
in by old software as mobiles.

So the on-air format would be:

SENSOR>abcdef:WIDE1-1:{STLLL........................
Where SENSOR is the Sensor's call
            abcdef is the LAT etc similar to Mic-E
            WIDE1-1 is the digipeater list
            {S is the Experimental identifier
             T is one of 91 different types of sensor
             LLL is Mic-E style Longitude
             .................. is then everything else you want to 
put in
             this packet....

Advantages are:
1)  Uses new format in accordance with APRS SPEC
2) Uses very condensed Mic-E "type" encoding
3) But is NOT a Mic-E so it does not confuse existing code
4) Each packet is fully stand-alone because it includes position of sensor
5) Total cost of the position is only 3 bytes (good to 60 feet)
6) If you insist, then make it LLLL good to the nearest foot.

something like that?

de WB4APR

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig