[aprssig] Chemical sensors

Robert Bruninga bruninga at usna.edu
Fri Oct 8 20:46:51 EDT 2004


>>> 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




More information about the aprssig mailing list