Project

General

Profile

Actions

New Model #1469

open

Yaesu FTM-400DR and FTM-400DE

Added by Johan Adler about 10 years ago. Updated almost 4 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
03/01/2014
Due date:
% Done:

50%

Estimated time:
Equipment Loan/Gift Offered:
No
I read the instructions above:

Description

Is anyone working on support for this model? "Manufacturer web page":http://yaesu.com/indexVS.cfm?cmd=DisplayProducts&ProdCatID=106&encProdID=227201D29C822AEFF8482F3367495319&DivisionID=65&isArchived=0

I received mine yesterday, it has support for µSD, where configuration can be saved, and a data cable is included.

Just as with the Wouxun KG-UV6D I will gladly help in any way I can, but I do not know where to start.

Johan Adler
Stockholm, Sweden


Files

CLNFTM400D.dat (75 KB) CLNFTM400D.dat Current memory dump file (clone) from memory card. Johan Adler, 03/08/2014 09:49 AM
ftm400.patch (3.74 KB) ftm400.patch Tom Hayward, 03/14/2014 10:27 AM
ftm400.patch (4.97 KB) ftm400.patch Updated patch, reads both types of file from SD card Tom Hayward, 03/14/2014 01:58 PM
MEMFTM400D.dat (25 KB) MEMFTM400D.dat Memory-only dump from 4x4ham Tom Hayward, 03/17/2014 08:49 AM
ftm-400d-memory-map.txt (2.75 KB) ftm-400d-memory-map.txt Latest analysis of CLNFTM400D.dat, updated March 17. Johan Adler, 03/17/2014 10:44 PM
ftm400.py (12 KB) ftm400.py driver for ftm400 John Murphy, 09/24/2016 08:18 PM

Related issues

Has duplicate New Model #1721: Yaesu FT1DRClosed06/28/2014

Actions
Has duplicate New Model #1755: Yaesu FTM-400deClosed07/13/2014

Actions
Has duplicate New Model #2245: Yaesu FT-400DRClosed01/23/2015

Actions
Has duplicate New Model #2373: FTM-400DRejected02/28/2015

Actions
Has duplicate New Model #3403: Yaesu FTM-400RejectedFilippi Marco03/03/2016

Actions
Has duplicate New Model #7559: Yaesu FTM-400Closed01/14/2020

Actions
Has duplicate New Model #2779: New Firmware for Yaesu FTM-400Closed08/08/2015

Actions
Has duplicate New Model #5375: ZASTONE D9000 and YAESU FTM400ClosedFilippi Marco11/25/2017

Actions
Has duplicate New Model #1601: YAESU FTM400DRClosed04/30/2014

Actions
Has duplicate New Model #9017: Yaesu FTM-400XDR/DEClosed04/26/2021

Actions
Has duplicate New Model #9009: Yaesu FTM-400XDR/DEClosed04/24/2021

Actions
Actions #1

Updated by Johan Adler about 10 years ago

I wrote a message on the developer mailing list too.

Using the file that the radio made on the micro-SD card and a hex editor I tried to analyze the file and look for probable locations of different data. After I made a general memory map I looked at the mapping used by the FTM-350 module of Chirp, and the basic address blocks seem to be the same. There are new features and setting I will have to locate, but first I might want to implement the methods of importing the data into Chirp, which in this case can be done in two ways, memory card or cable.

As I mentioned on the developer mailing list, the actual radio I bought has the transmit frequencies unlocked and it is claimed to be able to transmit on 137-174 and 400-480 MHz, which is quite useless for a law abiding ham, but it can help us locate the TX limits in memory if anyone else can provide a memory dump from a normal radio.

One thing I noted in the common Chirp code is the lack of channel spacing 8.33 MHz for Air Band, which this radio can receive (AM, of course).

Actions #2

Updated by Tom Hayward about 10 years ago

Inherit the clone routines from the FTM-350. Those will probably work.

