CHIRP

I have the same issue.

I have the same issue using 4.1 for windows.

I bet this is a regression from #739

Seeing the same issue on windows with daily build 20150814. Suspect this may be a address alignment issue as right side band assignments are successfully retrievable from the radio and report correctly in the right band tab. But are not recognized by the radio, so Chirp is pushing and pulling from the same config memory location.

However manual memory and band assignments on the right side are not downloading with band information on pulls from the radio. I would take a guess that the band info is not being placed where the radio is looking for it but it is being stored and is retrievable.

Still no joy in programming the right side memory bank on windows with CHIRP daily-20170420. It did successfully upload the memory assignments which was helpful.
Further work seems to be needed with the right side memory bank.

I have the same problem:
Mac OSX 10.11.6
Chirp build: daily-20170501
Yaesu ft-8800r

If I download from the radio, the right-side bank shows banks checked in the data that's downloaded. However, it shows a lot more banks checked than I have manually set in the radio. It seems to show the values as in a previous file I had used even though it was supposedly downloaded from the radio (?)
When I upload to the radio, it doesn't matter what I have set in Chirp for the right-side bank, the result of the upload is NO banks are set on the right set. This is easy to reproduce: Manually set some memories on the right side to a bank or two, download a new file from the radio, then upload that same file. All banks on right side of the radio are erased.

This is the only problem I have ever had with any Chirp version across all my radios. Is there an older version where this bug is not present? I'll happily use an older version and just stick with it since everything else works.

Update to my previous post

I updated to Chirp build "daily_20170510" (i.e., May 10th vs. May 1st) and here are the differences I noticed:

• Whatever I put in the screen for the RIGHT bank gets uploaded to the radio in the LEFT bank
• Adding/changing memory bank settings on the "Left Bank" tab in the application apparently has no effect on the radio when uploaded.
• When I download from the radio, the application shows all memory channels assigned to a bank for the right side (as I had previously set and uploaded), but they are not set that way in the radio after upload. There were only a few banks manually set on the right side and only those should be displayed (as opposed to a bunch more)
• The right bank is not completely erased upon upload to the radio (as with previous version of Chirp). However, the only memory banks preserved on the right side are those that were set when the file was downloaded from the radio.
• If I manually program new memory bank settings on the right side, these are erased when uploading to the radio (as I supposed they should be) except what's on the screen is not uploaded
• The memory banks that were manually programmed on the right side ARE downloaded from the radio but are not properly displayed. I know this because if I make changes manually to the right bank, then upload the file I just downloaded, the banks on the right side are reset to what they were before I downloaded the file. In other words, "somewhere", those bank settings are recorded in the application because if I upload a specific file to the radio, the right bank settings AS OF THE TIME THAT FILE WAS DOWNLOADED, are set in the radio when uploading that file. Example (all right-side banks): Say Repeater 1 is set to bank 1, repeater 2 is set to bank 2, and repeater 3 is set to bank 3 Download from the radio Display shows a lot more memory channels than those three are set to various banks Manually add Repeater 4 to bank 4 using the radio Upload that file I just downloaded, and repeater 4 will not be set (this is actually correct because I just overwrote my manually-set bank with the file from Chirp) But - no matter how I change the settings for the right bank in Chirp (using either Left Bank tab or Right Bank tab), when I upload, only repeaters 1, 2, and 3 will be set to banks 1, 2, and 3 just like they were when I downloaded the file.

Sorry to be long-winded, hope this helps - ask if you need clarification.

I know the 8800 is not a new rig, but any chance this could be looked it and possibly resolved?

