[aprssig] FREQ Object Formats
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Mon May 7 13:42:56 EDT 2012
On 5/7/2012 12:58 PM, Bob Bruninga wrote:
> By the way, the #1 problem is people not doing the Tnnn correctly, That is
> the #1 error I see on the air. All of the tones are channelized, we do not
> need to WASTE byte sending decimals!
And a close second if not the number 1 problem is people transmitting a
frequency OBJECT with the SAME frequency duplicated in the comment of
the object. According to the spec (which I'm hoping to change), this
second frequency is the RECEIVE frequency. So, when the two frequencies
are the same, the implication is a simplex repeater. I suspect that
none of the radios are interpreting it this way, and 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,
and it allows the position comment have a single meaning and
specification, regardless of whether it's attached to an object or a
position 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 for the object and the frequency in its comment text is
> its split receive frequency.
I suspect that only myself and EI7TRG (who's beaconing an apparent
cross-band repeater as objects 145.450 and 433.450) are aware of this
piece of the specification. I've only found one object using the
FFF.FFFrx format and that's K3OCM-6's 147.505FL object with an explicit
146.505rx. If we "fix" the spec to allow redundant transmit frequencies
(name and/or FFF.FFFMHz in the comment) then only EI7TRG needs to change
his/her FFF.FFFMHz comment to FFF.FFFrx to bring the rest of the world's
frequency objects into compliance. Oh, and it becomes more obvious when
just reading the packet what the second frequency is as well.
> #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. I believe I've
read that there is no standard for 70cm repeaters, and even the
"standard" for 2m repeaters is somewhat fragmented and local. For the
sake of easy, GLOBAL, interpretation of offsets, I'd propose that we
recommend explicit offset transmission. People get so carried away with
redundant description text that scrimping on these three bytes of useful
information is short-sited, especially for visitors operating
foreign-model radios out of their home area, just the folks that we're
trying to make the system more useful for.
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 such that it ranges
from +001 (10KHz) through +060 (600KHz standard on 2m) through +999
which covers up to 9.99MHz offsets. I couldn't find any mention of
+n.nM (+0.6M for instance) in the specifications, so I'd really
appreciate it if someone could determine if any of the APRS radios
actually USE it. To truly determine that, you'll need to specify some
non-standard offsets and see if the radio actually honors them or
ignores them.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
More information about the aprssig
mailing list