[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