Bug #1419
closedFT-60R loss of skip feature during upload and download
Added by Jason Kowalke almost 11 years ago. Updated over 4 years ago.
0%
Description
During upload and download from the radio the setting for off, skip, or only gets lost. Re-installed the latest stable version and downloaded and uploaded from the radio changing only one option. Still changed random settings on this.
Files
test.img (27.9 KB) test.img | Jason Kowalke, 01/31/2014 06:48 PM | ||
Imageforupload.img (27.9 KB) Imageforupload.img | Jason Kowalke, 02/03/2014 05:09 PM | ||
imagedownload.img (27.9 KB) imagedownload.img | Jason Kowalke, 02/03/2014 05:09 PM |
Updated by Tom Hayward almost 11 years ago
- Status changed from New to Feedback
I can't reproduce this. Can you please post step-by-step instructions for how to reproduce? Include an img from before and an img from after and tell me for which channels the skip was lost.
Updated by Jason Kowalke almost 11 years ago
I will try to duplicate the issue tomorrow night.
Updated by Jason Kowalke almost 11 years ago
- File Imageforupload.img Imageforupload.img added
- File imagedownload.img imagedownload.img added
Here is the image file I will upload flowed by the image downloaded. If it can't be duplicated on your end, I may have to check for issues with my RT cable.
Updated by Jason Kowalke almost 11 years ago
Step by Step is simple. I downloaded the image from the radio. Changed the skip settings, saved, and uploaded. The radio shows some differences and then when downloaded some of the settings are different in the image. I made no alterations to: imagedownload.img That's how it came out of the radio.
Updated by Tom Hayward almost 11 years ago
I meant specifically, like which memory number has wrong skip and which setting was affected. This tells me where to look in your img.
Have you tried downloading and then uploading without making any changes? Obviously this should not introduce any changes. If it does, it's likely a cable issue like you suggest. Yaesu uses a very primitive checksum that can easily result in a false positive.
Updated by Jason Kowalke almost 11 years ago
I did do as you asked without changes and it does in fact change things. This did not happen with an older version. I suppose it may be the cable. But as you requested: There are many channels affected in the radio. If we look at imagedownload.img we will find that 8, 99, 300, 301, 424, 708 have changed all by themselves. If you need me to download from the radio, upload to the radio and see if the radio itself exhibits changes I can do so. I believe the cable to be a RT systems cable.
Updated by Tom Hayward almost 11 years ago
- Status changed from Feedback to In Progress
- Assignee set to Tom Hayward
I took at look at your img files and I find it very conspicuous that the only flipped bits are in the skip data section. This seems to disprove my bad cable theory (a bad cable would randomly disperse errors throughout the entire img).
You say it did not happen in an older version. Which two version are you comparing? All of this information is very helpful for tracking down when the bad code (if any) was introduced.
Can you confirm the problem is present in the current code?
Updated by Thomas Chenot almost 11 years ago
I'm seeing the skip issue with my FT-60. Chirp v0.3.1
I dumped the chirp image file that I uploaded after setting the skip in the GUI and the one that I downloaded after manually programming the skip on the radio. It looks like the skip flags are shifted when comparing the upload file with the download file.
I had programmed locations 1..7 and set SKIP to 'S' on channels 6 and 7. This corresponded to a value of 0x0a at file offset 0x6EC9. The radio did not skip locations 6 or 7 after upload.
I then manually programmed skip for locations 6 and 7 on the radio. I downloaded the working skip configuration back to chirp. The value at offset 0x6EC9 now contains 0x16. In addition, the GUI displayed 'P' for locations 5 and 6 and 'S' for location 7 (recall that the original upload settings were 'S' for locations 6 and 7).
Chirp generated skip values
00006ec0 00 00 00 00 00 00 00 00 00 0a 00 00 00 00 00 00 |................|
Skip programmed on radio, downloaded to chirp
00006ec0 00 00 00 00 00 00 00 00 00 16 00 00 00 00 00 00 |................|
Notes:
- I focused on addresses near 0x6eC8 after looking at "flags" address in FT60.py
- I see that three bits are set after manually programming the radio (when only two skip locations were programmed)... I'm assuming the extra bit came from the original upload from chirp.
Updated by Jason Kowalke over 10 years ago
Tom Hayward wrote:
I took at look at your img files and I find it very conspicuous that the only flipped bits are in the skip data section. This seems to disprove my bad cable theory (a bad cable would randomly disperse errors throughout the entire img).
You say it did not happen in an older version. Which two version are you comparing? All of this information is very helpful for tracking down when the bad code (if any) was introduced.
Can you confirm the problem is present in the current code?
Sorry About the delay. I downloaded the daily 20140222
I Downloaded from the radio, Saved the img file, Changed the file to reflect some changes and saved it. When I uploaded The problem still existed in the radio.
What would you like me to do?
Updated by Tom Hayward over 10 years ago
Are you saying the errors introduced two weeks ago are still there, or new skip bits were flipped on your latest upload?
Updated by Bernhard Hailer over 4 years ago
- Status changed from In Progress to Closed
- Target version changed from 0.3.1 to chirp-legacy
- Chirp Version changed from 0.3.0 to daily
- Model affected changed from FT-60R to Yaesu FT-60R
No more feedback on this ticket. Please re-open if it's still an issue.