[aprssig] FREQ Object Formats

[Andre]

On Tue, 08 May 2012 00:48:33 +0200, Bob Bruninga <bruninga at usna.edu> wrote:

>
>> But there never can be standards build into the radio for
>> 70cm and 23cm because those standards don't exist.
>
> They do exist in the USA.  So where they exist, then I think they should  
> be
> used.  They do it for VHF in the USA, so why not for UHF.
>
Because VHF does not have subregional planning like UHF has, maybe the USA  
has a standard but what about other countries that use type A radios, it's  
better to be safe then have people transmit on wrong frequenties because  
of incorrect default settings.

>> So you can push for kenwood and yeasu including some arbiturary
>> standard offsets and tell sysops to transmit only a + or -
>
> Just hold on.  NOWHERE is simply sending + or - a part of the FREQ spec.
> Any packets that include that are not in accordance with the spec.
>
even worse push for no offset information in repeater sections.

>> but if yeasu picks +/-1.6 and kenwood picks +1.6/-7.6 then it still
>> won't work resulting in sysops going back to always include offset
>> frequentie or use the double frequentie objects.
>
> Neither of those are part of the APRS FREQ SPEC.  Only +xxx or -xxx are  
> part
> of the APRS spec where xxx is in 10's of KHz.
I was not talking about specs but default offsets in radios, those have  
been expressed in mhz for ages.
> The standard offset is used
> IF AND ONLY IF, there is NO OFFSET data in the correct format in the  
> packet.
>
it keeps getting worse, no offset information defaulting to using build in  
defaults will, not can but will, result in one person or radio asuming  
simplex and another asuming an offset that the manufactorer thinks should  
be used. simplex frequenties in repeater segements like parrots would have  
to send +000 and that could be asumed as an error and handled as default  
setting again.
Just transmitting the offset when an offset is used and no offset when  
simplex is used is clear and easy to understand by both machine and human


-- 
73 Andre PE1RDW