[aprssig] FREQ Object Formats

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Mon May 7 19:02:42 EDT 2012


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

Wait, you're arguing to NOT suggest the explicit offset on one hand and 
on the other hand you're saying that +/- by itself is not "allowed", but 
MUST have the 3 digits?

Am I the only one confused now?

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



>
>
> -----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
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>





More information about the aprssig mailing list