[chirp_devel] [PATCH 1 of 8] [ft4] Sometimes channel names are not displayed correctly. Fixes: #7601
# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580879326 28800 # Tue Feb 04 21:08:46 2020 -0800 # Node ID 427edcaeed8ddbffc1fa17fe1c8af32c4f277899 # Parent 845362c4e800e71e2dc45bade6feefbd9ff96fb5 [ft4] Sometimes channel names are not displayed correctly. Fixes: #7601 When user programmed radio manually and added a name shorter than 8 characters, the remaining characters were filled with garbage on the Chirp UI. This was due to padding with 0x7F used by the Yaesu; the solution is to pad with 0x20 (space characters) instead.
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -1063,6 +1063,8 @@ y = obj[x] if y == 0: break + if y == 0x7F: # when programmed from VFO + y = 0x20 name += chr(y) return name.rstrip()
# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580884634 28800 # Tue Feb 04 22:37:14 2020 -0800 # Node ID 5bb4c48c5231a760c0bc62b01274901fb0804333 # Parent 427edcaeed8ddbffc1fa17fe1c8af32c4f277899 [ft4] After CSV import, channels were always low power. Fixes #7603 After a CSV file was imported, all imported channels were displayed and uploaded with low power. This patch ensures the recommended high power setting will now be used.
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -476,9 +476,10 @@
SKIPS = ["", "S"]
-POWER_LEVELS = [chirp_common.PowerLevel("Low", watts=0.5), - chirp_common.PowerLevel("Mid", watts=2.5), - chirp_common.PowerLevel("High", watts=5.0)] +POWER_LEVELS = [ + chirp_common.PowerLevel("High", watts=5.0), # high must be first (0) + chirp_common.PowerLevel("Mid", watts=2.5), + chirp_common.PowerLevel("Low", watts=0.5)]
# these steps encode to 0-9 on all radios, but encoding #2 is disallowed # on the US versions (FT-4XR) @@ -1142,7 +1143,9 @@ _mem.freq = txfreq self.encode_sql(mem, _mem) if mem.power: - _mem.tx_pwr = POWER_LEVELS.index(mem.power) + _mem.tx_pwr = 2 - POWER_LEVELS.index(mem.power) + else: + _mem.tx_pwr = 0 # set to "High" if CHIRP canonical value is None _mem.tx_width = mem.mode == "NFM" _mem.step = STEP_CODE.index(mem.tuning_step)
# 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 When user programs radio manually and doesn't explicitly select positive or negative offset, then the radio's automatic pre-selection is being saved to the radio's memory. The driver was able to read that, but didn't know what to do with it. Some code to determine the correct value for "duplex" (0 for +, or 2 for -, not 5 for auto) has now been added. This will work for 2m only; for 70cm, the rules in the band plans (at least the ones offered by ARRL) are not specific enough. (The FT-4 / FT-65 might still use auto on 70cm; if observed, please contact me.). Mentioned in #6677.
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -470,9 +470,10 @@ # we can re-arrange the order, and we don't need to have all # the values, but we cannot add our own values here. DUPLEX = ["+", "", "-", "", "off", "", "split"] # (0,2,4,5)= (+,-,0, auto) -# the radio implements duplex "auto" as 5. we map to "" It appears to be -# a convienience function in the radio that affects the offset, but I do not -# understand it. +# the radio implements duplex "auto" as 5. We map to "". It is +# a convenience function in the radio that affects the offset, which +# sets the duplex value according to the frequency in use. Ham band plans +# prescribe + or - depending on the location in the spectrum.
SKIPS = ["", "S"]
@@ -1069,6 +1070,20 @@ name += chr(y) return name.rstrip()
+ 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 + mem = chirp_common.Memory() _mem, ndx, num, regtype, sname = self.slotloc(memref) mem.number = num @@ -1108,7 +1123,10 @@ mem.offset = txfreq else: mem.offset = int(_mem.offset) * self.freq_offset_scale - mem.duplex = DUPLEX[_mem.duplex] + if _mem.duplex == 5: # auto offset + mem.duplex = DUPLEX[get_duplex(mem.freq)] + else: + mem.duplex = DUPLEX[_mem.duplex] self.decode_sql(mem, _mem) mem.power = POWER_LEVELS[2 - _mem.tx_pwr] mem.mode = ["FM", "NFM"][_mem.tx_width]
# 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 duplexreturn_value = 4 # off# 2M frequencies (according to ARRL)if freq in range(145200000, 145500000):return_value = 2 # negativeif freq in range(146610000, 146970000):return_value = 2 # negativeif 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
On 06-Feb-20 07:59, Dan Smith via chirp_devel wrote:
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.
I noticed there was one missing :-)
So, first off, we have the chirp/bandplan* modules, which might be better to leverage if you're going to do this.
Ah, ok. I'm still finding my way through all the things Chirp provides. I'll look into it.
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?
I tend to say "no", and my reasoning for this statement is this:
"Auto" is a convenience default the radio offers when you use VFO. It kicks in when you scroll through frequencies which are reserved for repeater use: by default, it automatically picks positive or negative offset so that the user doesn't have to set it. It's unfortunate that it saves the duplex setting as "auto" when you add it to a memory channel, and not as the value it actually picks for it ("+" or "-"). The user can always override the default by selecting a different value than the one picked by "auto". BTW, the radio does show "+" or "-", not "auto", on its display.Even worse, this changes by region; it's different between US and EU models (and my patch doesn't do this correctly yet: it uses USA defaults, and I need to make it region dependent).
I think it creates less headache for the user if we apply the exact same "guessing" the radio does, and convert "auto" (5) to "+" (0) or "-" (2).
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.
Exactly my point. "Auto" is not really any useful value.
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).
Although I'm totally agreeing with you about the level of excitement, I think it's probably still the path to least grief. I trust in Yaesu not changing things all the time, i.e. that the automatic picks don't change either.
I'm open to alternatives, and I will leave the final decision to you.
73, Bernhard
"Auto" is a convenience default the radio offers when you use VFO. It kicks in when you scroll through frequencies which are reserved for repeater use: by default, it automatically picks positive or negative offset so that the user doesn't have to set it. It's unfortunate that it saves the duplex setting as "auto" when you add it to a memory channel, and not as the value it actually picks for it ("+" or "-"). The user can always override the default by selecting a different value than the one picked by "auto". BTW, the radio does show "+" or "-", not "auto", on its display. Even worse, this changes by region; it's different between US and EU models (and my patch doesn't do this correctly yet: it uses USA defaults, and I need to make it region dependent).
Yeah, most radios have auto duplex selection. The storing it as auto in the memory channel is the braindead behavior I think.
I'm open to alternatives, and I will leave the final decision to you.
Sending that email mostly crystalized my view that we should _not_ add an auto duplex type to chirp, but glad to have the sanity check. 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.
--Dan
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.
Just had a quick look. Seems to be an easy enough thing to explore. I think I can come up with something within the next few days.
73 Bernhard
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
- 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
# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580967044 28800 # Wed Feb 05 21:30:44 2020 -0800 # Node ID 7ccd6ff8b37061c110d92b016593c42c0ff2e2c4 # Parent 9fdd2b612c6e82eb01e9a776130486273ca09ea1 [ft4] Open allowed frequencies to radio supported receive ranges. Fixes #6651 The FT-4 driver restricted allowed frequencies to what the radios allowed for transmit. This patch opens allowed ranges to what the radios offer for receiving. Also mentioned in #6869.
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -572,38 +572,16 @@ FT65_PROGS = ("prog", ["P1", "P2", "P3", "P4"]) SPECIALS_FT65[-1] = FT65_PROGS # replace the last entry (P key names)
-# I wonder whether we should simply open the bands to what the radios allow -# for RX? The radios do take care of allowing or prohibiting TX on their own. -# In that case, the ASIA settings can be used for any region model. -# To be discussed with Dan Clemmensen. [AE6YN]
-VALID_BANDS_US_DUAL = [ +VALID_BANDS_DUAL = [ (65000000, 108000000), # broadcast FM, receive only - (144000000, 148000000), # VHF, US version, TX and RX - (430000000, 450000000) # UHF, US version, TX and RX - ] -VALID_BANDS_EU_DUAL = [ - (65000000, 108000000), # broadcast FM, receive only - (144000000, 146000000), # VHF, EU version, TX and RX - (430000000, 440000000) # UHF, EU version, TX and RX - ] -VALID_BANDS_ASIA_DUAL = [ - (65000000, 108000000), # broadcast FM, receive only - (136000000, 174000000), # VHF, Asia version, TX and RX - (400000000, 480000000) # UHF, Asia version, TX and RX + (136000000, 174000000), # VHF + (400000000, 480000000) # UHF ]
-VALID_BANDS_US_VHF = [ - (65000000, 108000000), # broadcast FM, receive only - (144000000, 148000000), # VHF, US version, TX and RX - ] -VALID_BANDS_EU_VHF = [ +VALID_BANDS_VHF = [ (65000000, 108000000), # broadcast FM, receive only - (144000000, 146000000), # VHF, EU version, TX and RX - ] -VALID_BANDS_ASIA_VHF = [ - (65000000, 108000000), # broadcast FM, receive only - (136000000, 174000000), # VHF, Asia version, TX and RX + (136000000, 174000000), # VHF ]
# bands for the five VFO and three home channel memories @@ -1249,7 +1227,7 @@ """ MODEL = "FT-4XR" id_str = b'IFT-35R\x00\x00V100\x00\x00' - valid_bands = VALID_BANDS_US_DUAL + valid_bands = VALID_BANDS_DUAL legal_steps = US_LEGAL_STEPS BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_DUALBAND
@@ -1261,6 +1239,6 @@ """ MODEL = "FT-65R" id_str = b'IH-420\x00\x00\x00V100\x00\x00' - valid_bands = VALID_BANDS_US_DUAL + valid_bands = VALID_BANDS_DUAL legal_steps = US_LEGAL_STEPS BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_DUALBAND
# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580967752 28800 # Wed Feb 05 21:42:32 2020 -0800 # Node ID 898fe63f06ffcea13a820754e56701ed124527f2 # Parent 7ccd6ff8b37061c110d92b016593c42c0ff2e2c4 [ft4] Add Yaesu FT-4XE. Fixes: #7189 This patch adds support for the Yaesu FT-4XE to Chirp. It offers an additional tune step of 6.25 kHz.
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -1233,6 +1233,17 @@
@directory.register +class YaesuFT4XERadio(YaesuFT4GenericRadio): + """ + FT-4X dual band, EU version + """ + MODEL = "FT-4XE" + id_str = b'IFT-35R\x00\x00V100\x00\x00' + valid_bands = VALID_BANDS_DUAL + legal_steps = STEP_CODE + BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_DUALBAND + +@directory.register class YaesuFT65RRadio(YaesuFT65GenericRadio): """ FT-65 dual band, US version
# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580969349 28800 # Wed Feb 05 22:09:09 2020 -0800 # Node ID 279f115be93e62202c1b224b9388fb1a1479a57d # Parent 898fe63f06ffcea13a820754e56701ed124527f2 [ft4] Add Yaesu FT-65E. Fixes: #6619 This patch adds support for the Yaesu FT-65E to Chirp. It offers an additional tune step of 6.25 kHz.
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -1243,6 +1243,7 @@ legal_steps = STEP_CODE BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_DUALBAND
+ @directory.register class YaesuFT65RRadio(YaesuFT65GenericRadio): """ @@ -1253,3 +1254,15 @@ valid_bands = VALID_BANDS_DUAL legal_steps = US_LEGAL_STEPS BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_DUALBAND + + +@directory.register +class YaesuFT65ERadio(YaesuFT65GenericRadio): + """ + FT-65 dual band, EU version + """ + MODEL = "FT-65E" + id_str = b'IH-420\x00\x00\x00V100\x00\x00' + valid_bands = VALID_BANDS_DUAL + legal_steps = STEP_CODE + BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_DUALBAND
# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580969883 28800 # Wed Feb 05 22:18:03 2020 -0800 # Node ID 28a0f90d2753ce206bc726bed471aade1709c28a # Parent 279f115be93e62202c1b224b9388fb1a1479a57d [ft4] Add Yaesu FT-4VR (and infrastructure for Yaesu FT-4VE). Fixes: #7387 This patch adds support for the Yaesu FT-4V to Chirp. The European version is commented out; we can activate as soon as we obtain an image (it can be downloaded using FT-25R as selected radio).
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -1245,6 +1245,31 @@
@directory.register +class YaesuFT4VRRadio(YaesuFT4GenericRadio): + """ + FT-4V VHF, US version + """ + MODEL = "FT-4VR" + id_str = b'IFT-15R\x00\x00V100\x00\x00' + valid_bands = VALID_BANDS_VHF + legal_steps = US_LEGAL_STEPS + BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_MONO_VHF + + +# No image available yet +# @directory.register +# class YaesuFT4VERadio(YaesuFT4GenericRadio): +# """ +# FT-4V VHF, EU version +# """ +# MODEL = "FT-4VE" +# id_str = b'IFT-15R\x00\x00V100\x00\x00' +# valid_bands = VALID_BANDS_VHF +# legal_steps = STEP_CODE +# BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_MONO_VHF + + +@directory.register class YaesuFT65RRadio(YaesuFT65GenericRadio): """ FT-65 dual band, US version
# HG changeset patch # User Bernhard Hailer ham73tux@gmail.com # Date 1580970116 28800 # Wed Feb 05 22:21:56 2020 -0800 # Node ID a3b9b5fee0d84083bcb5f8b7b4fdf7871836047a # Parent 28a0f90d2753ce206bc726bed471aade1709c28a [ft4] Add Yaesu FT-25R (and infrastructure for Yaesu FT-25E). Fixes: #7543 This patch adds support for the Yaesu FT-25 to Chirp. The European version is commented out; we can activate as soon as we obtain an image (it can be downloaded using FT-25R as selected radio).
diff --git a/chirp/drivers/ft4.py b/chirp/drivers/ft4.py --- a/chirp/drivers/ft4.py +++ b/chirp/drivers/ft4.py @@ -1291,3 +1291,27 @@ valid_bands = VALID_BANDS_DUAL legal_steps = STEP_CODE BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_DUALBAND + + +@directory.register +class YaesuFT25RRadio(YaesuFT65GenericRadio): + """ + FT-25 VHF, US version + """ + MODEL = "FT-25R" + id_str = b'IFT-25R\x00\x00V100\x00\x00' + valid_bands = VALID_BANDS_VHF + legal_steps = US_LEGAL_STEPS + BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_MONO_VHF + + +# No image available yet +# @directory.register +# class YaesuFT25ERadio(YaesuFT65GenericRadio): +# """ +# FT-25 VHF, EU version +# """ +# MODEL = "FT-25E" +# id_str = b'IFT-25R\x00\x00V100\x00\x00' +# valid_bands = # legal_steps = US_LEGAL_STEPS +# BAND_ASSIGNMENTS = BAND_ASSIGNMENTS_MONO_VHF
participants (2)
-
Bernhard Hailer -
Dan Smith