[aprssig] FREQ Object Formats

Mon May 7 15:54:21 EDT 2012

I agree.  It is a crossband repeater (simplex on either band).  Bob

-----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 3:06 PM
To: TAPR APRS Mailing List
Subject: Re: [aprssig] FREQ Object Formats

Yes, EI7TRG is a normal digipeater.  I was refering to the following two
frequency objects that it is transmitting:

EI7TRG>APOT21,EI2WCP*,WIDE2-1,qAR,EI3RCW-2:;145.450
*111111z5222.77N/00752.31Wr433.450MHz Tipp Amateur Radio Group
EI7TRG>APOT21,EI2WCP*,WIDE2-1,qAR,EI3RCW-2:;433.450
*111111z5222.77N/00752.31Wr145.450MHz Tipp Amateur Radio Group

The first one is 145.450 that has 443.450MHz as the first element of its
comment.
The second is 443.450 that has 145.450MHz as the first element of its
comment.

The spec says that the second (comment) frequency in a frequency object
is the split receive frequency, I'd have to say they're advertising a
cross-band repeater.  Either that, or they swapped the object or
frequency in their definitions.

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

On 5/7/2012 2:45 PM, Steve Daniels wrote:
> 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
>
>
> _______________________________________________
> 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