Same issue with the right side memory bank. :(

I also have this bug, but I believe that I have found the source of the problem!

Since it seems to be specific to this radio (FT-8800), I looked in the driver file that defines the FT-8800 interface (ft7800.py) and started searching for "8800" to find the definitions. The following snippet begins at line 921 of the current version of ft7800.py:

class FT8800RadioLeft(FT8800Radio):
"""Yaesu FT-8800 Left VFO subdevice"""
VARIANT = "Left"
_memstart = 0x0948
_bankstart = 0x4BC8

class FT8800RadioRight(FT8800Radio):
"""Yaesu FT-8800 Right VFO subdevice"""
VARIANT = "Right"
_memstart = 0x2948
_bankstart = 0x4BC8

Note that, while FT8800RadioRight and FT8800RadioLeft have different values for memstart (0x0948 & 0x2948), they have the exact same value for _bankstart: 0x4BC8.

Since left-side bank programming works, I think it is safe to assume that 0x4BC8 is the correct starting address for the left memory banks. I strongly suspect that if we the right side bankstart address to the correct address everything will just work.

So, the only question left is "what is the correct value for bankstart for FT8800RadioRight"?

Chris Parker wrote:

Since left-side bank programming works, I think it is safe to assume that 0x4BC8 is the correct starting address for the left memory banks. I strongly suspect that if we the right side bankstart address to the correct address everything will just work.

So, the only question left is "what is the correct value for bankstart for FT8800RadioRight"?

I've been doing a little more sleuthing on this. I made a simple image for my radio that puts the 144.110 in channel 1, 144.120 into channel 2, etc. up to 144.200 in channel 10 for both the left and right side radios. I also put channel 1 in bank 1, channel 2 in bank 2, etc. up to channel 10 in bank 10 for both left and right side radios. I then uploaded this to the radio. Of course, only the left side bank programming worked. Using the radio's panel controls, I also added the right side memory locations to banks 1-10 just like the left side. I then read this out of the radio using CHIRP, and have been reading the image file with a hex editor (ghex under linux).

Here is what I have found (some of this will be well-known by the dev team, but I am posting it here to help others who might want to work on this):
1) each regular memory channel uses 16 bytes of storage. Looking at it in a hex editor it is really easy to see your stored frequencies (they are in BCD).
2) Between the end of the right side regular memory and the beginning of left side bank assignments are 640 bytes. 20 left side PMS memories (L1, U1, L2, U2, ..., U10) + 20 right side PMS memories at 16 bytes per memory is 640 bytes, so my guess is that from 0x4948 to 0x4A87 are the left side PMS memories and from 0x4A88 to 0x4BC7 are the right side PMS memories.
3) Since we know that 0x4BC8 works as the starting point for the left side bank storage, we know that comes next, but bank storage is weird. It looks like banks are stored as flags in two bytes, using the high 10 bits of each the 2-byte pair to denote which bank a channel is in. However, channels do not appear to be stored in order. The bytes at 0x4BC9:0x4BC8 are 0x0080, (presumably marking left memory channel 1 as being in bank 1), but everything is 0x00 until 0x4C09:0x4C08, which is 0x0040 (presumably marking channel 2 as being in bank 2?). This suggests that memory channel bank assignments don't appear in consecutive 2-byte words but are interleaved somehow.
4) Nonetheless, assuming that we store all 512 left-side bank assignments in a contiguous block before beginning the right-side bank assignments (which would follow the pattern in the rest of the memory space), 512 bytes x 2 = 1024 bytes = 0x400 bytes, and 0x4BC8 + 0x0400 = 0x4FC8. I suspect that if we change the FT8800RadioRight._bankstart to 0x4FC8 right-side bank assignments will start working.
5) Even though I manually assigned the right-side channels to a memory banks, I cannot see a repetition of the data from 0x4BC8 later on in the memory (especially from 0x4FC8 to 0x53C7).

I am willing to try changing the value of FT8800RadioRight._bankstart to 0x4FC8 in ft7800.py, but I don't want to brick my radio in the process. Can anyone else verify any of what I have said above?

Correction to my last post on this. The correct number for FT8800RadioRight._bankstart should be 0x4E48.

Banks are not so weird after all. The first 64 bytes starting at 0x4BC8 use single bit flags to mark each left memory channel that is in bank 1 (512 memories / 8 bits per byte = 64 bytes). The next 64 bytes (starting with 0x4C08) do the same for bank 2, and so on. A quirk is that within the bytes the order is backwards from bit order. So, in the byte at 0x4BC8, bit 7 is the flag for memory channel 1, bit 6 is the flag for memory channel 2, ..., bit 0 is the flag for memory channel 8. This means that when you read them in a hex editor the bits are in the "correct" order when read left to right.

With 10 banks, that is 640 bytes in total for bank flags for the left radio. 640 = 0x280, and 0x4BC8 + 0x280 = 0x4E48.

Unfortunately, I was unable to actually test this, as after reading the memory out of my FT-8800R, when I pressed the power button to go back to normal radio mode, something in the radio got corrupted and now my radio is borked. I don't think this is a CHIRP issue, as I've found one report online of it happening with the RT programming software. The fact that a radio has no hard-reset option (e.g. a pad to short on power-up to restore a factory default) is infuriating...

I can confirm Chris' finding. 0x4E48 is the correct value for FT8800RadioRight._bankstart. (I played with dumped memory and verified that 0x5088 is the right bank10, so 0x4E48 is the right bank1)

However, I don't have a development setup so I can't modify .py and try compile/run it. Any developer compiles a new version and I am willing to test it.

Chris, that was an unfortune for your 8800R. Do you consider jump wire (or de-solder) the EEPROM (AT24C256N) and read/write by a flash programmer? (disclaimer: backup before any modification) If the content matches the dumped Chirp img file (i.e., data is not scrambled), you may be able to "reset" by loading a clear 8800R img (that anyone can generate for you).