Add rt493 rt580g drivers #1299

paulober · 2025-03-22T13:21:42Z

rt-493 and rt-580g: Add drivers

Adds drivers for the Radtel RT-493 and RT-580G radios.

paulober · 2025-03-22T14:25:23Z

I think there is a bug with the immutable system. If you add "extra" to the list of immutable values your mem.extra fields get disabled as they should. But if you then try to edit the name of this channel you get a warning that extra is set to immutable. I think the name field should not get counted towards the extra fields but if, then it should also be disabled in UI.

kk7ds · 2025-03-22T14:32:50Z

I think there is a bug with the immutable system. If you add "extra" to the list of immutable values your mem.extra fields get disabled as they should. But if you then try to edit the name of this channel you get a warning that extra is set to immutable. I think the name field should not get counted towards the extra fields but if, then it should also be disabled in UI.

Yep, probably, I'll have a look. Can you open a bug on the chirp site for this and I'll take it?

paulober · 2025-03-22T14:38:15Z

Yep, probably, I'll have a look. Can you open a bug on the chirp site for this and I'll take it?

https://chirpmyradio.com/issues/11904

paulober · 2025-05-04T21:43:20Z

@kk7ds I want to finally get this driver merged so I was working on the last tox errors. One of them again concerns immutability: chirp.chirp_common.ImmutableValueError: Field tmode is not mutable on this memory I also get it for offset and probably for more if I were to remove tmode. So basically the policy is if a channel is in AM mode most settings for that channel are locked.
What is the origin of this error and how should I fix it?

kk7ds · 2025-05-05T21:57:32Z

ImmutableValueError is raised when you try to modify something on a memory that is in the immutable list set on it.

Signed-off-by: paulober <[email protected]>

kk7ds

Thanks for working on this. I left a bunch of comments. I haven't reviewed all of it because a bunch of things will change as a result of those. Also, are you sure that none of the existing drivers are re-usable or adaptable for either of these radios?

kk7ds · 2025-10-21T00:08:09Z

chirp/drivers/radtel_rt493.py

+    LOG.debug(util.hexprint(hdr + data))
+
+    c, a, resp_length = struct.unpack(">BHB", hdr)
+    if a != int.from_bytes(addr, byteorder="big") \


Please don't do this. You should be passing addr into this as an integer not a bytestring, so no such interpretation should be necessary. I try to discourage use of int.from_bytes() everywhere in the codebase and use struct where necessary to keep things consistent and explicit about lengths.

kk7ds · 2025-10-21T00:09:25Z

chirp/drivers/radtel_rt493.py

+
+    # DEBUG
+    LOG.info("Response:")
+    LOG.debug(util.hexprint(hdr + data))


No need to do this. We have automatic full tracing happening and this just inflates the logs (and makes them hard to read).

kk7ds · 2025-10-21T00:11:08Z

chirp/drivers/radtel_rt493.py

+
+
+def _read_block(radio, channel_id):
+    address = bytes(_get_memory_address(channel_id))


This should be returning an integer and not passing around order-dependent bytestrings for something like this. Fixing this will also address what would be my comment on L131 below about the comparison. And of course, the manual formatting of each byte on L123...

kk7ds · 2025-10-21T00:11:17Z

chirp/drivers/radtel_rt493.py

+
+    # Sending an accept after reading the first line will crash
+    # the communication. The accept is sent when entering programming
+    # mdoe, so before reading the first block


"mode" is misspelled/.

kk7ds · 2025-10-21T00:13:18Z

chirp/drivers/radtel_rt493.py

+    0x8A: 88, 0x94: 89, 0x97: 90, 0x99: 91, 0x9A: 92, 0xA5: 93,
+    0xAC: 94, 0xB2: 95, 0xB4: 96, 0xC3: 97, 0xCA: 98, 0xD3: 99,
+    0xD9: 100, 0xDA: 101, 0xDC: 102, 0xE3: 103, 0xEC: 104,
+}


Isn't this just a list of the codes in order? Why can't you use chirp_common.DTCS_CODES?

kk7ds · 2025-10-21T00:18:55Z

chirp/drivers/radtel_rt493.py

