[aprssig] Chemical sensors

Keith Allen kallen2 at bellsouth.net
Fri Oct 8 22:41:26 EDT 2004



Kevin Brown - KC0CZI wrote:

>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.
>
    I think that some format needs to be formed and worked on.   
Remember, the reason for amateur applications is "when everything else 
fails".  So a format that would be seen appropriately on a d-700 easily 
(since it is the most prevalent APRS mobile 2-way mode) would be good. 
 As for served agencies, let's focus more on Amateur Operators helping 
the served agencies.  That way, if the 2+ gig system fails, there is at 
least some fort of backup.  I'm done rattling on.  73.   Keith Allen AG4AC

Former Decontamination Specialist for the Army (54B)


>
>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
>
>
>_______________________________________________
>aprssig mailing list
>aprssig at lists.tapr.org
>https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>  
>






More information about the aprssig mailing list