[aprssig] Help with repeater beacon

[Guido Trentalancia]

Hello John !

On Wed, 16/02/2011 at 20.33 -0500, John Gorkos wrote:
> Bob-
>   This seems broken in the Kenwood implementation.  Basically, I'll have to 
> double my transmit rate to get the appropriate information out there.  
> Actually, I don't see any way to actually make this work unless I change my 
> beacon callsign to "147.15NGA" and send a position packet that looks like 
> this:
> 147.15NGA>BEACON,WIDE2-1:111111z3414.21N/08409.60Wr147.150MHz T143 R60m 
> NET2000TU Cumming,GA de AB0OO

This is good, because the frequency is in the format FFF.FFFMHz, it
appears exactly at the beginning of the comment/status field and the
tone information follows it immediately. That's it.

All the rest is optional: it does not necessarily need to be from
callsign 147.15NGA, it does not necessarily need to bring the NETxxxxxx
field (that's a Frequency Object thing and won't be understood), it does
not need to bring a timestamp nor a position. The position however is
desirable.

The two functions "APRS Frequency Formats" (also known as AFRS) and
"Frequency Objects" are not part of the APRS Protocol Specification, so
it's somewhat opinable to say that the Kenwood implementation is broken.

They have just implemented some extra functionality and they have called
"QSY Function". From their documentation
(TM-D710_In-Depth-Manual_APRS_EchoLink.pdf ver 1.01 May 2008 at
paragraph 6.1.6), it appears that what they have implemented is in line
with what is specified in "APRS Frequency Formats" (which again is not
part of the protocol specification but it's more like a recommendation
for "future radio compatibility").

And you are not doubling your transmission rate because substantially
the only difference is ten bytes (the FFF.FFFMHz).

So, only if you need to both create a digipeater object (which provides
certain other fields such as NETxxxxxx) and provide "tunable beacons",
then it could be argued that there is some redundancy. But we are
talking about a bunch of bytes and perhaps, if you are so worried about
that, then the object can be transmitted less often (beacon - beacon -
object - beacon - beacon - object - ...) because you made it permanent
(111111z).

Good luck !

73,

Guido IZ6RDB

> Am I misunderstanding this?  It's highly likely...
> 
> On Wednesday, February 16, 2011 20:16:09 Guido Trentalancia wrote:
> > Hello John !
> > 
> > On Wed, 16/02/2011 at 17.37 -0500, John Gorkos wrote:
> > > We're having some problems with the "TUNE" function of D710s and D72s in
> > > the Atl area.
> > > 
> > > I'm beaconing the following text from my Tx/Igate:
> > > ;147.15NGA*111111z3414.21N/08409.60WrT143 R60m NET2000TU Cumming,GA
> > > which seems to match, per character, what's on the localinfo.html page:
> > > ;FFF.FFxyz*111111zDDMM.hhN/DDDMM.hhWrTnnn RXXm NETxxxxxx MTGxxxxx
> > > .........
> > 
> > Appears consistent with the specification for Frequency Objects.
> > 
> > The best specification, you can find it here:
> > 
> > http://webster-new.dmz.usna.edu/Users/aero/bruninga/aprs/freqspec.txt
> > 
> > > We can see the objects show up correctly in the station list of the 710s
> > > and 72s, but no amount of pushing the "tune" button does the trick. 
> > > Meanwhile, tune DOES work for stations that include their freq in their
> > > status text:
> > > KD4UYP-9>S3UV8R,WIDE1-1*,WIDE2-1,qAR,AB0OO-1:`oQhn*uk/]"72}147.075MHz=
> > 
> > Yes, this is consistent with what is implemented in the Kenwood TM-D710.
> > 
> > They have implemented what they call "QSY Function". And that works with
> > frequency information embedded in "the first 10 bytes of the existing
> > free-field position comment text or STATUS field".
> > 
> > So, if you want to tune, you have to send out beacons that report the
> > frequency as specified in the document mentioned above according to the
> > paragraph "APRS Frequency Formats" and not the paragraph "Frequency
> > Objects".
> > 
> > As a start, you can try:
> > >147.15 MHz T143 R60m And here you can write that it's in Cumming,GA
> > 
> > but that won't create an object for you. So it's two different features,
> > but you can use both of them if needed.
> > 
> > 73,
> > 
> > Guido IZ6RDB
>