[aprssig] FREQ Object Formats

[Bob Bruninga]

Explain again why a software client even cares about parsing the Freq spec.
Does APRSISCE do radio control?  If so, what radios are you supporting?

I am only aware of 3 radios that parse and act on Freq objects, the D72,
D710 and FTM-350.  All other APRS systems and all older aradios simply
display the data.  It is already in human readable form.

Are we making a mountain here?

Bob

-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Lynn W. Deffenbaugh (Mr)
Sent: Monday, May 07, 2012 4:18 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] FREQ Object Formats

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.


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