The DJ-500 has one extra tone (62.5 Hz) additional to the regular tones, and one special setting "Custom" with a separate channel property for the CTCSS frequency in the range of 62.5 Hz to 254.1 Hz in steps of 0.1 Hz. I can handle the special tone, but whenever the value is set to Custom, split_tone_encode boils out because Memory has only the tones from chirp_common.py, and I do not know how to reliably tell it to accept extended tones.
What is the right way to tell it what to do? I tried subclassing Memory, but I'm unsure if this holds.
Well, the 62.5Hz tone is already in TONES_EXTRA (IIRC, for alinco specifically), so you should be good there.
TBH, I'm not sure there is a good solution for this really without a lot of refactoring. If it were me, I think I'd probably force tone mode to None and handle the custom-ness in the special properties. Any time a custom tone is set, regular tone mode is forced to None. If you change the tone mode to non-None, then you unset the custom property.
Btw. the tmode and split_tone_decode/encode system is quite a quirks for the DJ-500. It has tone modes, tone and polarity for RX and TX, both CTCSS and DCS, which are freely interchangeable. It's confusing in this context to select TSQL etc. and not have them verbose mapped in the GUI to what is actually stored in the radio. I guess this is a concept that works better for other radios and is rooted there. Anyway, maybe I did not graps the concept completely. Any explanation optionally welcome.
The UI's notion of Tone, TSQL, etc, really has no bearing on what the radio can support. When CHIRP was young, the only radios it supported had strict notions of these kinds of tone modes. Since then, many (many) radios have been supported that have completely free-form TX and RX squelch modes. If the UI requests Tone, then that means TX tone is rtone and nothing for RX tone. If it requests TSQL, then TX and RX tones are ctone. If it's "Cross" then do what the cross_tone field says. What the radio implements really shouldn't change the look and feel that the user gets (for better or worse) as part of the UI.
--Dan