[aprssig] javAPRSSrvr 4.0 filter changes (was: HF noise ... via APRS)

[Lynn W. Deffenbaugh (Mr)]

Pete has assured me that all packets are passed throughout the 
infrastructure.  It is only the t/ (type) filter that enforces tight 
spec compliance.  A buddy or prefix filter works solely on the 
originating station ID.  Any of the position-based filters rely on 
having parsed a compliant position-containing packet.

But if a client filters on a specific type of packet, then the packet 
must be a spec-compliant (with the filter author providing his/her own 
definition of compliance) instance of that type of packet.  And since 
the telemetry spec says 3 digit values in the range of 0..255, that's 
what it must be in the upcoming javAPRSSrvr 4.0 filter implementation.

But again, ONLY for type-sensitive filters, and ONLY for filtered 
feeds.  The infrastructure will continue to carry all packets appearing 
to come from valid amateur radio callsigns and entering via validated 
APRS-IS connections.

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

PS.  Don't shoot me, I'm only propagating what I've learned of the 
upcoming changes as I discover them so that we can all set our 
expectations and avoid potentially unpleasant surprises.

On 9/17/2012 8:48 AM, Robert Bruninga wrote:
> 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
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>