Bug #10271
closedFTM-350: New channels not visible on radio unless directly dialled
100%
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
Updated by Stuart Longland over 1 year 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).
Updated by Dan Smith over 1 year 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:
- Go to one of the memories that doesn't work properly
- Capture an image
- Save that memory over itself
- Confirm it is now dial-able, dial back to it
- Capture another image
- 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.
Updated by Stuart Longland over 1 year 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 over 1 year ago
- File Yaesu_FTM-350_blank.img Yaesu_FTM-350_blank.img added
- File Yaesu_FTM-350_repeaters.img Yaesu_FTM-350_repeaters.img added
- File Yaesu_FTM-350_configured.img Yaesu_FTM-350_configured.img added
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. :-)
Updated by Stuart Longland over 1 year 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.
Updated by Stuart Longland over 1 year 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
Updated by Stuart Longland over 1 year ago
https://github.com/kk7ds/chirp/pull/397 submitted
Updated by Dan Smith over 1 year 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!
Updated by Stuart Longland over 1 year ago
- Status changed from New to Closed
- % Done changed from 0 to 100
Applied in changeset github|515bcb24f5c01caad9e48c5abd35a85b24946f01.
Updated by Dan Smith over 1 year ago
Oh I clicked on the wrong link, I see you've got a start there, looks sensible to me!