[aprssig] FREQ Object Formats

Mon May 7 19:25:52 EDT 2012

To clarify:

The example "FFF.FFF +" is only listed as an example in the SECOND 10-byte
field, which ONLY applies to a separately explicitly listed frequency.  It
is NOT part of the original FFF.FFFMHz format.  What I was referring to
below, is that it is also NOT parseable as part of the "xyz" part of an
OBJECT NAME either.

Let me say it again, the only parsable offsets are +xxx or -xxx where xxx is
in 10's of KHz.

Bob, Wb4APR

-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Bob Bruninga
Sent: Monday, May 07, 2012 7:19 PM
To: 'TAPR APRS Mailing List'
Subject: Re: [aprssig] FREQ Object Formats

>> Where-oh-where and why-oh-why does this keep poping up?
>> THE use of + or - by themselves IS NOT PART OF THE APRS FREQ SPEC.
Period.

> Really?  We're only going by reading what you wrote:

>>>    _FFF.FFF +    Alternate Frequency and standard shift

You pulled that from the list of possible xyz modifiers in the frequency
OBJECT NAME.  In that case the "xyz" have been chosen to be SPACE-SPACE-"+"
and have nothing to do with the parseable OFFSET field.  The "xyz" is not
parseable but is a way of differentiating HUMAN READABLE differences between
multiple FFF.FF objects with the same frequency.  I indicated that one must
select "xyz" to be unique in the world.  Using a simple "  +" is not unique
in the world.  And as I indicate, it causes the object to fail on FINDU.COM.

Since people are misinterpreting that use of the "xyz" unique identifiers,
Ill remove it.

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, May 07, 2012 5:34 PM
> To: TAPR APRS Mailing List
> Subject: Re: [aprssig] FREQ Object Formats
>
> 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
>>
>
> _______________________________________________
> 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

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