[chirp_devel] New driver for FT-4 and FT-65 #4787
I cannot figure out how to submit an entirely new driver, so Its here as an attachment, along with the .img file. This driver runs and passes the pep and tox tests on both Python 2 and Python 3. I am of course clueless about any python 2 and Python3 subtleties . There is no radio version and/or ID testing: I don't know how and I only have one radio. There is no frequency enforcement for the VFO and Home channels. There is no frequency validation for low<high for the PMS channels The FT-65 is assumed to be (almost) identical to the FT-4. The FT-65 has 4 programmable keys instead of 2 (I coded for these) and some settings I did not code for. I will get to those when I have more access to a FT-65 My UI for the programmable keys is is horrible. The code in not as Pythonic as it should be. I'm basically a C programmer.
Hi Dan,
I cannot figure out how to submit an entirely new driver, so Its here as an attachment, along with the .img file.
It's pretty much the same as any other change. What are you struggling with? I just added a few lines to the developer process page about adding a new file in case it is not obvious:
https://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Soft-commi...
I would definitely prefer to integrate this as a patch if possible.
This driver runs and passes the pep and tox tests on both Python 2 and Python 3. I am of course clueless about any python 2 and Python3 subtleties
Actually, it fails one test, BUT you didn't notice because I just realized the test adapter for unittest is broken in a subtle way. I just happened to run tests on your file manually since it wasn't in patch format and noticed that it failed that way but didn't with the automation. I will work on getting that fixed, but for now you can use the old test runner to see and fix the failures:
$ cd tests; ./run_tests -d Yaesu_FT-4XR Yaesu FT-4XR Detect PASSED: All tests Yaesu FT-4XR Settings PASSED: All tests Yaesu FT-4XR Clone PASSED: All tests Yaesu FT-4XR Edges PASSED: All tests Yaesu FT-4XR BruteForce PASSED: All tests Yaesu FT-4XR CopyAll FAILED: <100>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <101>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <102>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <103>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <104>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <105>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <106>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <107>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <108>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <109>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <110>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <111>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <112>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <113>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <114>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <115>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <116>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <117>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <118>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <124>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <125>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <127>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <141>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <142>: Field `ctone' is `88.5', expected `179.9' Yaesu FT-4XR CopyAll FAILED: <143>: Field `ctone' is `88.5', expected `179.9' Yaesu FT-4XR CopyAll FAILED: <144>: Field `ctone' is `88.5', expected `179.9' Yaesu FT-4XR CopyAll FAILED: <145>: Field `ctone' is `88.5', expected `179.9' Yaesu FT-4XR CopyAll FAILED: <146>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <147>: Field `ctone' is `88.5', expected `156.7' Yaesu FT-4XR CopyAll FAILED: <148>: Field `ctone' is `88.5', expected `131.8' Yaesu FT-4XR CopyAll FAILED: <149>: Field `ctone' is `88.5', expected `131.8' Yaesu FT-4XR Banks PASSED: All tests
Results: TOTAL : 37 FAILED : 31 SKIPPED: 0 PASSED : 6 CRASHED: 0
It looks like you're always looking at mem.rtone instead mem.ctone when the tone mode is TSQL.
There is no radio version and/or ID testing: I don't know how and I only have one radio.
What does this mean exactly? If it works with your radio you're probably okay. Right here it looks like you get back a version or identification string from the radio:
if b"QX" != sendcmd(pipe, b"PROGRAM", 2): raise errors.RadioError("expected QX from radio.") version = sendcmd(pipe, b'\x02', 15)
If that is always the same for you, then it's probably good to just check that it's what you expect and fail if not.
The FT-65 is assumed to be (almost) identical to the FT-4. The FT-65 has 4 programmable keys instead of 2 (I coded for these) and some settings I did not code for. I will get to those when I have more access to a FT-65
Okay, let's not register the FT-65 then (you can leave the definition there) until we get some confirmation that it works.
I also noticed that if I try to edit the first memory in your image to see the extra settings, I get a crash and traceback (and no dialog). Can you take a look at that?
I haven't gone through the code itself much yet. If you could do the patch thing according to the dev process, de-register the FT65, fix the test failures, and the mem.extra crash, I'd appreciate it. I'll work on getting the test adapter fixed.
Thanks!
--Dan
Thanks!
The code looks only at ctone in that case because that's the way I (perhaps incorrectly) interpreted the description at : https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModes I'll fix it. How do you run the test manually?
The version(?) string I get back is b'IFT-35R\x00\x00V100\x00\x00\0x06' This looks like it's generic for all radios that use the Yaseu ICU-35 cable, and that it has provisions for versioning. There is also information in the radio's memory block 0. This looks like (perhaps) a radio software version. If I fail out, it is possible to let the user decide to continue?
On Sat, Feb 16, 2019 at 11:34 AM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi Dan,
I cannot figure out how to submit an entirely new driver, so Its here as
an attachment, along with the .img file.
It's pretty much the same as any other change. What are you struggling with? I just added a few lines to the developer process page about adding a new file in case it is not obvious:
https://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Soft-commi...
I would definitely prefer to integrate this as a patch if possible.
This driver runs and passes the pep and tox tests on both Python 2 and
Python 3. I am of course clueless about any python 2 and Python3 subtleties
Actually, it fails one test, BUT you didn't notice because I just realized the test adapter for unittest is broken in a subtle way. I just happened to run tests on your file manually since it wasn't in patch format and noticed that it failed that way but didn't with the automation. I will work on getting that fixed, but for now you can use the old test runner to see and fix the failures:
$ cd tests; ./run_tests -d Yaesu_FT-4XR Yaesu FT-4XR Detect PASSED: All tests Yaesu FT-4XR Settings PASSED: All tests Yaesu FT-4XR Clone PASSED: All tests Yaesu FT-4XR Edges PASSED: All tests Yaesu FT-4XR BruteForce PASSED: All tests Yaesu FT-4XR CopyAll FAILED: <100>: Field `ctone' is
`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <101>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <102>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <103>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <104>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <105>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <106>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <107>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <108>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <109>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <110>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <111>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <112>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <113>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <114>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <115>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <116>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <117>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <118>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <124>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <125>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <127>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <141>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <142>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <143>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <144>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <145>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <146>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <147>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <148>: Field `ctone' is`88.5', expected `131.8'
Yaesu FT-4XR CopyAll FAILED: <149>: Field `ctone' is`88.5', expected `131.8'
Yaesu FT-4XR Banks PASSED: All tests
Results: TOTAL : 37 FAILED : 31 SKIPPED: 0 PASSED : 6 CRASHED: 0
It looks like you're always looking at mem.rtone instead mem.ctone when the tone mode is TSQL.
There is no radio version and/or ID testing: I don't know how and I only
have one radio.
What does this mean exactly? If it works with your radio you're probably okay. Right here it looks like you get back a version or identification string from the radio:
if b"QX" != sendcmd(pipe, b"PROGRAM", 2): raise errors.RadioError("expected QX from radio.") version = sendcmd(pipe, b'\x02', 15)If that is always the same for you, then it's probably good to just check that it's what you expect and fail if not.
The FT-65 is assumed to be (almost) identical to the FT-4. The FT-65 has
4 programmable keys instead of 2 (I coded for these) and some settings I did not code for. I will get to those when I have more access to a FT-65
Okay, let's not register the FT-65 then (you can leave the definition there) until we get some confirmation that it works.
I also noticed that if I try to edit the first memory in your image to see the extra settings, I get a crash and traceback (and no dialog). Can you take a look at that?
I haven't gone through the code itself much yet. If you could do the patch thing according to the dev process, de-register the FT65, fix the test failures, and the mem.extra crash, I'd appreciate it. I'll work on getting the test adapter fixed.
Thanks!
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
The code looks only at ctone in that case because that's the way I (perhaps incorrectly) interpreted the description at : https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModes I'll fix it. How do you run the test manually?
The command is the first line of the quoted failures from my last mail, but basically:
$ cd tests $ ./run_tests -d Yaesu_FT-4XR
The version(?) string I get back is b'IFT-35R\x00\x00V100\x00\x00\0x06' This looks like it's generic for all radios that use the Yaseu ICU-35 cable, and that it has provisions for versioning.
Hmm, well, I'd tend to do something with that. How about just making sure it starts with IFT-35R and if so, plow ahead?
There is also information in the radio's memory block 0. This looks like (perhaps) a radio software version. If I fail out, it is possible to let the user decide to continue?
No, but it's usually good to be conservative here. I would say log information about what you got and what you were expecting and then raise RadioError saying that the model appears incompatible. Then if someone files a bug about having a FT-4XR that should work but doesn't, we can go from there.
I meant to say in the last email: Thanks a lot for caring about making it work on python3 as well :)
I figured out the issue in the test runner and will get that pushed up soonish.
Thanks!
--Dan
I'm a python newbie, working in a weird environment (Gentoo Linux). I could not run ./runtest in either my Pythom 2 repository (tip) or in my py3 branch repository. When I forced it on my python 2 repository by modifying the bash script to run python2, the test passed. Hmm. I'll wait for your patch.
On Sat, Feb 16, 2019 at 12:43 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
The code looks only at ctone in that case because that's the way I
(perhaps incorrectly) interpreted the description at :
https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModesI'll fix it. How do you run the test manually?
The command is the first line of the quoted failures from my last mail, but basically:
$ cd tests $ ./run_tests -d Yaesu_FT-4XR
The version(?) string I get back is b'IFT-35R\x00\x00V100\x00\x00\0x06' This looks like it's generic for all radios that use the Yaseu ICU-35
cable, and that it has provisions for versioning.
Hmm, well, I'd tend to do something with that. How about just making sure it starts with IFT-35R and if so, plow ahead?
There is also information in the radio's memory block 0. This looks like
(perhaps) a radio software version.
If I fail out, it is possible to let the user decide to continue?
No, but it's usually good to be conservative here. I would say log information about what you got and what you were expecting and then raise RadioError saying that the model appears incompatible. Then if someone files a bug about having a FT-4XR that should work but doesn't, we can go from there.
I meant to say in the last email: Thanks a lot for caring about making it work on python3 as well :)
I figured out the issue in the test runner and will get that pushed up soonish.
Thanks!
--Dan
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
I'm a python newbie, working in a weird environment (Gentoo Linux). I could not run ./runtest in either my Pythom 2 repository (tip) or in my py3 branch repository. When I forced it on my python 2 repository by modifying the bash script to run python2, the test passed. Hmm. I'll wait for your patch.
It should fail on both, FWIW, so I dunno, but I just pushed the fix on the default branch for running under tox. I'll be pushing the py3 one soon.
--Dan
Here is the patch (as an attachment) and the image file (again, just in case). bugs fixed and FT-65 unregistered as you requested.
On Sat, Feb 16, 2019 at 11:34 AM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi Dan,
I cannot figure out how to submit an entirely new driver, so Its here as
an attachment, along with the .img file.
It's pretty much the same as any other change. What are you struggling with? I just added a few lines to the developer process page about adding a new file in case it is not obvious:
https://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Soft-commi...
I would definitely prefer to integrate this as a patch if possible.
This driver runs and passes the pep and tox tests on both Python 2 and
Python 3. I am of course clueless about any python 2 and Python3 subtleties
Actually, it fails one test, BUT you didn't notice because I just realized the test adapter for unittest is broken in a subtle way. I just happened to run tests on your file manually since it wasn't in patch format and noticed that it failed that way but didn't with the automation. I will work on getting that fixed, but for now you can use the old test runner to see and fix the failures:
$ cd tests; ./run_tests -d Yaesu_FT-4XR Yaesu FT-4XR Detect PASSED: All tests Yaesu FT-4XR Settings PASSED: All tests Yaesu FT-4XR Clone PASSED: All tests Yaesu FT-4XR Edges PASSED: All tests Yaesu FT-4XR BruteForce PASSED: All tests Yaesu FT-4XR CopyAll FAILED: <100>: Field `ctone' is
`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <101>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <102>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <103>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <104>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <105>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <106>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <107>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <108>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <109>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <110>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <111>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <112>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <113>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <114>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <115>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <116>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <117>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <118>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <124>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <125>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <127>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <141>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <142>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <143>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <144>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <145>: Field `ctone' is`88.5', expected `179.9'
Yaesu FT-4XR CopyAll FAILED: <146>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <147>: Field `ctone' is`88.5', expected `156.7'
Yaesu FT-4XR CopyAll FAILED: <148>: Field `ctone' is`88.5', expected `131.8'
Yaesu FT-4XR CopyAll FAILED: <149>: Field `ctone' is`88.5', expected `131.8'
Yaesu FT-4XR Banks PASSED: All tests
Results: TOTAL : 37 FAILED : 31 SKIPPED: 0 PASSED : 6 CRASHED: 0
It looks like you're always looking at mem.rtone instead mem.ctone when the tone mode is TSQL.
There is no radio version and/or ID testing: I don't know how and I only
have one radio.
What does this mean exactly? If it works with your radio you're probably okay. Right here it looks like you get back a version or identification string from the radio:
if b"QX" != sendcmd(pipe, b"PROGRAM", 2): raise errors.RadioError("expected QX from radio.") version = sendcmd(pipe, b'\x02', 15)If that is always the same for you, then it's probably good to just check that it's what you expect and fail if not.
The FT-65 is assumed to be (almost) identical to the FT-4. The FT-65 has
4 programmable keys instead of 2 (I coded for these) and some settings I did not code for. I will get to those when I have more access to a FT-65
Okay, let's not register the FT-65 then (you can leave the definition there) until we get some confirmation that it works.
I also noticed that if I try to edit the first memory in your image to see the extra settings, I get a crash and traceback (and no dialog). Can you take a look at that?
I haven't gone through the code itself much yet. If you could do the patch thing according to the dev process, de-register the FT65, fix the test failures, and the mem.extra crash, I'd appreciate it. I'll work on getting the test adapter fixed.
Thanks!
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (2)
-
Dan Clemmensen -
Dan Smith