This is my experience so far with CHIRP and the TM-D700A radio. The radio receives input from CHIRP in Live mode, with changes being in near real-time on the control head. Turning the radio off and on and then re-downloading the memory slots displays what was entered previously (of course it would, why are you mentioning that?). I can understand why RT Systems stopped supporting this model calling it a “cranky” radio. Here are some observed anomalies, and the solutions I found to work after much experimentation:

I have no idea that RT Systems is referring to, FWIW. These are some of the most reliable and well-behaved radios I've worked on (and I've worked on hundreds of models). They're especially well-behaved because the memory format is well-defined, well-understood, and sanity checked by the radio in real-time. Where many radios will happily let you send them garbage that will cause them to choke, these "live" kenwoods do 100% sanity checking on everything you send them. Quirky? Perhaps, but not cranky, IMHO :D

• Although the frequencies and memory names from CHIRP stick with the radio, the Tones do not, and even if the correct tone is there, moving to another memory slot and back to the previous memory loses the Tone setting.

There are two things going on here:

1. I went to try to replicate the behavior you're seeing and realized that a seemingly-innocuous and unrelated cleanup a couple months ago broke the tone indexing in this driver. You should absolutely be able to set the tone values in the D700 with total reliability, but CHIRP was sending the wrong index. I filed https://www.chirpmyradio.com/issues/11236 for that and it will be fixed in tree soon.

2. If you have a memory on the screen and you modify it via the computer, it doesn't update the memory you're seeing in realtime. You have to roll off and back onto the memory to see what you just sent. No mystery here, the radio just loads memories into a buffer while you're looking at them, which is what lets you make temporary changes (like changing tone or mode). The PC changes only what is in memory, not what is in the buffer.

In the future, anything like the tone mismatch should be filed as a bug so you can attach debug logs and I can "charge" a fix against that report. If it's something that CHIRP can't fix, it's easy to close it as not-a-bug :)

• This radio pays attention to which Band it’s in (see TM-D700 Manual, p.41). By default Band A (the Left knob) is for VHF, and Band B (the Right knob) is for UHF. I’ve learned to be sure to bring up for PTT in the Band associated with the frequency in a specific memory slot (listening to anything on either Band works fine with no problem). That also is the case for programming a memory slot, that is, program VHF frequencies with Band A and UHF frequencies with Band B, including correcting the Tone setting that it received from CHIRP and didn’t keep.

This is pretty conventional for radios of the era of the D700. Some less friendly radios even store the VHF and UHF memories in different locations such that you can't recall any memory on either side and have a fixed number of each type you can store. I agree it's annoying, but it's less annoying than its siblings from other brands at the time.

• I’m not sure this is something that CHIRP can solve: The Repeater Book look ups contain errors in the Tone settings. A couple of examples I’m directly familiar with are:

Nope, if the values are wrong in repeaterbook, they need to be corrected there. If CHIRP is interpreting something from the database incorrectly (i.e. configuring a TSQL when it shouldn't) then please file a bug with a link to the repeater entry and I'll be glad to have a look.

Thanks!

--Dan