On Tue, May 8, 2012 at 3:15 PM, Bob Bruninga <email@example.com> wrote:
I agree that they have it wrong... the format they use is notHere's an object my peers in Calgary are sending in order to get;146.85-NH*111111z5106.50N/11405.92Wr146.850MHz T110 -060 R50k RYC
compliant with the spec.
See my object 147.105md on the air. Not only does my D72 andHere 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
There is nothing that says the RX frequency HAS to be in another band.The second frequency according to the current specOnly if it is a crossband repeater. Otherwise only the OBJECT NAME or the
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
The whole basis of this discussion is that the KENWOOD line is NOT theand 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
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.
It is NOT spec compliant... we have shown you example after example,I know the Kenwood will QSY without the second frequencydigipeaters.
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 believe we have a solution at hand, but trying to get you to see theI'm thinking that they have come up with this hybridWe do have to figure out a solution. But I don't see how you can claim 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