So maybe you can help me clear up the setting logic.

Is set_memory called for every channel at some point, or only when channels are "touched" (i.e., some control event fired in ui)?

How exactly would chirp deal with a channel imported w/ 6.25 step, if it is not in my valid_tuning_steps?

Would it leave tuning_step empty?

So i fixed my tones with this:

TONES = list(chirp_common.TONES)

for tone in [ 165.5, 171.3, 177.3 ]:

TONES.remove(tone)

But I dont see anywhere to tell chirp about this new list, such returning a RadioFeatures.valid_tones, etc in get_features.

Should I be mutating chirp_commons.TONES directly?

From: Dan Smith <dsmith@danplanet.com>
To: chirp_devel@intrepid.danplanet.com
Sent: Sunday, August 25, 2013 5:24 PM
Subject: Re: [chirp_devel] [FT-90] add initial support for FT-90R. #1087

> I'm currently working on mapping out the special channels (vfos,
> calls, u/l scan limits) as well as the some of the global settings.
> I'm not sure exactly how those special channels are dealt with, as I
> didnt see a sample implementation in template, just an actual
> implementation like ft-857, etc.

Yeah, that's unfortunately pretty ugly right now. Looking at one of the
other implementations will get you there.

> How can I solve the issues with importing from floats that dont match
> (i.e., 6.25)? do I need to bracket them into my list at get_memory or
> set_memory time?

What do you mean? If you don't declare that you support 6.25kHz splits
then CHIRP won't ask your driver to attempt to set one.

> On the ToneSql type, how do I preserve a channel setting for Bell or
> Auto, if chirp doesnt support it. Do I have to be destructive and box
> all channels into one of the supported types? It's totally possible
> to have set Bell or Auto in memory on the radio. What happens when I
> import this now? How should I deal with this, if I cant tell chirp
> what are possible/legal values for my radio?

Right now, we just coerce those to supported values, which ends up
losing the bell setting if the user attempts to write to that memory
channel. You could, I suppose, detect and preserve that bit prior to
setting it if you want, but then the user would have to disable an
errant bell bit on the radio itself. You could expose that in the extra
settings...

> I commented out the ARS code, but now if I can do custom fields (i'll
> see how it's done with uv-5r) then I may be able to make this a bool
> field, and deal with the logic of ignoring/setting duplex field in
> get/set memory members.

Cool.

> I understand it is semantics and style, but since
> these allowed tone values for this particular radio will NEVER
> change, I don't want to be dependent upon chirp_common tones never
> changing.

I understand it's a bit icky, but we've done okay for five years on
this model.

> It would be a long shot that they ever do change, but if
> they do, it would be more difficult to determine which tones are now
> supported/unsupported, since the "source of truth" gets altered.

I understand. The reason we started with this pattern pre-dates CHIRP
supporting anything but Icom radios, and a few other things. It's all
in git history and the subtractive model makes it easier to eye-parse
the differences.

Thanks!

--
Dan Smith
www.danplanet.com
KK7DS
_______________________________________________
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