[aprssig] HF noise measuring campaign reports via APRS

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Mon Sep 17 08:25:14 EDT 2012


As I learned the hard way, the upcoming javAPRSSrvr 4.0 release 
implements a very strict definition of "packet type" with respect to the 
t/ filter.  Any non-3 digit value or value outside the range of 0..255 
will not be passed by a t/t (type/telemetry) filter.  Any non-type 
filter that hits the packet will pass it, but not a t/t.

My own APRSISCE/32-internal type filter implementation will pass any 
packet with a type (first) byte matching the type requested that has 
passed parsing.  I only parse for unsigned (per spec) longs of any 
length (not per spec), and will ignore any fractional parts without 
complaint (also not per spec).  A negative value will probably come 
through as zero to APRSISCE/32.  Per the spec, I require either a # or 
"MIC" to follow the T, and also require 5 values before accepting the 
telemetry values and identifying it as a telemetry packet.

Bob mentioned at one point an addendum that extended the original 0..255 
to allow 3 digits from 0..999, but never came back with a firm pointer 
to where that may be recorded.  AFAIK, floating point values were not 
mentioned recently.

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

On 9/16/2012 11:54 PM, Heikki Hannikainen wrote:
>
> By the way, a noticeable number of stations do seem to transmit 
> floating-point values in telemetry. Our perl parser currently accepts 
> them, I wonder how others treat them?
>
> The 0...255 requirement seems to be designed for 8-bit decoders, I 
> wonder if there are any of those around.
>
> On Sun, 16 Sep 2012, Lynn W. Deffenbaugh (Mr) wrote:
>
>> I agree that the standard APRS telemetry is definitely the preferable 
>> approach, but since your example packet (below) showed 8 floating 
>> point values of apparently some level of precision, I didn't suggest 
>> a format that only supports 5 values ranging from 0 to 255 (per spec, 
>> but some say 0..999) that can be scaled based on defined parametric 
>> equation coefficients.
>>
>>> 141916z6.999,-100.1,-110.1,-120.1,10.100,-101.0,-111.0,-121.0
>>
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>>
>> On 9/14/2012 4:40 PM, Chris Moulding wrote:
>>> Hessu,
>>>
>>> Thanks for the information about the telemetry packets. That looks 
>>> ideal especially when it displays in aprs.fi so well without any 
>>> software changes at your end!
>>>
>>> At the moment we are looking at three frequencies but with five 
>>> telemetry channels available it might make sense to go with five 
>>> frequencies from the start.
>>>
>>> 73,
>>>
>>> Chris, G4HYG
>>>
>>>>
>>>> If there's at most 5 frequencies monitored by a given station, you 
>>>> could
>>>> transmit it as standard APRS telemetry, and it would be graphed
>>>> automatically by all APRS receiving stations without any code 
>>>> changes in
>>>> the receiving end. Like this:
>>>>
>>>> http://aprs.fi/telemetry/a/OH7LZB-14
>>>>
>>>> You can also transmit channel names for each graph.
>>>>
>>>>    - Hessu
>>>
>>>
>>> _______________________________________________
>>> aprssig mailing list
>>> aprssig at tapr.org
>>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>>
>>
>>
>> _______________________________________________
>> aprssig mailing list
>> aprssig at tapr.org
>> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>>
>
>   - Hessu
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>





More information about the aprssig mailing list