+        elif setting == "VOXF":
+            byte1 = self._memobj.memory[4-1].global1.get_raw()
+
+            return bool(int.from_bytes(byte1, byteorder="big") & 0x01)


Please don't do this sort of thing. Identify the bits in the bitwise definition and get/set them ad objects instead of doing your own bit ops.

kk7ds · 2025-10-21T00:19:46Z

chirp/drivers/radtel_rt493.py

+            elif isinstance(element.value, RadioSettingValueInteger):
+                self._set_int(element.get_name(), int(element.value))
+            else:
+                LOG.error("Unknown setting type: %s" % element.value)


New drivers should ideally be using MemSetting which handles symbolic application of almost all the standard types directly to the memory object, eliminating the need for all this bespoke code.

kk7ds · 2025-10-21T00:24:39Z

chirp/drivers/radtel_common.py

+def rt_clean_buffer(radio: RadtelLikeRadio, LOG: Logger):
+    radio.pipe.timeout = 0.005
+    junk = radio.pipe.read(256)
+    radio.pipe.timeout = 5  # 5000ms


Please don't do this sort of thing. On Windows, setting the timeout value flushes the buffer and can do other things to the serial driver that don't happen on the other platforms. Switching the timeout in quick succession will give platform-dependent results and should be avoided. I imagine Serial.reset_input_buffer() is all you need.

kk7ds · 2025-10-21T00:27:11Z

chirp/drivers/radtel_common.py

+    return calculated_checksum == data[-1]
+
+
+def rt_read_block(


This and rt_do_download() don't appear to be used by at least the rt493 driver. TBH, this common file doesn't seem to be all that common and shared bits could easily be in one of the two drivers and imported from the other. Several of my comments in the r493 file that I started reviewing first apply here.

kk7ds · 2025-10-21T00:29:34Z

chirp/drivers/radtel_common.py

+BLOCK_SIZE = 0x10  # 16 bytes
+
+
+class RadtelLikeRadio(Protocol):


I don't see that you're using this anywhere? Also, please don't create new inheritance hierarchies for your drivers. If you want to have a common base class that inherits from chirp_common.Radio that you use for your drivers, that's cool, but this has no common ancestry.

paulober force-pushed the add-rt493-rt580g-drivers branch from 7647e8e to 7d21bf2 Compare May 19, 2025 23:12

paulober added 7 commits October 19, 2025 00:57

Add Radtel RT-493 Driver

d701ede

rt-580g: Add driver

15fc808

rt-580g: Fix channel name editing

df5be2f

Signed-off-by: paulober <[email protected]>

Fix linting

be2ef59

Signed-off-by: paulober <[email protected]>

Moved common functions of rt-580g and rt-493 into radtel_common

80891af

Fix mem.extra mutability

b817a9a

Signed-off-by: paulober <[email protected]>

Add split duplex

a4ca8f4

Signed-off-by: paulober <[email protected]>

paulober force-pushed the add-rt493-rt580g-drivers branch from 7d21bf2 to a4ca8f4 Compare October 18, 2025 23:57

paulober added 2 commits October 19, 2025 02:23

Fix tests

4d8e997

Signed-off-by: paulober <[email protected]>

Fix tests

7ed9f7c

Signed-off-by: paulober <[email protected]>

paulober marked this pull request as ready for review October 19, 2025 02:28

kk7ds reviewed Oct 21, 2025

View reviewed changes



		def _read_block(radio, channel_id):
		address = bytes(_get_memory_address(channel_id))

		BLOCK_SIZE = 0x10 # 16 bytes


		class RadtelLikeRadio(Protocol):

Add rt493 rt580g drivers #1299

Are you sure you want to change the base?

Add rt493 rt580g drivers #1299

Uh oh!

Conversation

paulober commented Mar 22, 2025

Uh oh!

paulober commented Mar 22, 2025

Uh oh!

kk7ds commented Mar 22, 2025

Uh oh!

paulober commented Mar 22, 2025

Uh oh!

paulober commented May 4, 2025

Uh oh!

kk7ds commented May 5, 2025

Uh oh!

kk7ds left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants