Bug #10915
closedUnsupported RT-470X firmware version V2.10A
100%
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
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
- File RT-470X v2 Menu List (00-57).txt RT-470X v2 Menu List (00-57).txt added
- File photo_2023-10-28_21-50-37.jpg photo_2023-10-28_21-50-37.jpg added
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.
Updated by Marcos Vives about 1 year ago
- File RT-470X v2 Menu List (00-57) (corrected).txt RT-470X v2 Menu List (00-57) (corrected).txt added
I hadn't saved the file before attaching it. My bad. Here is the correct one.
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.
Updated by Marcos Vives about 1 year ago
- File offsets.txt offsets.txt added
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.
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
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.
Updated by Jim Unroe about 1 year ago
- File mml_jc8810_rt470x-v2.py mml_jc8810_rt470x-v2.py added
Here is the replacement file. Let me know how it goes.
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.
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
- File RT-470X_BCL_memory_properties.png RT-470X_BCL_memory_properties.png added
- File RT-470X_BCL_spreadsheet.png RT-470X_BCL_spreadsheet.png added
- File mml_jc8810_rt470x-v2.1.py mml_jc8810_rt470x-v2.1.py added
- I read the instructions above set to Yes
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.
Updated by Mikael Eriksson about 1 year ago
- File RT-470X_BCL_Setting.png RT-470X_BCL_Setting.png added
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.
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.
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.
Updated by Anonymous 12 months ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|468da8c304608d8162cd6d8a868b23433d4929fc.