Bug #10286
closedYaesu FT-25 Offset doubles
100%
Description
It happened both when uploading to the radio and downloading from the radio. The offset value in the software will always doubles from the real offset on the radio no matter it's plus or minus duplex. For example, If I programmed the offset -0.600 on the radio itself, it'd be shown as -1.200 on the chirp, also happened the other way around.
Worked fine using official "FT-25_EXP" software from the Yaesu sites.
Files
| chirp_debug-9sreuyr6.txt (35.8 KB) chirp_debug-9sreuyr6.txt | |||
| Yaesu_FT-25R_20230120.img (8.52 KB) Yaesu_FT-25R_20230120.img | |||
| chirp_debug-y8hhxq9_.txt (2.93 KB) chirp_debug-y8hhxq9_.txt | |||
| Screenshot (5).png (137 KB) Screenshot (5).png | |||
| 20230120_181029.jpg (1020 KB) 20230120_181029.jpg | |||
| ft4.py (51.3 KB) ft4.py | 61ff219d | ||
| 20230123_184036.jpg (1.12 MB) 20230123_184036.jpg | |||
| Yaesu_FT-25R_20230123.img (8.52 KB) Yaesu_FT-25R_20230123.img | |||
| Yaesu_FT-25E_20230123.img (8.52 KB) Yaesu_FT-25E_20230123.img | |||
| FT-25E.png (42.2 KB) FT-25E.png | |||
| FT-25R.png (42.5 KB) FT-25R.png | |||
| (FT-25E) chirp_debug-62akz8qi.txt (3.86 KB) (FT-25E) chirp_debug-62akz8qi.txt | |||
| (FT-25R) chirp_debug-jvzd7rpy.txt (3.84 KB) (FT-25R) chirp_debug-jvzd7rpy.txt | |||
| ft4.py (52.5 KB) ft4.py | |||
| ft4.py (52.7 KB) ft4.py | 13b4782f |
.png){kind=link}
Updated by Pichayut Sombat almost 2 years ago
- File chirp_debug-9sreuyr6.txt chirp_debug-9sreuyr6.txt added
Updated by Dan Smith almost 2 years ago
Perhaps Dan or Bernhard can figure this out. It looks like there's definitely some frequency multiplier stuff in the code.
It would help if you would attach a .img file of your radio and call out specifically which memories are affected, and how they appear on the radio.
Also, please confirm that this reproduces on chirp-next as any fixes are going to have to happen against that version (you reported this against daily).
Updated by Pichayut Sombat almost 2 years ago
- File chirp_debug-y8hhxq9_.txt chirp_debug-y8hhxq9_.txt added
- File Yaesu_FT-25R_20230120.img Yaesu_FT-25R_20230120.img added
- File Screenshot (5).png Screenshot (5).png added
I now switched to the next version, the error still occurs. I'm not sure if this is relevant but there might be multiple version of FT-25, I've seen 2 of the official software version, EXP and US_EU. And the chirp's debugs also raised the ID suspect warning in this case. Maybe it'd be a good idea to have another radio tested after the fixes, my radio was bought in Thailand(afaik it's locally advertised and sold as FT-25R/E), I'm not sure if the USA EU or Exported version would be affected.
Thanks for the fast response!
Updated by Pichayut Sombat almost 2 years ago
- File 20230120_181029.jpg 20230120_181029.jpg added
I forgot to specify. On the latest img it's on memory 4. It showed -0.600 on the radio's settings but -1.200 on Chirp
Updated by Pichayut Sombat almost 2 years ago
Seems to occur on it's brbother too, FT-65. (Bug #9713)
Updated by Dan Smith almost 2 years ago
Are you using the FT-25R but actually have an FT-25E? Also is your FT-65 branded as an E model?
I'm surprised that the US/EU versions would differ in how they store their offsets like this, but I suppose it's possible.
Updated by Dan Smith almost 2 years ago
- Related to Bug #9713: Chirp reads Yaesu FT65R saved offset different value added
Updated by Dan Smith almost 2 years ago
Can you try the attached module? Enable developer mode with Help->Enable Developer Mode, then restart, File->Load Module and choose this file.
Please check with your FT-25 and FT-65 by selecting the E variant when you download. Old images will still open as the R variant, so you should download fresh.
Please test VHF and UHF frequencies in as many permutations as you can think of, and also attach a debug log here of the download from each please.
Updated by Dan Smith almost 2 years ago
- Status changed from New to Feedback
- Chirp Version changed from daily to next (py3)
Updated by Pichayut Sombat almost 2 years ago
- File 20230123_184036.jpg 20230123_184036.jpg added
Sorry for the confusion, actually, I only have one which I just noticed that it's stated on the back plate as FT-25R (monoband VHF version since UHF is kinda not allowed in Thailand). The FT-65(R) I've mentioned are from the other issue (#9713) which is not mine. I'll upload the results soon.
Updated by Pichayut Sombat almost 2 years ago
- File Yaesu_FT-25E_20230123.img Yaesu_FT-25E_20230123.img added
- File Yaesu_FT-25R_20230123.img Yaesu_FT-25R_20230123.img added
- File FT-25E.png FT-25E.png added
- File FT-25R.png FT-25R.png added
- File (FT-25E) chirp_debug-62akz8qi.txt (FT-25E) chirp_debug-62akz8qi.txt added
- File (FT-25R) chirp_debug-jvzd7rpy.txt (FT-25R) chirp_debug-jvzd7rpy.txt added
Here are the results. I've saved the memory directly on the radio itself on memory 3, 145.6750 with -0.6000 offset. On the CHIRP (latest next with ft4.py module loaded), selecting FT-25E reads the offset correctly as -0.6000 but using FT-25R Model still reads it wrong as -1.2000.
Updated by Bernhard Hailer almost 2 years ago
- Assignee set to Bernhard Hailer
I'll have a look, but please allow some time.
Indeed, there are some multipliers at work, and they differ from model to model (FT-25 vs. FT-65), and apparently from regions to regions (R vs. E), too. I developed using an R model, so I'm a bit surprised that this fails.
Thanks for the helpful files!
Updated by Steven Hiscocks almost 2 years ago
I just tested the offsets on my FT-65E and didn't have any issues. Value matched between radio and CHIRP. Tested with CHIRP next-20230126.
Updated by Bernhard Hailer almost 2 years ago
- % Done changed from 0 to 20
Started to work on this. Sorry, be patient, I need to get up to speed with Chirp-next.
I have an FT.25R for testing.
Updated by Bernhard Hailer almost 2 years ago
- % Done changed from 20 to 30
- Platform changed from Windows to Linux
Got Chirp-next running after installing Linux Mint from scratch and cloning repository. Getting there.
Updated by Bernhard Hailer almost 2 years ago
- % Done changed from 30 to 40
Ok, so I tested this with my FT-25R, which I bought in the US. It looks exactly like yours. "FT-25" on the front, "FT-25R" under the battery.
When I program it with an offset of +0.6 MHz, it works correctly...
The interesting thing is that there is a multiplier in the code. The multipliers for FT-25/65 and FT-4 are different, with the one for the FT-25/65 being twice the value of the one for the FT-4 (50 vs. 25 kHz). Looking into this ticket, and also #9713, I'm beginning to suspect that the multipliers are applied using some mechanism we haven't caught on yet.
I did some digging, and based on some of your input, I came to this conclusion:
I now switched to the next version, the error still occurs. I'm not sure if this is relevant but there might be multiple version of FT-25, I've seen 2 of the official software version, EXP and US_EU. And the chirp's debugs also raised the ID suspect warning in this case. Maybe it'd be a good idea to have another radio tested after the fixes, my radio was bought in Thailand(afaik it's locally advertised and sold as FT-25R/E), I'm not sure if the USA EU or Exported version would be affected.
I think this might be the key, actually. Can you try the US_EU OEM software version? If that one fails as well, then we have the solution: Export versions come with a modified multiplier, and I need to add a sub driver.
I'm somewhat confused, because you added two images: one for an FT-25R, the other for an FT-25E. I assume it's your FT-25R radio, but the OEM software has two selections? The images are practically identical.
Updated by Pichayut Sombat almost 2 years ago
Ok, so I tested this with my FT-25R, which I bought in the US. It looks exactly like yours. "FT-25" on the front, "FT-25R" under the battery.
When I program it with an offset of +0.6 MHz, it works correctly...
I always wondered if this problems occured since CHIRP supports it and not a single issues mentioned it (until I've found one but with FT-65 #9713). Now I only hope it's not just my supplier or unit's fault from the factory.
I'm somewhat confused, because you added two images: one for an FT-25R, the other for an FT-25E. I assume it's your FT-25R radio, but the OEM software has two selections? The images are practically identical.
To clarify, I use the file name according to the selected version in the softawre I've useed to download from the radio. Both 'FT-25R' and 'FT-25E' files are the images downloaded from my only radio (FT-25R , the onne I've shown in the previous reply) which I programmed the frequency and offset directly using keypad on it. I was thinking it may be useful because one raised an ID error which may be relevant to the problem.
I think this might be the key, actually. Can you try the US_EU OEM software version? If that one fails as well, then we have the solution: Export versions come with a modified multiplier, and I need to add a sub driver.
Yeah, I have both US_EU and EXP version of software but from my experiences recently, none of them raised an error both reading or writing with my 'FT-25R' radio which is surprising. But I will try it again and will report in later. So I should try uploading to the radio using different OEM software versions and read it with CHIRP is that correct? Do I need try with the latest next build or with that old modified module one from Dan?
Thanks for still following up on this, lately I have some exam and studies to take so I may reply a lot slower, but I will try to do the best I could on the issue!
Updated by Bernhard Hailer almost 2 years ago
Thank you, this is very helpful! Based on your description, I think there's probably a flag in the radio which defines the scaler in use. There are a few bytes in the radio's memory of which we don't know what they do. I will compare your image with mine and find out.
Meanwhile, yes, you should try uploading to the radio using different OEM software versions and read it with CHIRP. Thanks!
Updated by Bernhard Hailer almost 2 years ago
That flag apparently comes with the radio ID. An FT-25 identifies with "IFT-15R\0\0V100\v0\v0". The last byte is 0x00 indeed for me, but for you it's 0x03. So here may be the solution. I'll try to get more information about the European version of this radio; perhaps it gives me some insight for building a matrix.
Updated by Bernhard Hailer almost 2 years ago
Attached is a modified driver. You can test as follows:
- Open Chirp software.
- In Help, checkmark "Developer mode".
- End and restart Chirp.
- In File menu, select "Load module" and load the attached file.
- Test.
Please check:
- whether the offsets are coming out correctly,
- and whether there's no ID warning anymore in the debug log. Please share your observations and the debug log. Thanks!
Updated by Dan Smith almost 2 years ago
- File ft4.py added
Here's another driver to test. I'm fixing one thing for Bernhard but I don't have a radio to test with so if I could get a confirmation from one of the other people here, I'd appreciate it.
See LoadingTestModules for procedure to load this into your CHIRP.
Updated by Anonymous almost 2 years ago
- Status changed from Feedback to Closed
- % Done changed from 40 to 100
Applied in changeset github|ab0d759426ede5209b436bc24967fb3579960abe.