[aprssig] FREQ Object Formats

[Lynn W. Deffenbaugh (Mr)]

On 5/7/2012 5:18 PM, Bob Bruninga wrote:
> 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?

Not yet, but hopefully within a month or two D700s will get QSY/Tune 
capability compliments of APRSISCE/32.  And other non-APRS radios may 
gain the same capability as time goes forward.

And even if I don't do rig control, I want to display USABLE information 
to the user from a frequency object.  I'd rather show a REAL offset than 
+/- just in case the end user has a non-standard-offset (read cheap) 
radio.  S/He may be visiting the area with just a Baofung HT and not 
know the local standards.

And if this is all about Local information, then I firmly believe ALL 
information should be presented with no assumed knowledge on the part of 
the observer, especially in light of 3 bytes.

> 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.

+/- by itself is NOT in humanly USABLE form.  It implies local knowledge 
that a visitor to the area may NOT have.

And why not make something BETTER instead of just saying everything 
before this ignored the spec and left the interpretation up to the 
viewer when some programs want to make things more usable and less 
cryptic (+060 doesn't tell me 600KHz, which is what APRSISCE/32's 
interpreted frequency information IS displaying).

> Are we making a mountain here?

I'm not.  I'm only responding to your original unilateral statement of 
"#2) best thing we can do is NOT TRANSMIT ANY OFFSETS IF THE OFFSET IS 
STANDARD."   That may be "best" for owners of offset-aware radios being 
operated in their home region, but certainly isn't "best" for the very 
visitors that the local information initiative is targeting.

Again, with respect to the offset, I'm not asking for a change in the 
spec, but a change in your proposed recommended usage of the spec.  
Instead of pushing +/- that requires local knowledge and/or localized 
versions of future APRS-capable radios, just recommend +/-nnn so that 
the information is fully available in the objects.

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


>
> 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
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>