[aprssig] FREQ Object Formats

[Lynn W. Deffenbaugh (Mr)]

On 5/7/2012 2:59 PM, Bob Bruninga wrote:
> That is simply wrong. 

It may be wrong, but there's lots of objects out there doing it and only 
TWO doing it (apparently) correctly.

> But only for CROSS Band or odd-splits.

If it's there, people will use it, regardless of the fine print.

>> I'd like to see the receive frequency always require
>> the FFF.FFFrx and allow the (albeit redundant) specification
>> of the primary frequency in both the object name and
>> position beacon since that's how most of the world is doing it
> Then they are doing it wrong.  A complete waste of bandwidth when the
> comment text is supposed to convey additional USEFUL information.  Typicaly
> the extra bytes should be used for Weekly NET times and monthly Meeting
> dates as provided in the spec, not a dublication of the freq which is
> already in the packet.

Agreed, I'm not saying it's right, I'm saying it's what IS happening.

> Notice the key word "split" which does not refer to standard offsets.
> "Split" only refers to non-standard splits and cross band repeaters in the
> context in which I wrote it.  Maybe that needs to be clarified?

Clarified won't change all those objects that are out there.  I believe 
this is a "choose your battles".  If you want to get more local info 
objects on the air, that'd be my choice of battle rather than battling 
those that tried to put them up and may not have gotten it quite right, 
but at least the info is THERE.

>> This only works, IMHO, if there's a world-wide standard.
> But, it does *not* need to be worldwide.  It only needs to be LOCAL.  All
> radios sold in areas that have 600 KHz splits all do 600 KHz splits.  All
> radios sold in areas that do 500 KHz splits, do 500 KHz splits.  And QSY
> Tuning of an APRS radio to a local object is entirely a local process.

There ARE people buying radios from other areas as well as moving from 
one area to another and bringing their equipment with them.  And they're 
the folks most likely to not know what the "standard" offsets are when 
they're visiting an area.  And the local information initiative is for 
VISITORS, not the locals, right?

>> I believe I've read that there is no standard for 70cm repeaters
> In the USA, the standard is +/- 5 MHz.  And it amazes me that people feel
> the need to indicate MINUS offset when the repeater is above 445 MHz where
> the offset can ONLY be MINUS.  And to indicate + offset below 445 MHz where
> the offset can only be + or it interferes with the band  plan.

Yeah, but for those of us trying to write code that works planet-wide, 
it's really difficult to implement even "local" bandplans without having 
a configuration nightmare for the users.  If we'd just recommend that 
the addition 3 digits be supplied, then my (and other APRS-IS author's) 
problems get much simpler - as do the radio vendors that haven't yet 
implemented the offset parsing.

>> sake of easy, GLOBAL, interpretation of offsets, I'd propose
>> that we recommend explicit offset transmission.
> Not needed in 99% of the cases.  So it is wasteful use of bandwidth.

Even for the border folks that cross between different bandplans?  I 
respectfully believe it's worth the 3 bytes and recommend 
non-position-describing comments.   (VE7ZKI-10's "District of Sooke", 
KA0GFC's "KA0GFC FREEBURG", W2SO's "Lancaster Amateur Radio Club", 
UNCAN's "S.Uncan MT".  Yes, there's LOTS of redundancy that would be 
better recommended away than something programmatically useful like 
explicit rather than implied offsets).

>> The issue with offsets is that some people are beaconing
>> +n.nM to get a MHz offset when the spec says +nnn is in
>> 10KHz units... [there is no] mention of +n.nM (+0.6M for
>> instance) in the specifications...
> If people simply followed the spec, everything would work.  And if Kenwood
> would implement standard +/- offsets on 70 cm then all our problems would go
> away.  Except for the MAJORITY of digipeater manually prepared frequency
> beacons that are incorrectly formatted.

APRS-IS software doesn't distribute "regional" versions and therefore 
"standard" offsets are less than helpful.  Can you tell me what + and - 
offsets are for everywhere that someone may be running my client?  My 
goal is to provide QSY/rig control based on received frequency 
information for those of us without APRS-native radios, but in order to 
do that, the packet needs to provide sufficient information so as not 
not require extensive customization by the user to define the local band 
plan that becomes wrong when they change areas.  Three bytes is a small 
price to pay for portability.

And remember, I'm only asking for a change in recommendation, not a 
change in specification for this one.

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

PS.  Even AE5PL-OG's W5MRC-RW's object comment "MARC" and W5MRA-R's 
object comment "MERA" are rather redundant and longer than the 3 extra 
digits of offset.  Remember, there are still radios out there that don't 
even do automatic offsets, so putting the actual numbers in the packets 
benefit them as well.