[aprssig] FREQ Object radio issues (b)

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Tue May 8 13:36:49 EDT 2012


Please DON'T!

Remember how many time's you've gone looking for an extra bit here or 
there.  There's a distinction between t and T, so why not a distinction 
between OFF and off and k/m vs K/M?

If there's case sensitivity on the first letters, and on MHz (and 
probably rx), then there should be case sensitivity throughout the 
specification for consistency, IMHO.  It's a SPECIFICATION, not a HACK.

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

On 5/8/2012 1:32 PM, Bob Bruninga wrote:
>
> The intent was to key on the case of the first letter.  I can clarify 
> that in the spec.
>
> Bob
>
> *From:*aprssig-bounces at tapr.org [mailto:aprssig-bounces at tapr.org] *On 
> Behalf Of *Lynn W. Deffenbaugh (Mr)
> *Sent:* Tuesday, May 08, 2012 1:22 PM
> *To:* Ron Stordahl, AE5E; TAPR APRS Mailing List
> *Subject:* Re: [aprssig] FREQ Object radio issues (b)
>
> Spec says "Toff", not "TOFF", for a wide repeater (toff would be 
> narrow).  Yes, the devil is in the details.
>
> And the jury is still out as to whether or not Yaeus's APRS radios are 
> able to tune to frequency objects without the frequency in the 
> comments, so if you set these up, have a Yaesu owner give them a QSY 
> test (note that it is also my understanding that the FTM-350 must be 
> in VFO mode for the QSY/Tune function to work).
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> PS. Thanks for posting these because I wasn't flagging the OFF as 
> non-compliant in APRSISCE/32.  It will in the next development release.
>
> On 5/8/2012 1:00 PM, Ron Stordahl, AE5E wrote:
>
> I started all this ruckus on April 26 when I raised the issue of 
> proper format to set up a D710A one button QSY.
>
> Based upon all the discussion I am returning to essentially my 
> original proposal to send:
>
> ;146.85TRF*111111z4804.29N/09606.79WrTOFF -060 R30m
>
> ;444.80TRF*111111z4807.60N/09610.63WrT156 +500 R15m
>
> Correct me if I am wrong but I believe this complies with the 
> specification.  I realize including the offset on VHF is not 
> necessary, but it gives me some satisfaction from the point of 
> consistency to do so and makes it more understandable to the human 
> reader.  Additionally one of our VHF repeaters on 147.00 has a non 
> standard -600KHz shift when the standard is +600KHz, thus at least for 
> that one -060 is required.
>
> I have just completed setting up these objects for 12 area repeaters, 
> scattered over about 125 miles in NorthWestern Minnesota served by 8 
> APRS digipeaters.  Thankfully they are remotely programmable and can 
> be reached from my central location directly or by up to 2 hops.  When 
> remote programming is no longer possible, when these MFJ1270C's 
> UIDIGI-ROM's die, I am finished as well!
>
> Ron, AE5E
>
>     ------------------------------------------------------------------------
>
>     *From:*Bob Bruninga <bruninga at usna.edu> <mailto:bruninga at usna.edu>
>     *To:* 'TAPR APRS Mailing List' <aprssig at tapr.org>
>     <mailto:aprssig at tapr.org>
>     *Sent:* Tuesday, May 8, 2012 10:54 AM
>     *Subject:* [aprssig] FREQ Object radio issues (b)
>
>
>     Here are some more notes I have found on some known problems:
>
>     Use of the "xyz" in the OBJECT NAME:
>
>     > FFF.FF0xy object is OK and QSY is OK
>     > FFF.FF5xy object is OK and QSY is OK
>     > FFF.FFxyz object will not QSY in early D710 models.  Now fixed.
>
>     > FFF.FFxyz objects of any format will not QSY the FTM-350 (confirm?)
>
>     Extra "0" on end of the +xxx or -xxx OFFSET format.  The THD72
>     will accept
>     extra characters after the required +xxx or -xxx.  These will all
>     give the
>     proper offset:
>
>     > 440.000MHz tOFF +500 Bob's radio
>     > 440.000MHz tOFF +5000 Bob's radio
>     > 440.000MHz tOFF +5000Bob's radio
>     > 440.000MHz tOFF +5000000 Bob's radio
>     > 440.000MHz tOFF +500Bob's radio
>
>     BUT SHOULD N OT BE USED until confirmed all existing radios can
>     tolerate it.
>     This was a proposed backwards-compatible future fix to making the
>     offset
>     more human readable, because then we could recommend the use of +5000
>     instead of the +500.  But this CANNOT BE USED until we have
>     surveyed all
>     radios to see if ALL radios can properly set the offset if the
>     additional
>     "0" is included.  Or all radios are upgraded to do so
>
>     Here are some other known issues for the Compatibility table of
>     position
>     Comments:
>
>     Leading space:  (required, required-not, don't care) - (Y, N, X)
>
>     Xmits space:    (Transmits leading space) - (Y, N)
>
>     Requires "MHz":  (Requires mixed case, allows any case)    - (Y, N)
>
>     Requires "MHz_": (Requires trailing space) - (Y, N)
>
>     Xmits MHz_:      (Transmits trailing space) - (Y, N)
>
>     Responds to +xxx and -xxx offsets - (Y, N)
>
>     Transmits offsets +xxx and -xxx  - (Y, N)
>
>     Allows extra trailing zero so that +600 works, where only +60 is
>     IAW spec -
>     (Y, N)
>
>
>
>     _______________________________________________
>     aprssig mailing list
>     aprssig at tapr.org <mailto:aprssig at tapr.org>
>     https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
>
>
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org  <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20120508/7467cf1e/attachment.html>


More information about the aprssig mailing list