Project

General

Profile

Actions

Bug #10915

closed

Unsupported RT-470X firmware version V2.10A

Added by Marcos Vives about 1 year ago. Updated 12 months ago.

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

100%

Estimated time:
Chirp Version:
next
Model affected:
RT-470X
Platform:
Windows
I read the instructions above:
Yes

Description

This handheld came from factory with this version, and it seems it has some minor differences that prevents being used as is currently in CHIRP.

So far, I have identified at least the following changes:

  • The identification code is now "00 00 00 2c 00 20 d8 04"
  • DTMF codes have been extended from 5 to 7 digits (see offset 0xA020 where the DTMF is "2020202")
  • The PTT ID option is now at 0x900B (found by diffing "factory.img" with "factory_pttboth.img"). 0xA006 (as in the other radios) is used for something else, and altering it seems to cause the radio to transmit "123" on end-of-transmission instead of the correct code (???).

The official RT-470X programming tools seems to be unaware of these changes in the v2 firmware, and uses the v1 layout regardless, causing the DTMF lengths to be limited and corruption in the 0xA006 which causes also the aforementioned issue with DTMF 123.

Attached are two files:

  • "factory.img": image dumped from a reset device
  • "factory_pttboth.img": reset device, but the PTT ID mode has been changed from OFF to BOTH. No other changes.

Files

factory.img (44.9 KB) factory.img Marcos Vives, 10/25/2023 05:35 PM
factory_pttboth.img (44.9 KB) factory_pttboth.img Marcos Vives, 10/25/2023 05:35 PM
photo_2023-10-26_02-27-56.jpg (85.9 KB) photo_2023-10-26_02-27-56.jpg Marcos Vives, 10/25/2023 05:36 PM
photo_2023-10-26_02-27-57.jpg (151 KB) photo_2023-10-26_02-27-57.jpg Marcos Vives, 10/25/2023 05:36 PM
RT-470X Menu List (00-56).txt (3.48 KB) RT-470X Menu List (00-56).txt Jim Unroe, 10/26/2023 11:29 AM
RT-470X v2 Menu List (00-57).txt (3.48 KB) RT-470X v2 Menu List (00-57).txt Marcos Vives, 10/28/2023 12:52 PM
photo_2023-10-28_21-50-37.jpg (62.5 KB) photo_2023-10-28_21-50-37.jpg Marcos Vives, 10/28/2023 12:53 PM
RT-470X v2 Menu List (00-57) (corrected).txt (3.52 KB) RT-470X v2 Menu List (00-57) (corrected).txt Marcos Vives, 10/28/2023 01:39 PM
offsets.txt (2.28 KB) offsets.txt Marcos Vives, 10/30/2023 04:22 PM
mml_jc8810_rt470x-v2.py (48.4 KB) mml_jc8810_rt470x-v2.py Jim Unroe, 10/30/2023 06:53 PM
photo_2023-11-06_12-00-20.jpg (168 KB) photo_2023-11-06_12-00-20.jpg Marcos Vives, 11/06/2023 03:00 AM
RT-470X_BCL_memory_properties.png (59.8 KB) RT-470X_BCL_memory_properties.png Jim Unroe, 11/07/2023 07:10 PM
RT-470X_BCL_spreadsheet.png (42.9 KB) RT-470X_BCL_spreadsheet.png Jim Unroe, 11/07/2023 07:11 PM
mml_jc8810_rt470x-v2.1.py (48.9 KB) mml_jc8810_rt470x-v2.1.py Jim Unroe, 11/07/2023 07:11 PM
RT-470X_BCL_Setting.png (62.4 KB) RT-470X_BCL_Setting.png Mikael Eriksson, 11/08/2023 01:58 PM
Radtel_RT-470X_20231111.img (44.9 KB) Radtel_RT-470X_20231111.img Marcos Vives, 11/11/2023 01:26 PM
mml_jc8810_rt470x-v2.2.py (48.9 KB) mml_jc8810_rt470x-v2.2.py Jim Unroe, 11/11/2023 04:32 PM
Actions #1

Updated by Jim Unroe about 1 year ago

It would seem from the Radtel website, that the RT-470, RT-470L and RT470X have new circuit boards requiring the V2 firmware. I would expect it to be possible for me to use the V2 software in my "V1" radios to develop support.

