[aprssig] Yaesu FREQ OBJECT workaround

Lynn W. Deffenbaugh (Mr) ldeffenb at homeside.to
Wed May 9 13:45:24 EDT 2012


Ok, I took a bit of my own advice and went back to aprs101.pdf.  It does 
state plainly that the PHG must follow the position/symbol component of 
a packet and that arbitrary comment(s) come after that.  I get it now.

Can I ask why support the blank in FFF.FF MHz when a zero would go 
nicely?  I can understand the abbreviated, implied zero when specifying 
frequency in the object name (makes room for one additional uniqueness 
character), but why not just have one frequency spec in the comment?

And can  you provide an example of a dual-band repeater or one with a 
non-expressible offset?  Both as a frequency object AND as a 
callsign-named repeater station or object?

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

On 5/9/2012 1:27 PM, Lynn W. Deffenbaugh (Mr) wrote:
> WHY?  Why yet ANOTHER extension of ANOTHER packet when there's already 
> a specification that's almost good enough?
>
> 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?
>
> And what's with the FFF.FF MHz?  Why not just put the blooming ZERO in 
> there and keep it a SINGLE frequency spec?
>
> 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?
>
> Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
>
> 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
>





More information about the aprssig mailing list