Project

General

Profile

Actions

Bug #11360

closed

Alinco DR-735T new memory slot settings

Added by Corey Denton 6 months ago. Updated 7 days ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
05/25/2024
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next
Model affected:
Alinco DR-735T
Platform:
Linux
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

Alinco_DR735T_20240520.img (62.7 KB) Alinco_DR735T_20240520.img Corey Denton, 05/25/2024 06:16 PM
Actions #1

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.

Actions #2

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
Actions #3

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).

Actions #4

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.

Actions #5

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.

Actions #6

Updated by Jacob Calvert 7 days ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
Actions

Also available in: Atom PDF