[aprssig] FREQ Object Formats

Mon May 7 19:07:45 EDT 2012

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

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

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