[chirp_devel] [PATCH] [rt22] patch radio ID for RT-622
# HG changeset patch # User Dmitry Baryshkov dbaryshkov@gmail.com # Date 1603075401 -10800 # Mon Oct 19 05:43:21 2020 +0300 # Node ID 1552c486144d10aff7a63ff6d0a14b38c2c52544 # Parent de5d23f4a4235f42a3dee54e2054def2ac224572 [rt22] patch radio ID for RT-622
For RT-622 to update memory correctly, radio ID has to be written at the address 0x1b8. When reading this address reads as 0. So, patch the data during write operation to stop Chirp from overwriting radio ID on these radios.
I don't know if this operation has to be performed for other radio IDs as well, so this patching is limited to RT-622.
diff --git a/chirp/drivers/retevis_rt22.py b/chirp/drivers/retevis_rt22.py --- a/chirp/drivers/retevis_rt22.py +++ b/chirp/drivers/retevis_rt22.py @@ -205,7 +205,15 @@ serial = radio.pipe
cmd = struct.pack(">cHb", 'W', block_addr, block_size) - data = radio.get_mmap()[block_addr:block_addr + block_size] + mmap = radio.get_mmap() + data = mmap[block_addr:block_addr + block_size] + + # For some radios (RT-622) memory at 0x1b8 reads as 0, but radio ID should + # be written instead + if block_addr == radio._patch_addr: + for fp in radio._patch_id: + if fp in mmap[0:radio._patch_len]: + data = mmap[0:radio._patch_len] + data[radio._patch_len:]
LOG.debug("Writing Data:") LOG.debug(util.hexprint(cmd + data)) @@ -298,6 +306,9 @@ _memsize = 0x0400 _block_size = 0x40 _fileid = ["P32073", "P3" + "\x00\x00\x00" + "3", "P3207!"] + _patch_id = ["P3207!"] + _patch_len = 8 + _patch_addr = 0x1b8
def get_features(self): rf = chirp_common.RadioFeatures()
Dmitri,
Isn't this going to change these bytes for all models? For example, my regular RT22 which has "P32073" at 0x01b8 will be overwritten with "P3207!". I'm afraid to try this to see because I have already ruined 2 RT22 FRS models trying to add them to CHIRP.
Since it appears to me that this radio (and its RT22 FRS cousin) has "P3207!" stored at 0x0000 and 0x0200, there couldn't there be some kind of check that when 0x01b8-0x01bd is 0x00 * 6, then the value in 0x0000-0x0006 (or 0x0200-0x0206) could be sent at 0x01b8 during the upload?
I am really glad that you have discovered this because, as I mentioned above, I have already made 2 RT22 FRS radios unusable. The factory software asks for a password now (for download and upload) and so far I have not been able to discover what it is.
Jim KC9HI
On Sun, Oct 18, 2020 at 10:43 PM Dmitry Baryshkov via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
# HG changeset patch # User Dmitry Baryshkov dbaryshkov@gmail.com # Date 1603075401 -10800 # Mon Oct 19 05:43:21 2020 +0300 # Node ID 1552c486144d10aff7a63ff6d0a14b38c2c52544 # Parent de5d23f4a4235f42a3dee54e2054def2ac224572 [rt22] patch radio ID for RT-622
For RT-622 to update memory correctly, radio ID has to be written at the address 0x1b8. When reading this address reads as 0. So, patch the data during write operation to stop Chirp from overwriting radio ID on these radios.
I don't know if this operation has to be performed for other radio IDs as well, so this patching is limited to RT-622.
diff --git a/chirp/drivers/retevis_rt22.py b/chirp/drivers/retevis_rt22.py --- a/chirp/drivers/retevis_rt22.py +++ b/chirp/drivers/retevis_rt22.py @@ -205,7 +205,15 @@ serial = radio.pipe
cmd = struct.pack(">cHb", 'W', block_addr, block_size)
- data = radio.get_mmap()[block_addr:block_addr + block_size]
mmap = radio.get_mmap()
data = mmap[block_addr:block_addr + block_size]
# For some radios (RT-622) memory at 0x1b8 reads as 0, but radio ID should
# be written instead
if block_addr == radio._patch_addr:
for fp in radio._patch_id:if fp in mmap[0:radio._patch_len]:data = mmap[0:radio._patch_len] + data[radio._patch_len:]LOG.debug("Writing Data:") LOG.debug(util.hexprint(cmd + data))
@@ -298,6 +306,9 @@ _memsize = 0x0400 _block_size = 0x40 _fileid = ["P32073", "P3" + "\x00\x00\x00" + "3", "P3207!"]
_patch_id = ["P3207!"]
_patch_len = 8
_patch_addr = 0x1b8
def get_features(self): rf = chirp_common.RadioFeatures()
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
Jim,
ср, 21 окт. 2020 г. в 00:37, Jim Unroe rock.unroe@gmail.com:
Dmitri,
Isn't this going to change these bytes for all models? For example, my regular RT22 which has "P32073" at 0x01b8 will be overwritten with "P3207!". I'm afraid to try this to see because I have already ruined 2 RT22 FRS models trying to add them to CHIRP.
This sounds interesting. I'll add this check and send v2 of this patch. BTW: is there a way to check that developer options are enabled? I would not dare to enable all-zero radio ID (since this well might be some other random radio), but it would be required to restore broken RT22 radios.
Since it appears to me that this radio (and its RT22 FRS cousin) has "P3207!" stored at 0x0000 and 0x0200, there couldn't there be some kind of check that when 0x01b8-0x01bd is 0x00 * 6, then the value in 0x0000-0x0006 (or 0x0200-0x0206) could be sent at 0x01b8 during the upload?
I am really glad that you have discovered this because, as I mentioned above, I have already made 2 RT22 FRS radios unusable. The factory software asks for a password now (for download and upload) and so far I have not been able to discover what it is.
Could you please check if writing the proper string at 0x1b8 would fix your radios? It does for my RT622. However my radios still worked even when radio ID was a series of 0.
On Tue, Oct 20, 2020 at 6:36 PM Dmitry Baryshkov dbaryshkov@gmail.com wrote:
Jim,
ср, 21 окт. 2020 г. в 00:37, Jim Unroe rock.unroe@gmail.com:
Dmitri,
Isn't this going to change these bytes for all models? For example, my regular RT22 which has "P32073" at 0x01b8 will be overwritten with "P3207!". I'm afraid to try this to see because I have already ruined 2 RT22 FRS models trying to add them to CHIRP.
This sounds interesting. I'll add this check and send v2 of this patch. BTW: is there a way to check that developer options are enabled? I would not dare to enable all-zero radio ID (since this well might be some other random radio), but it would be required to restore broken RT22 radios.
Since it appears to me that this radio (and its RT22 FRS cousin) has "P3207!" stored at 0x0000 and 0x0200, there couldn't there be some kind of check that when 0x01b8-0x01bd is 0x00 * 6, then the value in 0x0000-0x0006 (or 0x0200-0x0206) could be sent at 0x01b8 during the upload?
I am really glad that you have discovered this because, as I mentioned above, I have already made 2 RT22 FRS radios unusable. The factory software asks for a password now (for download and upload) and so far I have not been able to discover what it is.
Could you please check if writing the proper string at 0x1b8 would fix your radios? It does for my RT622. However my radios still worked even when radio ID was a series of 0.
-- With best wishes Dmitry R1BBD
Dmitry,
Have had a chance to look into this yet. Here's what I came up with. It works with my original RT22, RT22(FRS) and RT622(PMR) models.
Jim KC9HI
Dmitry,
On Tue, Oct 20, 2020 at 6:36 PM Dmitry Baryshkov dbaryshkov@gmail.com wrote:
I am really glad that you have discovered this because, as I mentioned above, I have already made 2 RT22 FRS radios unusable. The factory software asks for a password now (for download and upload) and so far I have not been able to discover what it is.
Could you please check if writing the proper string at 0x1b8 would fix your radios? It does for my RT622. However my radios still worked even when radio ID was a series of 0.
What I finally ended up doing was to perform a serial port capture while using the factory software to remove the password of one of my working radios. Armed with this information I created a driver just for the purpose of removing the password. Worked like a charm. Now both radios are functioning as they should.
Jim KC9HI
Dmitry,
On Sat, Nov 28, 2020 at 8:15 PM Jim Unroe rock.unroe@gmail.com wrote:
Dmitry,
On Tue, Oct 20, 2020 at 6:36 PM Dmitry Baryshkov dbaryshkov@gmail.com wrote:
I am really glad that you have discovered this because, as I mentioned above, I have already made 2 RT22 FRS radios unusable. The factory software asks for a password now (for download and upload) and so far I have not been able to discover what it is.
Could you please check if writing the proper string at 0x1b8 would fix your radios? It does for my RT622. However my radios still worked even when radio ID was a series of 0.
What I finally ended up doing was to perform a serial port capture while using the factory software to remove the password of one of my working radios. Armed with this information I created a driver just for the purpose of removing the password. Worked like a charm. Now both radios are functioning as they should.
Jim KC9HI
Here is version 2 of my proposal. This one reads the image being uploaded to determine if 0x1b8 needs patched or not. It acquires the "patch_id" and uses it to build the appropriate "patch" based on the radio that the image is being uploaded to.
I have tested this with all 3 versions of my Retevis radios (RT22 (original), RT22 (FRS) and RT622). I have "images" from other similar models (WLN KD0C1 and Zastone ZT-X6) but I don't have the physical radios for testing.
Take a look at the attached driver module. Let me know your thoughts as to how we should proceed.
Jim KC9HI
participants (2)
-
Dmitry Baryshkov -
Jim Unroe