Bug #11360
closedAlinco DR-735T new memory slot settings
100%
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
Updated by Corey Denton 6 months ago
Correction: the settings that get activated and cannot be removed are the "bell" and "favorite" settings. This issue still exists in version 20240524.
Updated by Alexandre J. Raymond 6 months ago
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
Updated by Alexandre J. Raymond 6 months ago
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).
Updated by Dan Smith 6 months ago
Let's get a read from @Jacob Calvert, although I suspect clearing those bits is the right course of action.
Updated by Jacob Calvert 5 months ago
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.
Updated by Jacob Calvert 7 days ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|29f8102293c8c47a14112be6026e0641de59bf6d.