[aprssig] APRS Local Info Initative TM-D710A compatibitility

[Ron Stordahl, AE5E]

The APRS Local Info Initiative provides a format for local voice repeater objects, but fails to disclose the option to also include the repeater offset information.

This information when received by a TM-D710A offers a one button QSY feature to set the B side to the local voice repeater setting the tone and offset automatically.


In the case of the TM-D710A for VHF repeaters the offset is programmed to be "standard" based upon the frequency (-600 KHz in one range, +600 KHz in another), but for UHF the radio apparently provides no capability to define the standard shift (at least I can't find it!).

During a recent trip I found only a handful of digipeaters sending this object in the proper format, typically it was not sent at all, which is a shame as it is very convenient when properly transmitted.  Perhaps with time more sysops will take note and implement it.

I am not sure if any radio other than the TM-D710A can actually process this, but hopefully that will improve with time.

Here are two examples of what I send locally:

;146.85TRF*111111z4804.29N/09606.79WrToff -060 R45m
;444.80TRF*111111z4807.60N/09610.63WrT156 +500 R15m

The first is an object for our local VHF repeater.  Note: 'Toff -060 '.  The element 'Toff'' is interpreted as 'no tone', although the element is defined as T followed by the tone in Hertz (3 digits).  Perhaps T000, which would meet that definition may work, however I know that Toff does work.

The second element, -060 (the trailing space is required). is the repeater offset in units of 10 KHz.  This element is not defined in the document but is processed by the TM-D710A.  NOTE:  This must be in the format of either a + or a - followed by three decimal digits!  The format -60 is not correctly interpreted by the D710A, you must have it as -060 or +060. Also as a test I tried +050 and got a shift of +600 KHz rather than +500 KHz! Fortunately -060 and +060 work which will cover nearly 100% of the cases.

The second object is for our local UHF repeater.  Note that it has a tone of 156.7 and an offset of +5 MHz (which is represented as +500 in units of 10 KHz).

In my travels I did not find a single UHF repeater object which included the shift with the result that when doing the 'one button qsy' to the repeater the offset would be zero, requiring additional steps to set the shift while staying out of the ditch.

While it is true that the offset need not be provided on VHF as the standard shifts are programmed into the D710A, I am locally including it in the various digipeaters I manage as part of my effort to use a single format for both VHF and UHF.

What I recommend as a minimum would be for all sysops who are transmitting this information to at least include it for their UHF repeaters, using +500 to set an offset of +5MHz.

I would also like to see the offset information published in the APRS Local Info Initiative document so after this post is long forgotten there is a place to find the format for the offset.

While I am at it I want to mention the inappropriate repetition rates and paths I have seen used for repeater objects.  The purpose of such objects is not to broadcast this information far and wide, but rather to provide a service to the mobile ham, to give him local frequency information to a repeater that he would be in range of when the object is received.  As such it does have to be sent frequently, perhaps every 10 minutes, but the path should be such that it does not end up on the APRS-IS network nor digipeated far far away.  You can keep it off of APRS-IS by terminating the path with the string ',NOGATE'.  IGates which are working correctly will not send such a packet to the internet.  The path itself should be short, perhaps only NOGATE so that no area digipeater will repeat it.  An exception would be when the object is originated by a very short range digi and does need the 'local' high digi to extend it to a mobile in range of said voice
 repeater.  But going beyond this is unnecessary QRM and 'Vanity'.

UIView32 systems will not be able to transmit such objects, it was not included in the software when development ceased.  I am instead using BPQ32 which allows for a virtually unlimited number of objects each with it's own path and repetition rate.   I guess that is a topic for another posting.....

Ron Stordahl, AE5E
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120426/78efa531/attachment.html>