CHIRP

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.

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.

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

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.

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

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

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.

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.

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.

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.

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.

Applied in changeset github|468da8c304608d8162cd6d8a868b23433d4929fc.