I made the mistake early on by trying to doing the initial development by using the factory software and quickly learned that was not intended to be used for these radios. It just happened to work for reading their radios so they made it available.

Development for this "NEW PCB" model really should be done by someone in possession of the actual hardware. Since this seems to involve many models (it likely affects the Anysecu, Hiroyasu and Talkpod variants, too), I most likely won't be able to purchase them with my own funds. My initial RT470 was donated by a Radtel representative. Later here offered so send me an RT-470X for development. I accepted but one was never sent. I got no response from by followup emails so I don't know what happened.

It isn't easy to develop for a radio that I don't have in my possession, but it is not impossible. I was successful in getting the Talkpod A36Plus supported with help from a pair of volunteers.

I would see someone edit the attached list to correspond to the menu in their Radtel RT-470X V2 in order to get a feel for what else may have changed. Once I get a chance to look that over, I can them make requests for additional help from volunteers.

Updated by Marcos Vives about 1 year ago

Many defaults have been changed, but no new values have been seemingly added to existing menu options.

They have added a new menu option to edit the ANI NAME, which opens a T9 text input to edit the name associated with the ANI set on option 33.

Values for option 9 have mostly garbled names on reset. I am unsure if they are being reset to these garbled values, or if they are not being properly reset.

Actions #3

Updated by Marcos Vives about 1 year ago

I hadn't saved the file before attaching it. My bad. Here is the correct one.

Actions #4

Updated by Jim Unroe about 1 year ago

Marcos Vives wrote in #note-3:

I hadn't saved the file before attaching it. My bad. Here is the correct one.

I've lost count of how many times I done this.

I believe the next thing that needs to happen is to determine the full list of settings have been moved around in memory. You already mentioned a few when you opened the ticket. What I have been doing go through the radio's menu and setting all of the 'global' settings to the next-to-last value. Then I download the changed into CHIRP and see if any do not match. The ones that don't match must have been move so I then make images to diff the locations with.

Actions #5

Updated by Marcos Vives about 1 year ago

Attached the offsets I've found so far analyzing the diffs between multiple (circa 80) memory dumps.

Seems only the DTMF code has been moved, which is odd. Can someone confirm if a pre-v2 firmware really writes to the 0xA006 address and not 0x900B? The official tool does write to 0xA006, but that might be a bug in the tool.

Actions #6

Updated by Jim Unroe about 1 year ago

  • File mml_jc8810_rt470x-v2.py added

Outstanding job. I checked my RT-470X and DTMF CODE is indeed at 0x900B. I'll bet that this was diffed from the factory CPS for the RT-470. I will have to check on my other radios to see if the same is true for them. I'll bet that they are all wrong and the setting just needs to be moved. Makes me suspect the DTMF (on) and DTMF (off) settings as well. For testing, I am going to move the DTMF CODE setting. This will allow me to quickly test my other variant radios (RT-470L, etc).

I think at this point in time, what you have provided shows that most everything lines up well enough with the V1 model that I think it should be safe to add the 'fingerprint' to the existing RT-470X allowing the V2 radio to be programmed with current CHIRP setting. Then you will be able to run through the settings to verify which ones will still (if any) need attention. I have attached the test driver module with the added 'fingerprint' and change to DTMF CODE.

Instructions for LoadingTestModules

Actions #7

Updated by Jim Unroe about 1 year ago

  • File deleted (mml_jc8810_rt470x-v2.py)
Actions #8

Updated by Jim Unroe about 1 year ago

I deleted the file because I found a bug. I will replace it once I have fixed it.

Actions #9

Updated by Jim Unroe about 1 year ago

Here is the replacement file. Let me know how it goes.

Actions #10

Updated by Marcos Vives about 1 year ago

Can confirm that Python file works! I've tried changing every setting and could see it change on the handheld as well.

The only setting that did not match properly CHIRP were the "squelch tail eliminate (repeater)" and "ste repeater delay", where values in the RT-470X are 10x the values displayed on CHIRP (ie "200 ms" set "2 second" on the RT-470X). I am not sure if that's a bug on the handheld display or what - a multi-second squelch tail elimination seems absurdly long.

Actions #11

Updated by Mikael Eriksson about 1 year ago

I've tested mml_jc8810_rt470x-v2.py with version 2.12A of the firmware and it works both to read and write. The only parts that are missing is the "Tail code"and BCL ( Busy Channel Lock) settings.

