Bug #11360
closed
Alinco DR-735T new memory slot settings
Added by Corey Denton 6 months ago.
Updated 20 days ago.
Model affected:
Alinco DR-735T
I read the instructions above:
Yes
Description
When programming my DR-735T, any new memory slots I create within the program result in the radio having the "bell" (squelch notification) and scan skip settings activated, and cannot be removed permanently via the radio. If I modify an existing memory slot that was originally created on the radio itself, it does not have these settings.
Channels 0-20 were programmed on the radio.
Channels 21-24 were programmed through software.
Files
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.
- Status changed from New to Closed
- % Done changed from 0 to 100
Also available in: Atom
PDF