[aprssig] HF noise measuring campaign reports via APRS
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Mon Sep 17 07:25:14 CDT 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
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.
>> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>> On 9/14/2012 4:40 PM, Chris Moulding wrote:
>>> 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.
>>> Chris, G4HYG
>>>> If there's at most 5 frequencies monitored by a given station, you
>>>> 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:
>>>> You can also transmit channel names for each graph.
>>>> - Hessu
>>> aprssig mailing list
>>> aprssig at tapr.org
>> aprssig mailing list
>> aprssig at tapr.org
> - Hessu
> aprssig mailing list
> aprssig at tapr.org
More information about the aprssig