Bug #1419

FT-60R loss of skip feature during upload and download

Added by Jason Kowalke about 5 years ago. Updated about 5 years ago.

Status:In Progress Start date:01/31/2014
Priority:Normal Due date:
Assignee:Tom Hayward % Done:

0%

Category:-
Target version:0.3.1
Chirp Version:0.3.0 Platform:Windows
Model affected:FT-60R

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.

test.img (27.9 kB) Jason Kowalke, 01/31/2014 06:48 pm

Imageforupload.img (27.9 kB) Jason Kowalke, 02/03/2014 05:09 pm

imagedownload.img (27.9 kB) Jason Kowalke, 02/03/2014 05:09 pm


Related issues

related to Bug #1557: [FT-60] The implementation of memory skip is incorrect. Closed 04/11/2014

History

Updated by Tom Hayward about 5 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 about 5 years ago

I will try to duplicate the issue tomorrow night.

Updated by Jason Kowalke about 5 years ago

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 about 5 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 about 5 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 about 5 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 about 5 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?

http://trac.chirp.danplanet.com/chirp_daily/LATEST/

Updated by Thomas Chenot about 5 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 about 5 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?

http://trac.chirp.danplanet.com/chirp_daily/LATEST/

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 about 5 years ago

Are you saying the errors introduced two weeks ago are still there, or new skip bits were flipped on your latest upload?

Also available in: Atom PDF