[chirp_devel] FT1D and UI... seems to be OK, now. A bit of help still desired.

[Declan Rieb]

> On Jun 7, 2023, at 13:00, chirp_devel-request at intrepid.danplanet.com wrote:

Thanks for the very prompt attention. I’m trying to add features to the ft2d.py (and ft3d.py) but they’re almost all handled in the ft1d.py, which radio has the same features (along with several other Yaesu radios.) And you’ve described a “feature” of my driver that I am vaguely aware of.
In the radio, they are indeed in adjacent slots!

So, I looks as if I’ve fixed it by making the number field negative for specials (as I’ve seen in others’ implementations. Doh!) Yay, so far. Tox was still happy with the new driver. (Unless you’re VERY fast, I’ve not done a git pull since this morning.) You pointed me in the right direction. It’s still a bit strange that it only shows up in the UI, but I understand that I confused it.

I think it’ll be a wonderful idea to add a tax  test to check for my (previous?!) bad implementation.

> I haven't debugged your problem, but the reason for the UI disconnect is that you;'re returning an overlapping set of special memories with the regular ones. You need to map your special memories somewhere that does not overlap with the regular numbered memories (i.e. start right after the last regular memory). So when you edit memory 1, you'll notice that "Home2" actually changes waaay down at the bottom of the memory editor. During the initial load, you've returned a special memory with a number=1 and so chirp thinks that's where memory number 1 goes.
> 
> I'll take a todo to write a test to cover this if we really don't already h one.

Yes, I’ve made many changes, serially, and only locally. I’ll happily work on the big GitHub. I can also try to separate them, and build a branch on your real master onto GitHub. But: (A big but:) I’ve never used git in a collaborative environment, and am afraid of messing up the big github somehow. I’ve only entered one “issue” in your CHIRP documentation (#6151, asking to add digital settings) and some of my changes attend to that. 
	There is a logic error that prevents CHIRP from initializing settings on a default Yaesu ADMS-x file; I’ve not entered a bug report for it, but it was an easy fix. 
	Adding the specials was a labor of love, since the FT4 driver does it fine. 
	I’ve noticed that #7561 exists, and since I’m aware that the .dat files are essentially the same as the .ftXd files (I think ten bytes’ difference in header) that I can try to fix that one too (that’d be a boon since these radios can save memory to an Scared, using the .dat file format, so folks could handle the radio without having to buy the [ahem: very expensive] Yaesu programming cable, bypassing a lot of headaches for you, I think!) I’ve not started on that.
	Yaesu has more than 100 preset frequencies for use only on receive (WX channels, maritime VHF, SW broadcast.) Several of their radios have these defined and can be accessed by the VFO AND be referenced in banks. (that’s the root cause of #5167, which is now closed; CHIRP ignores the problem.) I’d like to fix that to actually handle these channels; they’re not in programmable memory, and can really only be accessed via the bank system. Perhaps they can just be specials with really big negative indices (but they do not reside in memory and are all immutable)

Is it still necessary to refer to issue numbers, especially in this age of CHIRP_next? I suppose I can add bug and feature requests to cover my efforts.
So a little handholding will help me:

What’s a PR?

I presume that I should 
	make a branch, put in one set of changes, 
		then make another branch based on the first one to add another set of changes, 
			then make another branch based on the second one to add another set of changes, 
				continuing until everything is done. Then some how I communicate to you which change sets are available? 
Or does one make multiple branches each from the master, each of which changes a smallish set of things? How does one integrate the whole mess, especially with collisions likely?

I also believe that FTM3200 radio, which inherits from the FT1D, should not be presently working. (the _mem_params arguments are in the wrong places to work right now. Should I worry about that at all? I tried to contact the driver folk listed in FTM3200.py via email, with no answer, but perhaps it’s not really used and so is moot?

>> A copy of my modified ft1d.py:<ft1d.py>
> 
> In the future, a draft github PR (or at least a diff) would be a lot easier to look at and pull down to try. However, you've got a ton of change in your .py file from current master, which makes it really hard to tell what all you've changed. Please do split that up into pieces before you submit, otherwise it'll be really difficult to review.
> 
> --Dan