Re: FREQ OBJECT Uniqueness

James Ewen

On Tue, May 8, 2012 at 3:15 PM, Bob Bruninga <> wrote:

Here's an object my peers in Calgary are sending in order to get
"proper" QSY functionality on their Kenwood radios.
;146.85-NH*111111z5106.50N/11405.92Wr146.850MHz T110 -060 R50k RYC

They insist that the radio will NOT QSY without the second
frequency in the comment, and the offset included.
Sorry, They need to re-check.  The OBJECT with only a FREQ in the name works
fine here.
I agree that they have it wrong... the format they use is not
compliant with the spec.

 See my object 147.105md on the air.  Not only does my D72 and
D710 QSY, but they also properly do the weird -500 KHz shift I included.
Here it is in all it's non-compliant glory!

;147.105md*111111z3859.33N/07629.33WrT107 -050 R22m

Check it against the specification for a FREQUENCY OBJECT

;FFF.FFFxy*111111zDDMM.hhN/DDDMM.hhWrT079 R25m NETxxxxxx MTGxxxx...

You're good on the object name, position, tone, and range, but there's
a non-compliant offset direction and magnitude included. There is no
provision for an offset and magnitude defined in the FREQUENCY OBJECT

The second frequency according to the current spec
should be interpreted as the RX frequency,
Only if it is a crossband repeater.  Otherwise only the OBJECT NAME or the
COMENT text has the frequency, not both.  Transmitting a packet with both is
not spec compliant unless it is a crossband repeater or split that cannot be
formatted into +xxx or -xxx.
There is nothing that says the RX frequency HAS to be in another band.
Normally one would not specify both the RX frequency AND offset, but
should that happen, the RX frequency should take priority. Kind of
like trying to figure out which icon to use when there's an SSID and
an icon described in the packet... the icon in the packet wins. Only
allowing an offset can create a problem when the offset require more
precision than x.xx MHz can provide. If you have some wonky repeater
on 144.100, and 147.995, the current offset can't describe that
abomination. (Yes I know 144.100 is a CW calling frequency, just an

and the offset is not a defined part of the FREQUENCY OBJECT.
It most certainly is.  "Tnnn -xxx (or +xxx)" works as it should for a FREQ
object in my D710's and D72's.
The whole basis of this discussion is that the KENWOOD line is NOT the
authority on the specification. Kenwood has implemented their
interpretation of what they think you have written on your
freqspec.txt page. There is nothing indicating that an offset can be
included in a FREQUENCY OBJECT packet. The offset description only
applies in the POSITION COMMENT as per YOUR specification.

I know the Kenwood will QSY without the second frequency
as I use it on all of the FREQUENCY OBJECTs that I send from my

Then it is disingenuous for you to be blogging that the Kenwood is non spec
compliant when it actually is.
It is NOT spec compliant... we have shown you example after example,
and you yourself have proven that it is not spec compliant with your
147.105md object above. By having the Kenwood change the offset to
-500 kHz, it proves that the Kenwood looks for an offset where there
should NOT be one.

I'm thinking that they have come up with this hybrid
to make BOTH the Yaesu and Kenwood "work".
We do have to figure out a solution.  But I don't see how you can claim the
Kenwood is not spec compliant.  We have to be careful of spreading
I believe we have a solution at hand, but trying to get you to see the
light is taking quite a while. Hopefully you will take the time to see
that what you have written down as a specification is not what you
THINK you have written down.

Specification has the word "specific" in it because when you define a
specification, you have to be very specific in your wording and
definition. Any ambiguity will be seized upon by the masses and
screwed up beyond belief, case in point right here.

Now, if we modify the specification slightly to remove the
inconsistencies between the two different formats, and make it work
like you "THINK" it is supposed to work, as well as how Kenwood and
Yaesu have implemented it, we can make everyone happy.

The problem is that the specification and the current implementations
are not the same. You can't expect people to implement things going
against the specification without dealing with the conflict. We should
be able to bring the specification to a place where it no longer
contains any ambiguity, and describes what has been implemented in
existing hardware.


Join to automatically receive all group messages.