[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