Bug #1187
closedError message when trying to write Yaesu FT-90
100%
Description
Hello!
I am using your software for a few days now, and it's a great piece of software - many thanks to you and all your helpers!
My problem: I tried using Chirp with a Yaesu FT-90R and I can read the data from the radio without any problems, but when I try to write data back to the radio I get the following error message:
Failed to communicate with radio: Traceback (most recent call last):
File "chirp\ft90.pyo", line 318, in sync_out
File "chirp\ft90.pyo", line 260, in _clone_out
File "serial\serialwin32.pyo", line 39, in open
SerialException: Port is already open.
I doubt it is the interface cable I use, because I have tried three different interface cables that all work fine with Yaesu VX-3, FT-60 and FT-7800...
The error occurs with todays build (20131019) as well as with last week's build (same error message, even the line numbers). I have added the complete error log in the attachment.
Best Regards & vy73 de
Willi
Files
Updated by Jens Jensen over 10 years ago
- Assignee set to Jens Jensen
Hi Willi,
Can you attach the image of your FT90 that you have successfully downloaded from your radio?
Updated by Willi Doe over 10 years ago
- File ft-90r.img ft-90r.img added
Hi Jens!
Here you are - i have just uploaded the image file ft-90r.img.
Good Luck & Many Thanks,
Willi
Updated by Jens Jensen over 10 years ago
- Status changed from New to Resolved
- Target version set to 0.4.0
- % Done changed from 0 to 100
- Estimated time set to 1.00 h
- Model affected changed from (All models) to FT-90R
- Platform changed from Windows to All
Hi Willi,
Thanks for providing the image.
There was an issue with reading channels that were not active, which should be fixed.
Please try again with the next daily build (should be out tommorow), and let me know if you are still having issues.
Updated by Willi Doe over 10 years ago
- File debug.log debug.log added
- File ft-90-20131028.img ft-90-20131028.img added
Hello Jens!
The error persists:
Failed to communicate with radio: Traceback (most recent call last):
File "chirp\ft90.pyo", line 318, in sync_out
File "chirp\ft90.pyo", line 268, in _clone_out
File "serial\serialwin32.pyo", line 39, in open
SerialException: Port is already open.
I attached both the upload file and the error log. I tried CHIRP daily-20131027.
Best Regards,
Willi
Updated by Jens Jensen over 10 years ago
Do you get the same error/result if you do the following:
- download image from the radio.
- save image to disk
- exit and reopen chirp
- open saved image from #2
- upload to radio
?
Updated by Jens Jensen over 10 years ago
Ok nevermind, fired up my dusty xp box and was able to duplicate.
For some reason, this radio refuses to go into upload (clone) receive mode unless the com port is opened.
Changing to the (very nice!) prompts broke this in a way. I'll have to take a hybrid approach: use the prompts to inform user, but still put in a delay to open port then give user a few secs to press DISP/SS before attempting to upload...
Patch submitted to list. May take a day or so for this to reach the daily builds.
Updated by Willi Doe over 10 years ago
Hello Jens!
All my apologies for my late answer to your qustion #6 - I was busy with work. I tried it out, and actually it makes no difference at all: I took the image i downloaded from the radio, which still resided on my harddisk, and tried to upload it to radio without performing any other action prior to this - same result as described in #4.
I'll try your patch from #6 asap and inform you about the result.
Many thanks for all your efforts,
Andreas
Updated by Willi Doe over 10 years ago
- File ft-90r_a.img ft-90r_a.img added
- File ft-90r_b.img ft-90r_b.img added
- File debug.log debug.log added
Hello Jens!
I can - at least partially - confirm that your bug fix works. The original problem does not occur any longer, and I can successfully write my FT-90. But now I face another problem: I have two FT-90, let's call them A and B. The original problem occurred with A, and it is solved for A, and has never been tested before with B. I last tested Chirp daily 20131031.
When I tried to write A's configuration into B, I received an error message. I have uploaded the error log. When I investigated this more deeply, I found out the following:
I can read the image from A and write it back into A, but not into B.
I can also read the image from B, but I cannot write it back, neither into B nor A.
These are the error messages - they slightly differ:
Image A uploaded to Radio A:
No error message, this works flawlessly
Image B uploaded to Radio A:
Failed to communicate with radio: Traceback (most recent call last):
File "chirp\ft90.pyo", line 316, in sync_out
File "chirp\ft90.pyo", line 296, in _clone_out
Exception: Radio did not ack block 0
Image B uploaded to radio B:
Failed to communicate with radio: Traceback (most recent call last):
File "chirp\ft90.pyo", line 316, in sync_out
File "chirp\ft90.pyo", line 296, in _clone_out
Exception: Radio did not ack block 1
Image A uploaded to Radio B:
Failed to communicate with radio: Traceback (most recent call last):
File "chirp\ft90.pyo", line 316, in sync_out
File "chirp\ft90.pyo", line 296, in _clone_out
Exception: Radio did not ack block 0
I have uploaded the two image files (they are marked with _a and _b). I also tried resetting both radios to factory defaults, but the results are the same.
This somewhat reminds me of a problem I have had with FTBVX3 and two Yaesu VX-3 years ago: Due to different country versions of the two radios, the image format was not exactly the same. The images have to be converted between different country versions prior to an upload to a VX-3 whose country version does not match that of the image version...
Is it possible that the FT-90 suffers from a similar problem? From the factory default 70cm repeater shift and direction (7,60MHz downwards) I have concluded that they are both western european models (non-uk and non-french). Diffing the two image files reveals differences, which i cannot interpret.
I also have a third FT-90, but this one is currently used in our club's station. I will get it back next Sunday so I can also test with this radio. I'll keep you informed about the results.
Best Regards, Willi
Updated by Jens Jensen over 10 years ago
Thanks Willi, this is useful information.
In all of the yaesu radios I have seen, the first few bytes are "id" bytes.
In the case of my ft-90 it is the first two bytes. In mine, these are 8F F6
In your radio A, it's 0E E4. In radio B, it's 2F E4.
In both cases, neither will upload to my radio unmodified. However, if I change just first two bytes to 8F F6, either of these files will upload (without any noticable issue) to my radio.
I do suspect, as you do this is either related to firmware revision and/or regional difference (most likely this one).
As I'm not sure if this can be handled transparently in chirp, it seems there are at least two workarounds:
One workaround would be to import from one radio to another. This should be the cleanest method, as it would only import over settings and fields that chirp is aware of.
Another idea would be to download from radio A, save image, modify ID bytes to radio B ID, open in chirp, and upload to radio. This is less ideal, as it is transplanting the memory image. If there are real differences in the data formats between the "versions" of ft-90 it could expose some issue. I doubt it, judging from my quick transplant test, however it's a risk that must be considered.
With that said, my testing and reasoning above doesn't explain why you are unable to re-upload an image you just downloaded from radio B.
I suspect there is something else going on, but without further testing, it's a mystery.
You could try working with the other radio, or other chirp users to get some images from different types of radios and correlate with model numbers, manufacture date, etc.
-Jens
Updated by Willi Doe over 10 years ago
Hi Jens!
I considered the export/import, too, but the export does not work. You run into an error message - you can try it out yourselves. Looks like a data type casting problem.
Concerning just changing the id code: I agree this might cause damage:-( But:
I have investigated this more deeply: Sources on the internet say the FT-90 can be converted from one country version to another by setting/removing solder bridges (0 Ohm resistors) on the pcb - you have to remove the bottom cover of the FT-90. After a master reset you have a different country version. When I have my third radio back on Sunday, I'll compare what solder bridges are closed and open in the three different radios. Maybe you can supply a photo of your resistors so I can compare? I need a detailed photograph of the resistors/bridges around R2156/Q2021 (have a look at this: http://www.vss.pl/mods.dk/mods.php3-radio=yaesu&model=ft-90&selectid=1168.htm). I'll keep you informed about my results.
If you can simply change the id by changing the country version, I'd assume that the rest of the data is always stored identically - or do I miss something here?
One more question: How can I see the id bytes in the downloaded image? Can I see that somewhere in Chirp, or do I have to use a hex editor?
Best Regards, Willi
Updated by Jens Jensen over 10 years ago
ok, for the import/export issue, I see a few minor problems which I'll track and fix on bug #1217
regarding my radio, I believe it's US model (FT-90R ?).
It has open/float on 21 (modded?), 22, 23, 24. Pins 25 and 26 are populated. Pin 25 has larger smd (shunt?) that is same size as 21-24 pads. Pin 26 has a smaller smd.
You can edit the hex bytes in something like wxHexEditor or HxD.
I'm submitting a patch that would expose the ID field in the developer-mode browser.
Updated by Willi Doe over 10 years ago
- File ft-90r_b_new.img ft-90r_b_new.img added
Hello Jens!
One short update: Radio B missed the resistor R2156; I've soldered in a bridge and reset the radio. Now they have the same id code 0E E4. I can now download an image from radio B and upload it to A, but I cannot write any image (neither from radio A nor B) into B. I've uploaded an image from radio B after my modification.
The error now is:
Failed to communicate with radio: Traceback (most recent call last):
File "chirp\ft90.pyo", line 316, in sync_out
File "chirp\ft90.pyo", line 296, in _clone_out
Exception: Radio did not ack block 1
BTW: The missing bridge causes an extended TX frequency range.
It seems like the first block is transmitted properly, and then the transmission fails. Question: What size do the transmission blocks have (in bytes)?
I'll try with my third radio as soon as I get hold of it. Unfortunately the club station is 55km away:-(
Best Regards, Willi
Updated by Jens Jensen over 10 years ago
Interesting. Well, in order to see what's going on, I would need to see output of debug.log with CHIRP_DEBUG environment variable turned on, i.e., (CHIRP_DEBUG=True).
I'm not on windows at the moment, so unsure what the exact steps to do so are.
Once you have that on, you should receive alot more output about the clone process (bytes sent and received, etc), which may help in diagnosing this.
the block lengths for this radio are like:
# block 03 (200 Bytes long) repeats 18 times; channel memories
_block_lengths = [ 2, 232, 24 ] + ([200] * 18 ) + [205]
Updated by Willi Doe over 10 years ago
- File debug.log debug.log added
- File ft-90r_c_20131110.img ft-90r_c_20131110.img added
Hello Jens!
I have now my third radio here (Radio C). I've tried up- and downloading, and it shows the same behaviour as radio B: You can read the radio, but writing to it fails after block 0. All stored settings of the radio are gone after the failed upload. I've uploaded both the image file and the debug log (with CHIRP_DEBUG=True).
I hope this helps...
Best Regards, Willi
Updated by Jens Jensen over 10 years ago
hi willi,
I see you radio C has id bytes of 0F E4. I would be curious to know what resistor feature matrix this corresponds to?
At this point I'm thinking it could either be a timing issue, or maybe the different versions of this radio have different block sizes during write?
As I dont have access to these radios to test, the only thing I can think of would be to suggest some diagnostic data collection activities.
I would want to see a log of the serial communication while downloading and then uploading from the oem software. As there is no alternate software, and the only thing I'm aware of for oem software (besides latest rtsystems) is an older version of rt systems ft-90 which has 15-day demo version. This is on mods.dk site, available by searching for ft90demo.exe
To capture the sequence of reading and writing:
- install free serial port monitor: http://www.serial-port-monitor.com/free-serial-port-monitor-downloads.html
- setup session to capture your com port, looking at "Request view"
- open up your programming software and perform functions: a. download from radio b. upload (same image) back to radio
- export the session log from request view of serial port monitor. (right click on request view pane, export, as htm)
Another thought is that it could simply be related to timing (i.e., chirp not giving radio enough time to ack block 1).
What platform are you on? (assuming windows). Are you able to setup a devel instance where I could give you some patches to test out?
Updated by Jens Jensen over 10 years ago
-willi,
i made a test windows build with slower timings on upload, if you want to try this and let me know if there is any difference:
https://skydrive.live.com/redir?resid=14DD1F51D490C59E!549&authkey=!AHHF8D6CgkR5iD4¶
Updated by Jens Jensen over 10 years ago
- File ft90.py added
actually, please disregard comment #16, there is an easier, faster way to test.
I noticed that it's possible to load a modified module from existing version of chirp.
steps:
download attached ft90.py
open chirp, go to:
Help -> check Enable Developer Functions
File -> Load Module, open ft90.py
Now test out downloading and then re-uploading various images.
You will also notice the "id" field has been exposed in the devel browser ui (browser tab on left, at root node)
Updated by Willi Doe over 10 years ago
Hello Jens!
Just to give you a short update: I will try this Sunday, since I'm busy with work. Can't make it earlier, unfortunately.
Did I get you correctly: You want me to try up- and downloading using the modified ft90.py, and then you need the images plus the debug.log, or is there anything else I should upload?
Best Regards, Willi
Updated by Jens Jensen over 10 years ago
yes, basically, I just wanted some feedback to see if this modification resolves your issue. It's just a pass/fail sort of thing. Only debug.log would be useful to me (with "set CHIRP_DEBUG=True" environment variable turned on).
I did also expose the ID bytes field in the devel browser UI as noted earlier. This would allow easier access to change the ID bytes to attempt cross-radio upload (e.g., change radio image A id to match B, so that you can upload radio image from A to radio B, etc)
Updated by Willi Doe over 10 years ago
Hello Jens!
I have checked the issue again: Partially, your modified ft90.py works. But now, things become complicated. I'll try to explain:
With the modified ft90.py, I can read and write radio A, as before.
With the modified ft90.py, I can read radio B, but not write to it.
With the modified ft90.py, I can read and write radio C. I cannot upload an image from radio A, but that's certainly caused by the different country codes.
I have then restarted Chirp WITHOUT loading your modified ft90.py to make absolutely sure I'm not telling bullshit, and retested with radio C:
- WITHOUT the modified ft90.py, I can read radio C, but not write to it. Same error as before. -> To me, this is a cear indication for timing problems.
I have then opened radio B and C to compare the solder bridges:
The only difference I've seen was the missing bridge at R2156 in radio C; I've soldered it in and now the radio says it has an id 0E E4, like the others have. That's somewhat strange...
After that, I've tested again with your modified ft90.py:
I can read and write radio C with its own image.
I can write an image of radio A into radio C:-) Thanks a lot!
I have then again checked radio B: I can read it, but not write to it. debug.log is attached.
I have then completely reset the radio, to make sure it doesn't have corrupted image data stored, but it's the same result as in 7.
I have compared the serial numbers: They say, radio A and C are manufactured in 1999, radio B in 2000 (according to some comment on the internet - this is not an official information). I've observed differences in the type ids of some chips in the radios. If you're interested, I might unscrew them again to tell about the differences.
I hope this helps...
Many Thanks and Best Regards, Willi
Updated by Willi Doe over 10 years ago
Hello Jens!
In the past weeks, I didn't have time to track this further. Today, I have performed a test with the latest daily build (20131211), and the situation has not changed: I can read and write my radios A and C, but radio B can only be read but not written, not even with the image from radio B...
Error log is attached.
Many thanks & best regards,
Willi
Updated by Jens Jensen over 10 years ago
Hi Willi,
I have made one last version of ft90.py which you can test given the previous method of loading this module into chirp. It has some even more relaxed timings.
If this doesn't fix it, I think I am out of options.
Unfortunately, I'm not sure what else I can do without having the radio in front of me ;)
The only other thing I would like to know is if this radio can be programmed from oem software (RT Systems).
I know of only one 15-day time-expiring demo version which is old, but still worked for my radio.
You can find it on mods.dk, and it is ft90demo.exe
It would be interesting to know if RT systems can program this radio, but I cannot with chirp, then it probably means we dont have timings just right. If you cannot program with oem/rt systems, I dont think chirp will be able to program it either.
Updated by Willi Doe over 10 years ago
Hello Jens!
Great work - Thanks a lot! With the more relaxed timing, I can read and write all three radios, and I can randomly exchange images between them without any problems.
Many thanks & vy73
Willi
Updated by Jens Jensen over 10 years ago
Thanks for the update willi, glad its working.
Can you do me a favor and check this last modification, and let me know if it is working or not. Based upon this, I'll submit a patch to chirp.
Updated by Willi Doe over 10 years ago
Hello Jens!
All my apologies for replying so late - I just didn't check this mail account for a couple of days. I've tested with your latest ft90.py: It works fine with my radios A and C, but it doesn't work at all with B: I was able to read and write A and C, and I was able to interchange memory images between them. But: I couldn't even read radio B, and I've tried to write an image from radio C into B, and both failed. Error log is included.
Do I correctly assume this is your intended result?
The ft90.py in posting #22 works perfectly fine. I've done all the tests (both modules) with daily built 20131211 for Window$, tested on a Window$ XP Home machine.
If you need further tests or more information, do not hesitate to contact me. The favour you've done to me is not comparable to this minor testing stuff I've done, so just ask for (almost) whatever you want to get tested. Please expect delayed answers during the holiday season.
Many Thanks again, and all my best wishes to you and you family for the next year,
Willi
Updated by Jens Jensen over 10 years ago
- Status changed from Resolved to Closed
Hi Willi,
The patch for the working timings have been committed to chirp daily. Please check that out.
I'm closing this ticket out.
If you find any other issues, let's work off of a new ticket.
Updated by Willi Doe over 10 years ago
Hello Jens!
I have retested with chirp daily-20131218 and I can confirm that your fix works without loading any additional modules. I can exchange data randomly between my three radios without any problems.
Many thanks again for your help.
I wish you (and all others who might read this) a Merry Christmas and a Happy New Year!
Many 73s & Best Regards,
Willi