[aprssig] HF noise measuring campaign reports via APRS

[Robert Bruninga]

Segway:

I hope that packets that are not allowed by these narrow filters are still
captured somewhere.  The concept of APRS was that EVERY packet represents
someone on the channel and their presence should be captured.

IE, any non-pre-defined packet still causes that station to be captured,
added to the station list, and the raw packet to be indicated as his
"STATUS".

Further his position should be identified as an ambiguity circle around
his first used digipeater if known.  And his symbol should be a big
question mark.

Hope that helps.  Im not following this thread, but EVERY packet on an
APRS channel has information of value.  APRS is supposed to capture that
info.

I know this is off topic, because you are trying to get these new packets
into a proper format, but it reminds me that NOTHING should be ignored on
the APRS channel.  This also allows APRS to be used as-is as a channel
montitor on ANY packet channel and to find anyone on the channel.

Bob, Wb4APR

-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Lynn W. Deffenbaugh (Mr)
Sent: Monday, September 17, 2012 8:25 AM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] HF noise measuring campaign reports via APRS

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
>


_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig