Project

General

Profile

Actions

Bug #10271

closed

FTM-350: New channels not visible on radio unless directly dialled

Added by Stuart Longland almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Start date:
01/14/2023
Due date:
% Done:

100%

Estimated time:
Chirp Version:
next (py3)
Model affected:
Yaesu FTM-350AR v1.6
Platform:
Linux
Debug Log:
I read the instructions above:

Description

I managed to program a FTM-350AR using Chirp, a USB serial adaptor (tried with my laptop's built-in RS-232, but it didn't like the non-standard baud rate) and a homebrew adaptor made many moons ago, however I note the new channels cannot be selected with the up/down buttons or the dial, I have to punch in the channel number directly.

Having a look at the memory browser, I don't see anything obvious, but clearly there's a "bitmap" here that tells the radio which channels are valid or not. The FT5DR had something similar in its little memory dump files.

I've uploaded the dump generated by Chirp -- now I'm not sure what parts of this file are Chirp headers, and what parts are Yaesu raw memory map: clearly it's not just a raw dump because Chirp can identify the radio from the .img file handed to it. hexdump -C doesn't show anything obvious, but maybe I need to make a change to a memory channel, then download an image again and diff the two to figure out where this extra bitmap is.


Files

Yaesu_FTM-350_20230114.img (64.3 KB) Yaesu_FTM-350_20230114.img Memory image from radio with phantom channels Stuart Longland, 01/14/2023 10:29 AM
Yaesu_FTM-350_blank.img (64.3 KB) Yaesu_FTM-350_blank.img Blank image immediately after reset. Stuart Longland, 01/15/2023 04:14 AM
Yaesu_FTM-350_repeaters.img (64.3 KB) Yaesu_FTM-350_repeaters.img After loading repeaters into the image using `chirpc` Stuart Longland, 01/15/2023 04:19 AM
Yaesu_FTM-350_configured.img (64.3 KB) Yaesu_FTM-350_configured.img Configuring the radio and backing-up the new settings. Stuart Longland, 01/15/2023 04:19 AM
test.img (64.3 KB) test.img Last night's image, with those LSBs changed to 1s Stuart Longland, 01/15/2023 05:00 AM
Actions #1

Updated by Stuart Longland almost 2 years ago

In that dump; channels 0-4, 10, 11 and 50 are selectable via the up/down buttons and the dial.
Anything else, I have to punch in via the DTMF key pad the exact memory channel (e.g. 102).

Actions #2

Updated by Dan Smith almost 2 years ago

Oh wow, interesting. I wrote that driver in a major hurry a long time ago in between it being purchased and installed in a very inconvenient location. I have no idea what version that one was, it was an early model and never updated.

Here's what I'd do:

  1. Go to one of the memories that doesn't work properly
  2. Capture an image
  3. Save that memory over itself
  4. Confirm it is now dial-able, dial back to it
  5. Capture another image
  6. Diff.

That should result in as little change as possible.

Also, I use vbindiff which is an ncurses-based interactive binary diff program that works pretty well for this.

Actions #3

Updated by Stuart Longland almost 2 years ago

Yep, I did try saving a channel back over itself, but no noticeable change on the radio.

What I might try since I note that dump seems to have a lot of APRS message traffic in the logs despite not showing up in the UI, is do a full factory reset on the thing, then download the config, insert my channels into the new image, load it back, and see how that goes. I have the back-up of the current settings here, so nothing to loose really.

diff-ing this should tell us where this little bitmap is. I'll have a look at vbindiff; I've been using hexdump -C and plain diff, but always open to new tools. :-)

One oddity with this radio left/right sides are seen as sub-devices, and that breaks chirpc, I managed to make it work again (see https://github.com/sjlongland/chirp/commit/2a94fae76f759e35d329466044bbc5d0e75ba02e -- I will have to clean that up as a proper PR), but I get the feeling the FTM-350 is a real oddball radio.

Updated by Stuart Longland almost 2 years ago

Okay, so did a full factory reset of the device… then did a Clone TX to grab the image Yaesu_FTM-350_blank.img.
I then made a copy of this image: Yaesu_FTM-350_repeaters.img, and used (patched) chirpc to load in from my CSV files the repeaters I had.
I loaded this in using Clone RX, made some settings changes to re-instate some of the UI preferences I had, and did another Clone TX, creating Yaesu_FTM-350_configured.img.

Now to analyse these I guess. :-)

Actions #5

Updated by Stuart Longland almost 2 years ago

Yaesu_FTM-350_20230114.img                                                      
0 0000 0800: 91 02 04 39 70 08 00 00  00 48 00 8F 00 64 00 00  ...9p... .H...d..
0 0000 0810: 93 02 84 38 72 18 00 00  00 52 00 8F 00 64 00 00  ...8r... .R...d..
0 0000 0820: 91 02 81 46 62 08 00 00  00 48 00 8F 00 0C 00 00  ...Fb... .H......
0 0000 0830: 91 03 01 47 20 08 00 00  00 48 00 8F 00 0C 00 00  ...G ... .H......
0 0000 0840: 80 02 84 38 52 08 00 00  00 48 00 8F 00 64 00 00  ...8R... .H...d..
0 0000 0850: 80 02 01 47 00 08 00 00  00 48 00 8F 00 0C 00 00  ...G.... .H......
0 0000 0860: 80 02 81 46 77 08 00 00  00 48 00 8F 00 0C 00 00  ...Fw... .H......
0 0000 0870: 80 02 81 46 67 08 00 00  00 48 00 8F 00 0C 00 00  ...Fg... .H......
0 0000 0880: 80 02 04 39 95 08 00 00  00 48 00 8F 00 64 00 00  ...9.... .H...d..
0 0000 0890: 81 02 81 46 87 00 00 00  00 48 00 8F 00 0C 00 00  ...F.... .H......
0 0000 08A0: 81 03 81 47 02 00 00 00  00 48 00 8F 00 0C 00 00  ...G.... .H......
0 0000 08B0: 80 02 84 38 02 08 00 00  00 48 00 8F 00 64 00 00  ...8.... .H...d..
0 0000 08C0: 80 02 81 46 97 08 00 00  00 48 00 8F 00 0C 00 00  ...F.... .H......
Yaesu_FTM-350_configured.img                                                    
0 0000 0800: 81 02 04 39 70 00 00 00  00 48 00 8F 00 64 00 00  ...9p... .H...d..
0 0000 0810: 81 02 84 38 72 10 00 00  00 52 00 8F 00 64 00 00  ...8r... .R...d..
0 0000 0820: 81 02 81 46 62 00 00 00  00 48 00 8F 00 0C 00 00  ...Fb... .H......
0 0000 0830: 81 03 01 47 20 00 00 00  00 48 00 8F 00 0C 00 00  ...G ... .H......
0 0000 0840: 81 02 84 38 52 00 00 00  00 48 00 8F 00 64 00 00  ...8R... .H...d..
0 0000 0850: 81 02 01 47 00 00 00 00  00 48 00 8F 00 0C 00 00  ...G.... .H......
0 0000 0860: 81 02 81 46 77 00 00 00  00 48 00 8F 00 0C 00 00  ...Fw... .H......
0 0000 0870: 81 02 81 46 67 00 00 00  00 48 00 8F 00 0C 00 00  ...Fg... .H......
0 0000 0880: 81 02 04 39 95 00 00 00  00 48 00 8F 00 64 00 00  ...9.... .H...d..
0 0000 0890: 81 02 81 46 87 00 00 00  00 48 00 8F 00 0C 00 00  ...F.... .H......
0 0000 08A0: 81 03 81 47 02 00 00 00  00 48 00 8F 00 0C 00 00  ...G.... .H......
0 0000 08B0: 81 02 84 38 02 00 00 00  00 48 00 8F 00 64 00 00  ...8.... .H...d..
0 0000 08C0: 81 02 81 46 97 00 00 00  00 48 00 8F 00 0C 00 00  ...F.... .H......
┌──────────────────────────────────────────────────────────────────────────────┐
│Arrow keys move  F find      RET next difference  ESC quit  T move top        │
│C ASCII/EBCDIC   E edit file   G goto position      Q quit  B move bottom     │
└──────────────────────────────────────────────────────────────────────────────┘

That LSB of the first byte is a clue. In ftm350.py this is marked as one of the "unknown" bits, but it seems to be a "visibility" bit. I note channel 0 on each side is in a "special" place, and we get 1-499 of the left side starting at 0x0000:0800. Up top is the image I grabbed last night, and the one below is my "configured" image.

Note the LSBs of the first byte for each channel in the second is always 1 whereas in the top image, up to 0x0000:0830 are 1s with 0x0000:0840 (channel 5) is 0.

Actions #6

Updated by Stuart Longland almost 2 years ago

Bingo… the following diff fixes the problem:

diff --git a/chirp/drivers/ftm350.py b/chirp/drivers/ftm350.py
index ee901a4b..1593ba7a 100644
--- a/chirp/drivers/ftm350.py
+++ b/chirp/drivers/ftm350.py
@@ -29,7 +29,8 @@ mem_format = """
 struct mem {
   u8 used:1,
      skip:2,
-     unknown1:5;
+     unknown1:4,
+     visible:1;
   u8 unknown2:1,
      mode:3,
      unknown8:1,
@@ -368,6 +369,7 @@ class FTM350Radio(yaesu_clone.YaesuCloneModeRadio):
             _mem = self._memory_obj()[mem.number - 1]
             _lab = self._label_obj()[mem.number - 1]
         _mem.used = not mem.empty
+        _mem.visible = not mem.empty
         if mem.empty:
             return
Actions #8

Updated by Dan Smith almost 2 years ago

  • Assignee set to Stuart Longland
  • Target version set to chirp-py3

One oddity with this radio left/right sides are seen as sub-devices, and that breaks chirpc, I managed to make it work again (see https://github.com/sjlongland/chirp/commit/2a94fae76f759e35d329466044bbc5d0e75ba02e -- I will have to clean that up as a proper PR), but I get the feeling the FTM-350 is a real oddball radio.

Ah, there are a number of radios with sub-devices, so we should fix that in chirpc. I can take a look at that tomorrow and see if I can make it work.

Thanks for tracking this fix down!

Actions #9

Updated by Stuart Longland almost 2 years ago

  • Status changed from New to Closed
  • % Done changed from 0 to 100
Actions #10

Updated by Dan Smith almost 2 years ago

Oh I clicked on the wrong link, I see you've got a start there, looks sensible to me!

Actions

Also available in: Atom PDF