The @match_model()@ routine will allow you to open the files copied from the radio. We usually just use length as the identifier as long as there's not a conflict.

Actions #3

Updated by Johan Adler about 10 years ago

Thank you, Tom!

I have noticed, by the way, that the Yaesu SCU-20 is based on the Prolific PL2303. :-( The data port is some 10 pin mini-DIN version I have not seen before, but the owner manual gives the pinout nice and clear.

About the 8.33 kHz channel spacing, I am not sure if the Chirp project is interested in supporting RX frequencies outside the ham bands.

Actions #4

Updated by Johan Adler about 10 years ago

Regarding the file I attached, the callsign is not mine, since I do not have one yet. This radio demands a callsign to be entered in order to be able to use the radio at all, and since I will not be transmitting, only receiving, a friend allowed me to enter his callsign.

The callsign is found in two places, at 0x2b8 and at 0x508, the latter with added APRS data.

Actions #5

Updated by Tom Hayward about 10 years ago

Here's a patch that creates a new FTM-400 driver based on the FTM-350 and allows you to read .dat files.

I wasn't able to glean much information from your .dat file. It looks like you have 144.800 MHz stored in a memory, but I don't know which memory and I don't know if I'm just seeing those bytes by coincidence. You'll need to tweak the seek offsets to match what's actually in your radio.

Actions #6

Updated by Tom Hayward about 10 years ago

Here's an updated patch. This appears to read both your full memory+settings dump and the memory-only dump correctly, at least for the A-band. I haven't seen a file with anything in the B-band.

This may actually clone correctly, too, but I wouldn't bet on it. It just inherits the FTM-350 clone code (including the memory size!).

Actions #7

Updated by Johan Adler about 10 years ago

Thanks for the help, Tom. I had to make a small change to make it read bank B correctly, and I have only worked with the full file so far. Either it does not recognize tone mode, or I have failed to set it in my rig.

I have done more analyzing of the memory dump, so I think I will be able to add some to this soon.

In the character set for labels it seems that the number 0 is now 0xbf, which shows as a qeustion mark in Chirp.

I will keep working on it at my end.

Actions #8

Updated by Tom Hayward about 10 years ago

The tone settings were simply copied from the FTM-350, so it's possible a change is needed. However, the file I was working with seemed to read the tones just fine. I've attached it here so you can test it alongside your full memory dump. The guy on 4x4ham said he left tone enabled for almost everything and only checked that it was set to a specific tone for repeaters that required it. This seems to jive with how the file decoded: tone is enabled on almost every channel with various frequencies. The frequencies match his post at 4x4ham, so I'm confident in them.

Actions #9

Updated by Johan Adler about 10 years ago

Interesting, I look forward to analyzing that file. I just registered at 4x4ham in order to be able to cooperate with the persons working on the same thing there, and share my findings.

I attach my latest update of the memory map/analysis.

Actions #10

Updated by Mike Montalvo over 8 years ago

Seems like the FTM400 effort is stalled.. Maybe I can kickstart it..

I have successfully populated a FTM400 (v1.9) dat file with a chirp CSV. This is the only radio that I have that chirp doesn't work with, so I wrote my own tool.

The data in this spreadsheet has been confirmed:
https://docs.google.com/spreadsheets/d/1Qn5wanBEPYKfFTT_YugJCQU-J17CJAZhdD8cft4vBLs/edit#gid=1778955122

Hope this helps someone do what needs to be done to get it working in chirp.

Actions #11

Updated by Joseph Peterson about 8 years ago

Just (finally!) got my FTM-400XDR and love it! Would love it even more if it would work with Chirp, any progress on this thread?
Thanks much!

73 de K6JPE

Actions #12

Updated by John Murphy over 7 years ago

I have started using this file to read/write the FTM400 I have. This appears to be working, and supporting independent top/bottom memories.

I don't have a laptop handy to test cloning with this. This needs to be placed into the drivers/ subdirectory of the chirp installation to use it.

Actions #13

Updated by Ken Alker over 7 years ago

I am running "CHIRP daily-20161208" on Windows 7 and there is no "drivers" subdirectory in the chirp installation (which is in c:\Programs (x86)\CHIRP). Can you let me know where the .py file needs to go?

Actions #14

Updated by Tom Hayward over 7 years ago

Once you enable developer functions under Help, you can use File > Load Module to load this driver. You will need to do this every time you open Chirp.

Actions #15

Updated by Ken Alker over 7 years ago

Thanks, Tom. I tried this but I get the error, "Unable to load module: invalid syntax (ftm400.py, line 1)". Any suggestions?

Actions #16

Updated by Tom Henderson about 7 years ago

John Murphy wrote:

I have started using this file to read/write the FTM400 I have. This appears to be working, and supporting independent top/bottom memories.

I don't have a laptop handy to test cloning with this. This needs to be placed into the drivers/ subdirectory of the chirp installation to use it.

Hello John,

Just got my FTM-400 and tried this. On my Linux machine, nothing happens at all when I try to download from the radio. No attempt to communicate at all.

In my Windows machine, the transfer fails with "Failed to download from radio (String index out of range)

Actions #17

Updated by Tom Henderson about 7 years ago

John Murphy wrote:

I have started using this file to read/write the FTM400 I have. This appears to be working, and supporting independent top/bottom memories.

I don't have a laptop handy to test cloning with this. This needs to be placed into the drivers/ subdirectory of the chirp installation to use it.

More info on the linux error. Got this when I tried to start the download:

Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/chirp/ui/mainapp.py", line 1582, in mh
self.do_download(*args)
File "/usr/lib/python2.7/dist-packages/chirp/ui/mainapp.py", line 681, in do_download
timeout=0.25)
File "/usr/lib/python2.7/dist-packages/serial/serialutil.py", line 261, in init
self.open()
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 282, in open
self._reconfigurePort()
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 417, in _reconfigurePort
set_special_baudrate(self, custom_baud)
File "/usr/lib/python2.7/dist-packages/serial/serialposix.py", line 60, in set_special_baudrate
raise ValueError('Failed to set custom baud rate: %r' % baudrate)
ValueError: Failed to set custom baud rate: 48000

Actions #18

Updated by David McIntyre about 5 years ago

Tom Henderson wrote:

Just got my FTM-400 and tried this. On my Linux machine, nothing happens at all when I try to download from the radio. No attempt to communicate at all.

In my Windows machine, the transfer fails with "Failed to download from radio (String index out of range)

Did you go to the [RESET/CLONE] menu in your radio and select [7 CLONE] then [This radio -> Other] to start the data transfer on the radio?

Actions #19

Updated by Bernhard Hailer almost 4 years ago

  • Target version set to chirp-legacy

Hi, is there any progress on this, or is the project stalled?

Actions #20

Updated by Bernhard Hailer almost 4 years ago

  • Status changed from New to Feedback
Actions #21

Updated by Joseph Peterson almost 4 years ago

+1 what's up with this request? 6 years?

Actions #22

Updated by Bernhard Hailer almost 4 years ago

  • Assignee deleted (Johan Adler)

The addition of a new radio to Chirp requires two things:
1) a volunteer developer who takes the task to work on this driver,
2) availability of test equipment, such as a loaner radio (see Rules For Loaning A Radio).
Unfortunately, you need to wait until both conditions have been met.
Or, you could decide to get your hands dirty yourself - check Wiki, "Developers".

Actions #23

Updated by Bernhard Hailer about 1 year ago

Actions #24

Updated by Bernhard Hailer about 1 year ago

Actions #25

Updated by Bernhard Hailer about 1 year ago

Actions #26

Updated by Bernhard Hailer about 1 year ago

Actions

Also available in: Atom PDF