[aprssig] FREQ Object Formats

Mon May 7 17:45:46 EDT 2012

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
>