# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580962623 28800 # Wed Feb 05 20:17:03 2020 -0800 # Node ID 9fdd2b612c6e82eb01e9a776130486273ca09ea1 # Parent 5bb4c48c5231a760c0bc62b01274901fb0804333 [ft4] Automatic duplex value selection not working. Fixes #7605
FYI, I didn't apply this patch yet because all the others applied cleanly without it and I thought it might be worth some discussion.
def get_duplex(freq): # auto duplex to real duplex
return_value = 4 # off
# 2M frequencies (according to ARRL)
if freq in range(145200000, 145500000):
return_value = 2 # negative
if freq in range(146610000, 146970000):
return_value = 2 # negative
if freq in range(147600000, 147990000):
return_value = 0 # positive
# ARRL band plan for 70cm does define repeater
# frequency ranges, but it allows local entities
# to make them input or output channels.
return return_value
So, first off, we have the chirp/bandplan* modules, which might be better to leverage if you're going to do this. However, I also wonder if we should add "auto" to the list of duplexes? I know other Yaesu models support this, and while I'm totally unsure what the point of this "feature" is in the radio (given that the channel is what it is and the radio isn't going to pick a different duplex ever), I wonder if it would be less confusing to just add support for it?
The problem comes in when you go to import or copy a memory from this radio to another radio that doesn't support auto duplex. We would need to calculate/guess the duplex at that point, like you are doing that here, which while more general, doesn't excite me (at all). It also means that we can't show you in the UI what the radio is actually going to do when you transmit, unless each driver that supports auto duplex is carefully tested throughout the entire range and all that information is expressed upwards.
I guess the question is: for people that own these radios, what is the best behavior? Would you rather an internal conversion/guess to represent everything as fixed duplex, or try to expose the ambiguity up the stack?
--Dan