[aprssig] FREQ Object Formats

Steve Daniels steve at daniels270.eclipse.co.uk
Mon May 7 14:45:23 EDT 2012


For info EI7TRG does not appear to be a crossband repeater. It's a normal
digipeater. 
But also broadcasts that the Tipperary Amateur Radio Club monitor 145.450
and 433.450. So perhaps a little misleading

In the offset part of the spec is the + required or is the lack of a -
assumed to be + as it usually is?

Steve Daniels
G6UIM
Torbay Freecycle Moderator
-----Original Message-----
From: aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] On Behalf
Of Lynn W. Deffenbaugh (Mr)
Sent: 07 May 2012 18:43
To: TAPR APRS Mailing List
Subject: Re: [aprssig] FREQ Object Formats

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


_______________________________________________
aprssig mailing list
aprssig at tapr.org
https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig





More information about the aprssig mailing list