[aprssig] FREQ Object Formats

Mon May 7 18:42:11 EDT 2012

It is not "allowed".  Just because the Kenwood just happens to misinterpret
it and just luckily gets it right, does not make it in accordance with the
spec.  The only allowed offsets are +xxx or -XXX (in 10s of KHZ).    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:46 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] FREQ Object Formats

On 5/7/2012 5:32 PM, Bob Bruninga wrote:
>> Here is what I am transmitting for frequency objects
>> which work with the TM-D710A North American version:
>> ;444.80TRF*111111z4807.60N/09610.63WrT156 + R15m
> But, "works" is debatable.  The "+" is not part of the spec.

And why is it allowed for frequency position packets and not for
frequency object packets?  I was not going to bring this up until the
current bruhaha settles, but since you mentioned it.

For the sake of future APRS radio implementers, I believe we need to
take this opportunity to UNIFY the frequency specifications.  There's no
reason that I can see for frequency objects to have some capabilities
and frequency comments to have others.  If it's good for the goose, it's
good for the gander.

>> The " + " is required, otherwise the D710A does not apply any offset on
> UHF.
>
> The D710 needs +500 which is the correct way to do the +5 MHz offset.  The
> fact that a bug in that radio might be seeing the + and then not
> understanding the following 3 bytes and just defaults to the 5 MHz is just
> luck, not part of the spec.

And just because the D710 doesn't need the +060, other APRS-capable
radios visiting the area might need it.  Standards should be standards
and not target one favor one vendor or implementation over another.

>> For VHF I transmit:
>> ;146.85TRF*111111z4804.29N/09606.79WrTOFF - R40m
>> For VHF ' - ' is not required,
> Since it is not in accordance with the spec, it just adds confusion and a
> perpetuation of non-spec compliant packets on the air.  In North America,
> the standard for 147 MHz repeaters is +600KHz offset and 146MHz and below
> have -600 KHz offsets.

But visitors to North America with non-offset-smart radios don't know
that, so why not tell them explicitly with no inferences?

>> I am including [the -] to be congruent with the UHF version,
>> which isn't much of a reason I will admit.  I could instead
>> include the offset as +500 and -060 respectively, but since
>> these repeaters use the standard offsets I don't.
> Exactly. All of the APRS radios that have the auto-TUNE/QSY function will
> use the standard at least on 2 meters and the Yaesu I think does it on
both.
> But my recommendation is to not transmit the offset in North America on
VHF
> and to always include the +/-500 on UHF.

And they won't work with just a + or - if they're not from the proper
country.  We have a chance to FIX this to work with WHATEVER the
operator has with them instead of making assumptions about anything.

>> As a check I looked at the first 10 VHF and 10 UHF frequency
>> objects I came across on APRS.FI and only 2 VHF and 1 UHF
>> frequency objects were compatible with the D710A.
> Yep, I agree, most FREQ objects on the air are wrong.  SO I am so glad we
> are gifinalluy getting everyone's attention.

And if we're going to get them to fixed, then let's get them fixed in
the most flexible and informative a fashion as possible.

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

>
> Bob, WB4APR
>
>
>
> ________________________________________
> From: Bob Bruninga<bruninga at usna.edu>
> To: 'TAPR APRS Mailing List'<aprssig at tapr.org>
> Sent: Monday, May 7, 2012 1:59 PM
> Subject: Re: [aprssig] FREQ Object Formats
>
>> And a close second... is people transmitting a
>> frequency OBJECT with the SAME frequency duplicated
>> in the comment of the object.
> That is simply wrong.
>
>> According to the spec (which I'm hoping to change),
>> this second frequency is the RECEIVE frequency.
> But only for CROSS Band or odd-splits.
>
>> 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.
>
>> The current spec at http://www.aprs.org/info/freqspec.txt says:
>> If both the object name and the comment contain a frequency,
>> then the name is considered the transmit frequency...
>> and the frequency in its comment text is its split receive frequency.
> 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?
>
>> #2) best thing we can do is NOT TRANSMIT ANY OFFSETS IF THE OFFSET IS
>> STANDARD.
>> 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.
>
>> 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.
>
>> 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.
>
>> 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.
>
> Bob, WB4APR
>
>
>
> _______________________________________________
> 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