On 06-Feb-20 11:45, Dan Smith via chirp_devel wrote:
If you don't min exploring the bandplan usage instead of hard-coding things in as you have them here, that'd be cool. If it's not feasible or easy for some reason, let me know.
I did some research. There are a number of things to consider.
1) Chirp band plans are nice, but incomplete. There's no complete IARU Region 1 band plan yet (compared to Region 2, where we have bandplan_na.py extending it to Region 2 VHF/UHF/SHF). I would have to write a bandplan_eu.py. I might still do that eventually, when I'm too terribly bored.
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).
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.
73 Bernhard