[aprssig] FREQ Object Formats
Bob Bruninga
bruninga at usna.edu
Mon May 7 19:33:51 EDT 2012
Read the first line of your quote. This was ONLY an example of the 2nd 10
byte field and is not parsable. It does not apply anywhere else. 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 7:20 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] FREQ Object Formats
Negative. I pulled that from a list of allowed 2nd 10 bytes,
http://www.aprs.org/info/freqspec.txt
> 2nd 10-BYTES Optional Added fields (with leading space)
> ---------- -----------------------------------------------------
> _Txxx RXXm Optional PL tone and nominal range in miles
> _Cxxx RXXm Optional CTCSS tone and range in miles
> _Dxxx RXXk Optional DCS code and nominal range in kilometers
> _1750 RXXk Optional 1750 tone, range in km, wide modulation
> _l750 RXXk Optional 1750 tone narrow modulation (lower case L)
> _Toff RXXk Optional NO-PL, No DCS, no Tone, etc.
> _Txxx +060 Optional Offset of +600 KHz (up to 9.90 MHz)
> _Exxm Wxxm East range and West range if different (N,S,E,W)
> _txxx RXXm Lower case first letter means NARROW modulation
> _FFF.FFFrx Alternate receiver Frequency if not standard offset
> _FFF.FFF + Alternate Frequency and standard shift
Like I said, you maybe better go brush up on your specifications. I've
been going through them with a fine tooth comb trying to make sense of
them and + by itself is certainly in there as legally specifying a
"standard shift" by my read of that list.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
On 5/7/2012 7:19 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
> 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
>
_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
More information about the aprssig
mailing list