[chirp_devel] [PATCH 3 of 8] [ft4] Automatic duplex value selection not working. Fixes #7605

[Dan Smith]

> 2) I loaned an FT-65R from a friend (incidentally, the same one Dan 
> Clemmensen used for his initial work on the ft4.py driver :-) and 
> checked what the feature does when I scroll through the bands using VFO. 
> This is the result:
> 
>     145.100 - 145.495 neg
>     146.000 - 146.395 pos
>     146.600 - 146.995 neg
>     147.000 - 147.395 pos
>     147.600 - 147.995 neg
> 
>     (There is no auto on 70 CM.)
> 
> This doesn't match with Chirp's North America band plan. It doesn't 
> match anything in the European band plan either (the one which might 
> have to be created in Chirp).

Yeah, I know my Yaesu radios don't select duplex consistently with my other brands (which seem to do it based on the NA plan, although I haven't exhaustively checked). So, I guess this doesn't surprise me in retrospect.

> Therefore, I'm afraid that we might have to go with a radio specific 
> table. Or we make a Chirp Common table (separate from band plans) from 
> which we could load the ranges for "auto". In that case, it would help 
> to know how other radios set these values. However, I guess only Yaesu 
> had this strange idea to save the duplex value as "auto". Insofar, I 
> think it would be acceptable to keep it in ft4.py.
> 
> What do you think? If you agree, then I will modify my patch to reflect 
> the table above and resend it.

Well, what I think (about Yaesu's "feature") is probably not appropriate for polite company :P

It's weird that there's no auto mode on UHF, at least for that radio, but I guess it limits the amount of hard-coding necessary. So yeah, I guess if you know _exactly_ what the radio does then encoding it in the driver makes (the most) sense. It won't match for all the other drivers we have in tree (which AFAIK, pretend this problem isn't a problem) but it's not really worse than if we do nothing.

--Dan