I've compared with the official application (Radtel RT-470X Programming Software v1.0.3.2) by reading and writing back and forth and the values corresponds.

Regarding the "squelch tail eliminate (repeater)" and "ste repeater delay" times, I believe it is an error in the HT:s display of the values. It has the same behaviour as the official application.

Updated by Jim Unroe about 1 year ago

Mikael Eriksson wrote in #note-11:

I've tested mml_jc8810_rt470x-v2.py with version 2.12A of the firmware and it works both to read and write. The only parts that are missing is the "Tail code"and BCL ( Busy Channel Lock) settings.

I've compared with the official application (Radtel RT-470X Programming Software v1.0.3.2) by reading and writing back and forth and the values corresponds.

Regarding the "squelch tail eliminate (repeater)" and "ste repeater delay" times, I believe it is an error in the HT:s display of the values. It has the same behaviour as the official application.

Good catch on the 'Tail code'. That has always been a missing setting on the RT-470X. BCL is a per-channel setting. It has always been available in the memory properties editor or the spreadsheet style memory editor when 'Show extra fields' is enabled (see attached screen captures).

The attached test driver module adds the missing 'Tail code' setting and adds code that allows CHIRP to determine if the radio has the original PCB (printed circuit board) or has PCBv2.

Actions #13

Updated by Mikael Eriksson about 1 year ago

Tested the tail code and it works like charm. Thanks!
The BCL I'm talking about is not in the channel data but in the settings data. See the attached picture. BUT here comes the interesting part.
When I looked into the source code of the official application, it seems like the checkbox never gets written to the radio, but another variable gets written instead. When it read it back to the application it is read into another variable that is connected to the user interface.

The memory it writes to is "unknown_900f":
pttlt:3; // PTT Delay
u8 unused_900d:6, // 900D
mdfa:2; // Channel_A Display
u8 unused_9003:6, // 900E
mdfb:2; // Channel_B Display
u8 unknown_900f; // 900F
u8 unused_9010:4, // 9010
autolk:4; // Key Auto Lock

The codes that writes look like this:
cHImfStrToHex[12] = (byte)this.theRadioData.funCfgData.CbB_SendIDDelay;
cHImfStrToHex[13] = (byte)this.theRadioData.funCfgData.CbB_CH_A_DisplayMode;
cHImfStrToHex[14] = (byte)this.theRadioData.funCfgData.CbB_CH_B_DisplayMode;
cHImfStrToHex[15] = (byte)this.theRadioData.funCfgData.CbB_BusyLock;
cHImfStrToHex[16] = (byte)this.theRadioData.funCfgData.CbB_AutoKeyLock;

The code that reads look like this:
theRadioData.funCfgData.CbB_SendIDDelay = (dat[12] & 15) % 7;
theRadioData.funCfgData.CbB_CH_A_DisplayMode = (dat[13] & 15) % 3;
theRadioData.funCfgData.CbB_CH_B_DisplayMode = (dat[14] & 15) % 3;
if (dat[15] <= 0)
{
theRadioData.funCfgData.CB_StopSendOnBusy = false;
}
else
{
theRadioData.funCfgData.CB_StopSendOnBusy = true;
}

So to summarize the variable is called BCL in the user interface, BusyLock when it gets written and StopSendOnBusy when it gets read.

Actions #14

Updated by Marcos Vives about 1 year ago

With that v2.1 I am getting "list index out of range" on all programmed channels that are empty. I can manually enter values, but copying from another saved list (like those at File -> Open Stock Config) would not work.

Attached is the saved file, in case it is relevant. Firmware is v2.11 and have been fully reset to factory, aside from a couple programmed channels I put.

Actions #15

Updated by Jim Unroe about 1 year ago

Marcos Vives wrote in #note-14:

With that v2.1 I am getting "list index out of range" on all programmed channels that are empty. I can manually enter values, but copying from another saved list (like those at File -> Open Stock Config) would not work.

Attached is the saved file, in case it is relevant. Firmware is v2.11 and have been fully reset to factory, aside from a couple programmed channels I put.

There was a recent change made to CHIRP that broke the test driver. This one has been updated meet the new requirements and should now work.

Actions #16

Updated by Anonymous 12 months ago

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

Also available in: Atom PDF