[aprssig] Yaesu FREQ OBJECT workaround

[Bob Bruninga]

> What's wrong with:
>
> Object name FFF.FFFxy or FFF.FFxyz as it is now, 
> but with a COMMENT that says:

> FFF.FFFMHz Tnnn +ooo Rnnm PHG and comment can go here?  
> And isn't PHG kind of redundant with an explicit range anyway?

No, because PHGxxxx can only be in the first 7 bytes.  It cannot be anywhere
else in the packet (even though UIview against my strong objections will
accept it anywhere in violation of the spec).  So that is why we had to add
the Rxxm for humans to see the expected range of the repeater...

> And what's with the FFF.FF MHz?  Why not just put the 
> blooming ZERO in there and keep it a SINGLE frequency spec?

Human readability and consistency with the FFF.FFxyz format for the
FREQ-OBJs. It is trivial code, but improves readability and consistancy..

> Does the Kenwood line (or ANYTHING for that matter) actually 
> DO the split frequency object specification (FFF.FFFxy object 
> with an FFF.FFFMHz at the start) which would be the ONLY reason 
> I can see for not doing what I show above?

Agree, that is a possibility.  But until we know that every radio can tune
it (meaning it not only recognizes the FFF.FFxyz in the OBJECT NAME, but
also then uses the other freq for INPUT, then we cant.  My fear is that the
FREQ-NAME will trump the other in the kenwoods, and then we are back to the
"assumed standard offset".  That then would only work if Kenwood "astonished
us" by ignoring the FFF.FFFMHz but still honored the following oXXX.  Which
as you can see would violate the least astonishment principle.

And if we don't allow people to force an oXXX offset, we are back to square
one with respect to all the emotions of the last week.

Bob, Wb4APR

On 5/9/2012 10:55 AM, Bob Bruninga wrote:
> The workaround for the FTM-350 not properly parsing the QSY in an APRS
FREQ
> OBJECT is suggested as follows:
>
> 1) Continune FREQ OBJECTS as before with Tnnn oXXX Rxxm... in the object
> text. (if oXXX is omitted, then radios will use standard offsets).
>
> 2) For the FTM-350, also include the FFF.FFFMHz in the DIGIPEATERS beacon
> text after the PHG data.  For example for WB4APR-1 digipeater, I might
use:
>
> PHG1234/147.105MHz T107 +060 R20m AARC
> PHG1234/146.76 MHz T156 -060 R34m BRATS
>
> OPEN ISSUE:  Does the FTM-350 properly decode the FREQUENCY when the "/"
> separator is used after the PHG data???  Do the Kenwoods?  If not, do they
> work with a SPACE separator?  If not, then we have to run them together.
>
> This should work fine as a workaround since the FTM-350 has a wider
display
> and even if the DIGIPEATER CALLSIGN is used, the radio will still display
> the FREQ on the front panel too.
>
> The only thing we lose in the original DIGI text was "W2, SSn-N " which by
> now, everyone should understand to limit their hops to 2 or less
>
> Bob, WB4aPR
>
>
> _______________________________________________
> 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