CHIRP

Correction: the settings that get activated and cannot be removed are the "bell" and "favorite" settings. This issue still exists in version 20240524.

Looking at your log file, the issue seems to be that some channel struct members are not explicitly initialized in the driver's set_memory() function, resulting in 0xFF bytes by default.

Compare this (set using radio):

5500000110985507C027090000000808000000008000000047353754545400000000000000000000000000000000000000000000000000000000000000000000
    ^^favorite setting
                                              ^^bell setting

with this (set using CHIRP):

5500FFFF38DC931B000000000001160000FF00008000FFFF40464B4C3230FFFF000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
    ^^favorite setting
                                              ^^bell setting

I would expect part of the fix to be something like this:

diff --git a/chirp/drivers/alinco_dr735t.py b/chirp/drivers/alinco_dr735t.py
index f4097732..b3bf8a31 100644
--- a/chirp/drivers/alinco_dr735t.py
+++ b/chirp/drivers/alinco_dr735t.py
@@ -284,6 +284,8 @@ class AlincoDR735T(chirp_common.CloneModeRadio):
             _mem.power_index = self.POWER_MAP.index(
                 mem.power) if mem.power in self.POWER_MAP else 0
             _mem.skip = 0x01 if mem.skip == "S" else 0x00
+            _mem.favorite = 0
+            _mem.bell = 0
             try:
                 _mem.rx_tone_index = ALINCO_TONES.index(
                     mem.rtone)

but other fields are also uninitialized (resulting in 0xFF bytes when programmed with CHIRP), and I don't know what the effect of setting them to 0x00 would be (or leaving them to 0xFF for that matter).

Let's get a read from @Jacob Calvert, although I suspect clearing those bits is the right course of action.

Sorry for the long delay. Yes, I think we should set them explicitly. I left those bytes unchanged when read from the radio assuming that the cleared radio channel would be in some default state -- this is a bad assumption, and for uninitialized channels the whole config struct is 0xFF's. As an aside, what I've discovered (from previous investigations) is that on a factory reset, the channels are all 0xFF's. When you clear a channel using the Alinco programming software it's set to all 0x00's. This makes sense why you're seeing the 0xFF be written back for previously-uninitialized, now-used channels. Setting them to default 0x00 should fix this going forward.