[aprssig] FREQ Object Formats
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Mon May 7 19:19:38 EDT 2012
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
>
More information about the aprssig
mailing list