Thanks, Dan for the pointers. You were pretty quick to add the test to help identify my problem. Yay!

I’ve updated my copy of the CHIRP drivers for Yaesu FT-1, FT2 and FT3. They pass tox tests and seem to work fine. (Yes, yes: I’m probably missing something obvious.)

In the chirp homepage Issues tab, I submitted new bug and feature requests to match what I’ve done (#10628, #10629, the old #6151) and what I hope to do (#7561 and #10630, which refers to #5167.) I refactored my changes into several Git commits, which allowed me to split up the changes into somewhat-manageable chunks. I’ve attached a truncated log (unix text file) of the Git changes. I even think that the Yaesu FTM3200D_R has not broken with the changes (although it may not pass tox driver tests.)

I know that I’ve got to get these drivers to the GitHub somehow, sometime. Do I simply git push my branch up to Github? What’s the proper method? Will it keep note of my commits, or does it come as one big push, or must I push each one separately?

PS. I’ve a few mechanical questions for future work: - Can banks be made to show connections to special memory registers? That might be an ideal way to handle Yaesu’s bank-accessible preset memories, which are not in any memory available to CHIRP. I believe the Yaesu single-digit line (1, 2, 3, 4, and 7) all use these presets. - The file reading/writing is pretty opaque to me. I’d like to add a new type of file (.dat and/or .img) that is pretty much a memory image with a pretended header. (Not replace the present ADMS format .ftXd files.) Is there a reasonable template for adding a filetype?

Thanks. I’m hoping to at least get my changes into some tester hands for these radios.

______ Declan Rieb WD5EQY wd5eqy@arrl.net