<div dir="ltr"><div dir="ltr"><div>Thanks!<br></div><div><br></div><div>The code looks only at ctone in that case because that's the way I (perhaps incorrectly) interpreted the description at :</div><div> <a href="https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModes">https://chirp.danplanet.com/projects/chirp/wiki/DevelopersToneModes</a></div><div>I'll fix it. How do you run the test manually?</div><div><br></div><div>The version(?) string I get back is</div><div> b'IFT-35R\x00\x00V100\x00\x00\0x06'</div><div>This looks like it's generic for all radios that use the Yaseu ICU-35 cable, and that it has provisions for versioning.</div><div>There is also information in the radio's memory block 0. This looks like (perhaps) a radio software version.<br></div><div>If I fail out, it is possible to let the user decide to continue?<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 16, 2019 at 11:34 AM Dan Smith via chirp_devel <<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dan,<br>
<br>
> I cannot figure out how to submit an entirely new driver, so Its here as an attachment, along with the .img file.<br>
<br>
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:<br>
<br>
<a href="https://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Soft-committing-a-Change" rel="noreferrer" target="_blank">https://chirp.danplanet.com/projects/chirp/wiki/DevelopersProcess#Soft-committing-a-Change</a><br>
<br>
I would definitely prefer to integrate this as a patch if possible.<br>
<br>
> 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 <br>
<br>
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:<br>
<br>
> $ cd tests; ./run_tests -d Yaesu_FT-4XR<br>
> Yaesu FT-4XR Detect PASSED: All tests<br>
> Yaesu FT-4XR Settings PASSED: All tests<br>
> Yaesu FT-4XR Clone PASSED: All tests<br>
> Yaesu FT-4XR Edges PASSED: All tests<br>
> Yaesu FT-4XR BruteForce PASSED: All tests<br>
> Yaesu FT-4XR CopyAll FAILED: <100>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <101>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <102>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <103>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <104>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <105>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <106>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <107>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <108>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <109>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <110>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <111>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <112>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <113>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <114>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <115>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <116>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <117>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <118>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <124>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <125>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <127>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <141>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <142>: Field `ctone' is `88.5', expected `179.9'<br>
> Yaesu FT-4XR CopyAll FAILED: <143>: Field `ctone' is `88.5', expected `179.9'<br>
> Yaesu FT-4XR CopyAll FAILED: <144>: Field `ctone' is `88.5', expected `179.9'<br>
> Yaesu FT-4XR CopyAll FAILED: <145>: Field `ctone' is `88.5', expected `179.9'<br>
> Yaesu FT-4XR CopyAll FAILED: <146>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <147>: Field `ctone' is `88.5', expected `156.7'<br>
> Yaesu FT-4XR CopyAll FAILED: <148>: Field `ctone' is `88.5', expected `131.8'<br>
> Yaesu FT-4XR CopyAll FAILED: <149>: Field `ctone' is `88.5', expected `131.8'<br>
> Yaesu FT-4XR Banks PASSED: All tests<br>
> ----------------------------------------------------------------------<br>
> Results:<br>
> TOTAL : 37<br>
> FAILED : 31<br>
> SKIPPED: 0<br>
> PASSED : 6<br>
> CRASHED: 0<br>
<br>
<br>
It looks like you're always looking at mem.rtone instead mem.ctone when the tone mode is TSQL.<br>
<br>
> There is no radio version and/or ID testing: I don't know how and I only have one radio.<br>
<br>
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:<br>
<br>
> if b"QX" != sendcmd(pipe, b"PROGRAM", 2):<br>
> raise errors.RadioError("expected QX from radio.")<br>
> version = sendcmd(pipe, b'\x02', 15)<br>
<br>
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.<br>
<br>
> 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<br>
<br>
Okay, let's not register the FT-65 then (you can leave the definition there) until we get some confirmation that it works.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Thanks!<br>
<br>
--Dan<br>
_______________________________________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a><br>
</blockquote></div>