New Model #4129
closedKenwood TH-D74A
Added by Mike Storke over 7 years ago. Updated over 1 year ago.
60%
Description
Brand new radio selling like hotcakes. Will buy and offer for loan to get supported. Meant to be a replacement for the D72 but this radio appears to be quite different all the way around, lacking full duplex but adding D-STAR, CW/SSB/USB reception, and (on the American version) 222 MHz (thus the A/E variants are different internally in this radio).
Not related to this model, still offering my IC-T81a and DJ-G29T along with this radio for loan if developer will try to support them (their requests are over 2 years old with no response).
Files
| kenwood_live.py (43.7 KB) kenwood_live.py | Tom Hayward, 11/20/2016 02:56 PM | ||
| thd74a_dump.txt (5.69 KB) thd74a_dump.txt | Eric Wolak, 11/29/2017 11:45 AM | ||
| kenwood_live.py (47 KB) kenwood_live.py | William McKeehan, 07/09/2018 10:39 AM | ||
| kenwood_live.py (47 KB) kenwood_live.py | William McKeehan, 07/13/2018 07:12 AM | ||
| thd74.py (12.9 KB) thd74.py | Eric Wolak, 08/17/2019 02:45 PM | ||
| mcp_dump_d74.py (1.62 KB) mcp_dump_d74.py | Use the MCP protocol to get a dump of the settings memory | Angus Ainslie, 06/13/2020 10:23 AM | |
| kenwood_live.py (62.5 KB) kenwood_live.py | Add the d74 in line mode - can't write names | Angus Ainslie, 06/13/2020 10:23 AM | |
| thd72.py (23.7 KB) thd72.py | d72 driver with some python3 mods | Angus Ainslie, 06/14/2020 06:01 PM | |
| thd74.py (19.9 KB) thd74.py | TH-D74 driver | Angus Ainslie, 06/21/2020 09:32 AM | |
| platform.py (15.1 KB) platform.py | Add rfcomm for bluetooth radios | Angus Ainslie, 06/21/2020 09:32 AM |
Updated by Tom Hayward over 7 years ago
- Status changed from New to Feedback
What kind of turnaround would you expect if I were to take you up on the loan offer? If its protocol is like the D7, D72, D700, and D710, it will only take me a few hours. If it is something new it will take me much longer and may get spread out over a month or two.
Updated by Mike Storke over 7 years ago
I've decided not to buy the radio after playing with it at HRO. However, if you don't get any takers in the next week or two for some reason, I may buy it to help with the project. (I'm away visiting family next week, so some time after that.)
Updated by Mike Storke over 7 years ago
I've been at a new job so sorry it apparently took a whole month (!!) to reply here! I'm very sorry about that. Do you still need someone to loan a radio?
Updated by Nigel Johnson over 7 years ago
I am a little hesitant to ship the D74 across international borders due to the high value customs documentation, but I would like to help get support.
I am a computer engineer (read old fashioned mainframe CE and embedded systems) with over 40 years experience but have not delved into the protocols of radio programming.
If I could hack into the comms and get data packets of a read and write with the kenwood software, would it be of any use to someone to help get support, with me then as a beta tester?
I have used chirp now for my TH-D72, IC-7100, and IC-92AD and am a firm believer!
cheers,
Nigel
ve3id
Updated by Tom Hayward over 7 years ago
You can get started by sending the two characters "ID" over a serial connection to the device (probably its USB-serial port) and seeing if you get a response. That's how all Kenwoods program.
Updated by Nigel Johnson over 7 years ago
OK, using kermit at 115200 baud on /dev/ttyUSB0:
Connecting to /dev/ttyACM0, speed 115200
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.¶
ID TH-D74
Updated by Tom Hayward over 7 years ago
- File kenwood_live.py kenwood_live.py added
Okay, try this with File > Load Module (you'll need Help > Enable Developer Functions checked).
This just tries to use the TH-D72 driver for the TH-D74. If they changed anything, you'll get an error. Feel free to debug from there.
Updated by Nigel Johnson over 7 years ago
Well, it communicates with the radio fine when I do that, but comes up with Unsupported model `TH-D74'
Updated by Nigel Johnson over 7 years ago
Nigel Johnson wrote:
Well, it communicates with the radio fine when I do that, but comes up with Unsupported model `TH-D74'
Is there a how-to on changing a driver to accommodate a new model? I didn't find one so far.
Updated by Tom Hayward over 7 years ago
You can see examples of how new models have been added by reading the kenwood_live.py source. Here's where it adds the TH-D74 with the same process as various other Kenwoods: http://chirp.danplanet.com/attachments/2955/kenwood_live.py#L1145
Updated by Randall Hearn over 7 years ago
Tom Hayward wrote:
You can see examples of how new models have been added by reading the kenwood_live.py source. Here's where it adds the TH-D74 with the same process as various other Kenwoods: http://chirp.danplanet.com/attachments/2955/kenwood_live.py#L1145
I got the py file to work with my radio, however when I enter a freq it tells me it refused the mem entry "Radio Refused 1".
I have the D72 and looking at the files the difference is the memory channels are the same except the D74 appends the following information to every entry "Off,100,0,Off,0,CQCQCQ,DIRECT,DIRECT"
That is the default information for all entries unless you want to make it a specific DSTAR type memory. Below is what I have found, there are Tornadoes in the area so I am calling it a night earlier.
The first off I believe is the Squelch Type (I will play with it more)
The 100 is Fine Step [Hz]
The first 0 is not known yet. Could be Digital Code
The next off is not known yet as well.
The next 0 is not known, it could be the digital code or another.
The CQCQCQ is URCALL
First DIRECT is RPT1
Second DIRECT is RPT2
So those fields would need to be edited for each memory location where a DSTAR memory is stored, but for now for FM repeater or simplex use simply appending that to the information to the radio would allow me to program mine.
Just learning the code used in CHIRP, but to eliminate the Radio Refuse
I will see if I can find out what the values are that I could not easily find in MCP soon.
Updated by Tom Hayward over 7 years ago
It sounds like you have made some good progress! Take a look at the D72 and D710 functions @_parse_mem_spec@ and @_make_mem_spec@. These handle decoding and encoding the string from the radio, which is apparently different on the D74 like it was on the D72.
http://chirp.danplanet.com/attachments/2955/kenwood_live.py#L1091
Updated by Randall Hearn over 7 years ago
Tom Hayward wrote:
It sounds like you have made some good progress! Take a look at the D72 and D710 functions @_parse_mem_spec@ and @_make_mem_spec@. These handle decoding and encoding the string from the radio, which is apparently different on the D74 like it was on the D72.
http://chirp.danplanet.com/attachments/2955/kenwood_live.py#L1091
Thanks, that is the area I was thinking about. I am going to setup my d74 and d72 exactly the same end export new files. Seems there may be a few more differences as well in the order the information is stored. Not sure if that makes a difference in parsing, but I would think it would.
Updated by Tom Hayward over 7 years ago
It looks like Kai has the mem spec documented here: https://github.com/LA3QMA/TH-D74-Kenwood/blob/master/commands/ME.md
Updated by Randall Hearn over 7 years ago
That will help, I could not get portmon to work on X64 so I finally got Serial port Monitor installed and was starting to go through the dumps. I did find that adding the question mark in the code below allowed Chirp to stop after importing my 2 memories I have entered, instead of running through 999. Found the "?" in a error return.
Will be playing over the Christmas Holiday break, so lots of time to learn the code and whats going on I hope.
result = command(self.pipe, *self._cmd_get_memory(number))
if result == "R" or result == "E" or result == "?":
mem = chirp_common.Memory()
mem.number = number
mem.empty = True
self._memcache[mem.number] = mem
Updated by Aaron P over 7 years ago
Is anybody actively working on this? The inability of the Kenwood software to import analog repeaters is just crazy. It's also winblows only. Other than that, it appears to work pretty well.
My instinct is to get to hacking a radio backup to jam in some saved frequencies, but that's not necessarily useful for chirp.
Have any of you made any more progress that you'd like to share? I'm happy to see what I can contribute. Otherwise, I'll have a crack at some file hacking.
Updated by Tom Hayward over 7 years ago
Aaron, all the commands are documented in the link in my last post. It's almost exactly the same as the D72. You should be able to copy/paste the D72 code in Chirp, edit the memspec slightly to the match the linked spec, and it'll be done.
Updated by Aaron P over 7 years ago
Tom; you are humouring me with very obvious things. TY. :)
LA3QMA also has a lot more docco than I ever expected to see.
If I hear nothing from Randall I'll launch into this tomorrow.
Do you guys know anyone with the 72? Is this normal Kenwood behaviour? Or WTF is the crazy, lazy, situation that leads to this?
Updated by Randall Hearn over 7 years ago
Aaron P wrote:
Tom; you are humouring me with very obvious things. TY. :)
LA3QMA also has a lot more docco than I ever expected to see.
If I hear nothing from Randall I'll launch into this tomorrow.
Do you guys know anyone with the 72? Is this normal Kenwood behaviour? Or WTF is the crazy, lazy, situation that leads to this?
I have not been able to look at this since December, priorities. But I do have both the d72 and the d74. I can help with testing if you can help with code, python is not my friend.:)
Updated by Tom Hayward over 7 years ago
LA3QMA has been documenting Kenwood protocols for a long time. It's immensely helpful.
I have a D72 and wrote the D72 support linked in my last reply. There is also a D72 clone mode driver that I did not write, but it has major bugs (in particular, added channels are always UHF, or something like that). I do not have access to a D74.
Updated by Aaron P over 7 years ago
This might save someone a few minutes at some stage:
Had to modify chirp/platform.py to show ACM* in the list of ports.
Ubuntu 14.04
kernel: [22991.102604] usb 3-2: new full-speed USB device number 2 using xhci_hcd
kernel: [22991.236491] usb 3-2: not running at top speed; connect to a high speed hub
kernel: [22991.253618] usb 3-2: New USB device found, idVendor=2166, idProduct=600b
kernel: [22991.253621] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
kernel: [22991.253623] usb 3-2: Product: TH-D74
kernel: [22991.253624] usb 3-2: Manufacturer: JVC KENWOOD
kernel: [22991.255719] cdc_acm 3-2:1.0: ttyACM1: USB ACM device
Updated by Aaron P over 7 years ago
Just to keep you guys up to date, here's a portion of an email I sent to the dev list the other day:
I've been pissing about with a live driver for the TH-D74 and I've hit a
wall. There's no command to fetch/set a memory name. Surely there is one
somewhere. But, as far as I can see, it is yet to be discovered. I will
take a look through the last firmware update for the radio and see what
I can find, but I'm not overly hopeful.
With that in mind, it looks like the best way forward is hacking on a
memory dump.
Updated by Randall Hearn over 7 years ago
Arron having issues posting to the dev_list so I reply here till we figure it out.
I am not a Python programming but it is similar enough to some others. I am more Game Development. That being said, I have not done much with serial port hacking like this since the Commodore 64 days, telling my age here. My main interest with joining the dev group is to just broaden my experience some.
You are running into the issue I ran into before I got pulled away. If you let me know what the best process is to pull this information from the D74 I can help get it. The D74 must also be placed in PC mode, I have not tried your latest patch to see if that works. Maybe that is the reason I can’t send individual commands to the radio.
Not sure if the HMK export I did matches the actual memory block, but if it does I believe LAQ3MA may be incorrect. P15 according to what I have seen should be the Memory Name. P21 is actually URCALL and there are 23 total memory fields.
Hope this helps some, below is the hkm file for two memory entries in the D74.
// Memory Channels
!!Ch,Rx Freq.,Rx Step,Offset,T/CT/DCS,TO Freq.,CT Freq.,DCS Code,Shift/Split,Rev.,L.Out,Mode,Tx Freq.,Tx Step,M.Name
0001,00146.940000,005.00,00.600000,Off,88.5,88.5,023,-,----,Off,FM,00146.940000,005.00,N4HSV,Off,100,0,Off,0,CQCQCQ,DIRECT,DIRECT
0002,00147.240000,005.00,00.600000,Off,88.5,88.5,023,+,----,Off,FM,00147.240000,005.00,SKYWARN,Off,100,0,Off,0,CQCQCQ,DIRECT,DIRECT
Updated by Tom Hayward over 7 years ago
Randall Hearn wrote:
The D74 must also be placed in PC mode, I have not tried your latest patch to see if that works. Maybe that is the reason I can’t send individual commands to the radio.
The single commands actually run in normal mode. You do not put it into PC mode first.
Not sure if the HMK export I did matches the actual memory block, but if it does I believe LAQ3MA may be incorrect. P15 according to what I have seen should be the Memory Name. P21 is actually URCALL and there are 23 total memory fields.
Hope this helps some, below is the hkm file for two memory entries in the D74.
// Memory Channels
!!Ch,Rx Freq.,Rx Step,Offset,T/CT/DCS,TO Freq.,CT Freq.,DCS Code,Shift/Split,Rev.,L.Out,Mode,Tx Freq.,Tx Step,M.Name
0001,00146.940000,005.00,00.600000,Off,88.5,88.5,023,-,----,Off,FM,00146.940000,005.00,N4HSV,Off,100,0,Off,0,CQCQCQ,DIRECT,DIRECT
0002,00147.240000,005.00,00.600000,Off,88.5,88.5,023,+,----,Off,FM,00147.240000,005.00,SKYWARN,Off,100,0,Off,0,CQCQCQ,DIRECT,DIRECT
Wow! That could explain why they removed the MN (memory name) command that was in the D72! This should be very easy to prove--no coding needed. Just open an terminal emulator and type "ME 001". It should return comma separated values for memory channel 1.
Updated by Aaron P over 7 years ago
No:
(/home/aaron/) C-Kermit>open line /dev/ttyACM0
(/home/aaron/) C-Kermit>set speed 9600
/dev/ttyACM0, 9600 bps
(/home/aaron/) C-Kermit>connect
Connecting to /dev/ttyACM0, speed 9600
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,
or followed by ? to see other options.¶
ME 000,0118700000,0000000000,5,5,2,0,1,0,0,0,0,0,0,0,08,08,000,0,CQCQCQ,0,00,0
Updated by Randall Hearn over 7 years ago
Aaron P wrote:
No:
(/home/aaron/) C-Kermit>open line /dev/ttyACM0
(/home/aaron/) C-Kermit>set speed 9600
/dev/ttyACM0, 9600 bps
(/home/aaron/) C-Kermit>connect
Connecting to /dev/ttyACM0, speed 9600
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,or followed by ? to see other options.¶
ME 000,0118700000,0000000000,5,5,2,0,1,0,0,0,0,0,0,0,08,08,000,0,CQCQCQ,0,00,0
I have not been able to connect to the radio through windows yet. Any suggestions on a Windows program comparable to C-Kermit?
Updated by Randall Hearn over 7 years ago
Randall Hearn wrote:
Aaron P wrote:
No:
(/home/aaron/) C-Kermit>open line /dev/ttyACM0
(/home/aaron/) C-Kermit>set speed 9600
/dev/ttyACM0, 9600 bps
(/home/aaron/) C-Kermit>connect
Connecting to /dev/ttyACM0, speed 9600
Escape character: Ctrl-\ (ASCII 28, FS): enabled
Type the escape character followed by C to get back,or followed by ? to see other options.¶
ME 000,0118700000,0000000000,5,5,2,0,1,0,0,0,0,0,0,0,08,08,000,0,CQCQCQ,0,00,0
I have not been able to connect to the radio through windows yet. Any suggestions on a Windows program comparable to C-Kermit?
ok got it. And correct its not in the ME command
ME 002,0147240000,0000600000,0,0,0,0,1,0,0,0,0,0,0,1,08,08,000,0,CQCQCQ,0,00,0
Updated by Aaron P over 7 years ago
Randall Hearn wrote:
HMK export
...Hope this helps some, below is the hkm file for two memory entries in the D74.
// Memory Channels
!!Ch,Rx Freq.,Rx Step,Offset,T/CT/DCS,TO Freq.,CT Freq.,DCS Code,Shift/Split,Rev.,L.Out,Mode,Tx Freq.,Tx Step,M.Name
0001,00146.940000,005.00,00.600000,Off,88.5,88.5,023,-,----,Off,FM,00146.940000,005.00,N4HSV,Off,100,0,Off,0,CQCQCQ,DIRECT,DIRECT
0002,00147.240000,005.00,00.600000,Off,88.5,88.5,023,+,----,Off,FM,00147.240000,005.00,SKYWARN,Off,100,0,Off,0,CQCQCQ,DIRECT,DIRECT
Surely did help! It had not occurred to me that you would import CSV files by opening them as native files. Some of the column headers are missing, but all of the required information is present in the data.
With this new information my enthusiasm for hacking on chirp has diminished. I will spend a day or so setting up my new radio and get back to this later.
As an aside, I also discovered many radio images in the source tree, so that gives me a good starting point for finding drivers with features that I can copy.
Updated by Douglas King almost 7 years ago
I'm running a Kenwood TH-D74 as well ... if I can do any testing or provide assistance, let me know. I can't do the shipping thing due to cross border issues though. I can test under Windows or Linux. The radio does work with the Kenwood software under Linux.
Updated by Eric Wolak over 6 years ago
I just got myself a TH-D74A, so I'll be taking a crack at this over the next few weeks.
Updated by Eric Wolak over 6 years ago
It looks like the "MCP" software from Kenwood does a memory dump, instead of live editing. Is there commercial software out there that does live editing that I can tackle for reverse engineering to see if we can get the channel name? Otherwise I'm going to get the MCP mode working and go with a standard memory dump.
Updated by Tom Hayward over 6 years ago
Since channel name is not available in the live commands I would focus on the MCP protocol. Check out the D72 clone mode driver for inspiration.
Updated by Eric Wolak over 6 years ago
- File thd74a_dump.txt thd74a_dump.txt added
I'm on it. Looks like the protocol is more or less the same, so I'll refactor out a common Kenwood base class for these radios.
Updated by John Mikucki over 6 years ago
Douglas King wrote:
I'm running a Kenwood TH-D74 as well ... if I can do any testing or provide assistance, let me know. I can't do the shipping thing due to cross border issues though. I can test under Windows or Linux. The radio does work with the Kenwood software under Linux.
Likewise, happy to offer myself up as a beta tester. Can test windows, linux, mac.
Updated by Craig Waldman about 6 years ago
Found this on the Yahoo Th-D74 Group, does this help?
https://github.com/LA3QMA/TH-D74-Kenwood
Updated by George Rosvally almost 6 years ago
Any status on the update?
I can test or work on update if needed.
Updated by Aaron P almost 6 years ago
I did make some progress on this initially, but I've been side-tracked for some time now, unfortunately.
Updated by George Rosvally almost 6 years ago
Would you be willing to share what you have and any thoughts on what needs to be done?
I may be able to put some cycles into the project.
Updated by Aaron P almost 6 years ago
For sure! I'm out of action for a couple of days though. I'll gather it all together early next week.
Updated by William McKeehan almost 6 years ago
- File kenwood_live.py kenwood_live.py added
I made an attempt to update the kenwood_live.py to add the TH-D74 and got it working well enough to add the frequencies in my list to the radio. Issues that remain with this attempt include:
- No support for D-Star
- Memory Names are not read/updated
- Band B of the radio must be in a memory mode (not VFO) - this was so I could get a non N or ? response from a command that did nothing
It's not great, but it's better than what I had and I was able to get all of my frequencies into my D74.
Updated by William McKeehan almost 6 years ago
- File kenwood_live.py kenwood_live.py added
The previous file missed one critical bit - the offset. This version fixes that issue.
Updated by David McIntyre almost 6 years ago
William McKeehan wrote:
The previous file missed one critical bit - the offset. This version fixes that issue.
I noticed that channel names did not import from CHiRP to the D74A in attachments/4335. Does this fix resolve that issue?
I went back in with MCP to update the channel names to work around.
Updated by William McKeehan almost 6 years ago
David McIntyre - no, this update does not set the name for the memories - thus far, I cannot find a way to set the names (or groups).
Updated by Emilio Recio almost 6 years ago
Just bump for a status on the synch'ing for TH-D74[AE]. If there's anything I can do to help move this along, I have a few hot moments between work.
Updated by Bryan McWhirt almost 6 years ago
I just got my TH-D74A and was playing around based on what I was reading. However Im not getting expected responses.
I wanted to make sure I wasn't missing something so I read 10 lines afer asking the radio to ID, the only response I get is '?'
@
#!/usr/local/bin/python
#
import serial
with serial.Serial('/dev/tty.usbmodem145411', 9600, timeout=1) as ser:
ser.write('ID\r')
for x in range(9):
line = ser.readline()
print(line)
@
If anyone is interested I can upload serial data capture as well as the save file of my memory from MCP-D74.
Updated by Bryan McWhirt almost 6 years ago
Bryan McWhirt wrote:
I just got my TH-D74A and was playing around based on what I was reading. However Im not getting expected responses.
I wanted to make sure I wasn't missing something so I read 10 lines afer asking the radio to ID, the only response I get is '?'
@
#!/usr/local/bin/python
#
import serial
with serial.Serial('/dev/tty.usbmodem145411', 9600, timeout=1) as ser:
ser.write('ID\r')
for x in range(9):
line = ser.readline()
print(line)
@If anyone is interested I can upload serial data capture as well as the save file of my memory from MCP-D74.
Ok, I got that working, I apparently I had a non printable char in the ser.write('ID\r') line.
Now that I can talk directly to the radio I'll try to catch up on what's already done in latest kenwood_live.py file.
Updated by christopher hoover over 5 years ago
Bryan and others -- any progress on this?
Updated by christopher hoover over 5 years ago
This will likely be useful:
https://github.com/LA3QMA/TH-D74-Kenwood/tree/master/commands
Updated by christopher hoover over 5 years ago
Ooops. Meant to use this URL to the top:
Updated by Jesse Bayer over 5 years ago
I just picked up a TH-D74A and was curious if it is going to be supported on chirp? Dose one still need to be loans out to get it supported on here? Any updates at all on support? Thanks
Updated by David McIntyre over 5 years ago
There's a link in this thread to a driver that (sort of) works. It's good enough to copy entries from another CHiRP spreadsheet into the D74A, but there will likely be some post-processing in MCP or manual entry on the keypad to get the memory names to display.
Updated by Nick Ellson about 5 years ago
Hello, new owner of TH-D74A from a TH-D72A. I see that there is a driver (Python Code) that will do simple copy of my TH-D72A to the 74, I have the python file, where does it go to use it?
And is anyone still working on improving the support for the TH-D74A, I am happy to help if I can with testing on my Radio.. and I would love to play with writing code, I do Python Scripting as a network Engineer.. not really sophisticated, but I can follow code pretty well.
Nick
N7CKY
Updated by Nick Ellson about 5 years ago
OK, I seem to have some progress.. by enabling developer mode. Got the module loaded and read my radio, copied my TH-D72A Memories 1-50 into my TH-D74A in livemode and watched it complain each time about the NAME field being rejected and a number of my Frequencies being rounded to the nearest correct frequency.. Odd.. and it wasn't even the FRS band freq's either..
So to try and be helpful, I thought I would download a USB Sniffer app, and work with the MCP-74 free program and see how it sent names. Quite a ways into teh upload I found them all by themselves (I had just manually set memory 0 & 1 only.) I may work with this sniffer a bit to see if I can figure out how to do it manually with a terminal (Using SecureCRT in Windows 10) and then Python. Kinda fun..
57 01 00 00 00 41 50 52 53 00 00 00 00 00 00 00 W....APRS.......
00 00 00 00 00 4E 55 43 41 4C 4C 00 00 00 00 00 .....NUCALL.....
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 0 .
Updated by Randall Hearn almost 5 years ago
I have retired and need a project so I was surprised this wasn't resolved yet. I have not used my D74 except for the already manually defined freqs but I do need to transfer freqs now.
Nick, I found the channel calls as you have and the channel names are on 16 spaces. I should have my code where I was accessing the D74 (ported from the D72) on my old computer.
Best bet I am thinking for this radio is to do just like the MCP program and do a full memory dump. It does not take long to dump it all. You can speed the dump up by removing a lot of the Dstar information the user does not need.
So I guess it is time to find that old code, update and start cracking it again.
Updated by Randall Hearn almost 5 years ago
After playing around monitoring the radio from MCP and looking at the current posted kenwoodlive, I think I am coming to the same conclusion that I had 2 years ago.
While you can edit and change the frequencies in Live mode, you only have limited ability to change the Names,Dstar and other memory blocks.
From what I am seeing the radio enters MCP Programming mode and then reads the initial memory channels. After that it reads the rest of the memory blocks (not in this order) for the memory channel Names, Dstar repeaters, ect in 261 byte chunks with 16 byte blocks.
I have a huge memory dump and will go through each 261 byte block and identify what is being read. I think the key is going to be reading off the memory, storing the writing it back.
If someone sees anything else going on let me know. But I can now identify the memory channels, and the associated memory block where its NAME is associated with. But only by looking at complete memory dumps.
Updated by Eric Wolak over 4 years ago
Hey Randall,
I got clone read of the D74 mostly working a couple of years back, but I stalled out on the write side. Somehow I forgot to attach the code to this ticket and only sent it to the mailing list.
Updated by Marius Strom over 4 years ago
Bummed we're still not able to manage the D74 through CHIRP, which can manage all my other Kenwood rigs. I'm willing to offer a $200 paypal bounty to anyone who can get this across the finish line - success criteria being able to update memory banks, including memory names, and DSTAR repeater info into the D74. Any takers?
Updated by Karsten Benz over 4 years ago
I'm willing to give this a try, especially since I've been a proud owner of a TH-D74A since a week - and I can't get the windows software to run on my Linux systems.
Updated by Angus Ainslie almost 4 years ago
- File mcp_dump_d74.py mcp_dump_d74.py added
- File kenwood_live.py kenwood_live.py added
- Target version set to chirp-py3
Ok I've been doing some testing with this under the py3 branch. I can read and write the memory locations with the name caveat above.
Attached is a very slightly modified kenwood_live.py to work with the py3 branch.
I've also attached a mcp_dump_d74.py that uses the Kenwood MCP protocol to dump all of the configuration memory. Here's a good explanation how the protocol works on a V71
https://blog.oddbit.com/post/2019-10-03-tm-v71a-linux-part-1/
The D74 works the same way except uses 3 bytes for the address as it has a larger memory.
I'm not going to include the memory dump from the radio save settings to SD or the mcp_dump_d74.py but here is what I've found so far.
The save settings file for the radio that ends with ".d74" is very similar to what is read by the mcp_dump_d74.py program. The settings file has an addition 256 byte header that accounts for the differing offsets below.
|.d74 offset|.mcp offset|_.data|
|0x0|NA|256 byte settings file header - includes radio type and firmware ver|
|0x3f0|0x2f0|D-Star channel information|
|0x11c0|0x10c0|Radio start up message|
|0x11d0|0x10d0|Model name:TH-D74|
|0x1300|0x1200|Callsign , default:NOCALL|
|0x10100|0x10000|Channel names - 16 bytes each|
|0x145d0|0x144d0|Weather station names - 16 bytes each|
|0x14800|0x14700|Call channel names - 16 bytes each|
|0x14900|0x14800|Group test name - 16 bytes each|
|0x15100|0x15000|APRS message status header - 256 bytes|
|0x15200|0x15100|APRS messages - 256 bytes each|
|0x2a100|0x2a000|A list of cities and callsigns around the world - repeaters maybe ??|
|0x4d100|0x4d000|Bluetoth device names, MAC address and key|
|NA|0x4ffe0|radio serial number|
|NA|0x50000|MCP dump is 0xff to the end at offset 0x150000|
|0x50100|NA|.d74 file ends|
Updated by Angus Ainslie almost 4 years ago
- File thd74.py added
I don't think there is any way to use live mode to program the channel names.
I have a working d74 driver for the py3 branch. No idea if it will work on python 2
Attaching the driver for now and I'll try to get it merged later.
Updated by Angus Ainslie almost 4 years ago
- Status changed from Feedback to In Progress
- Assignee set to Angus Ainslie
- % Done changed from 0 to 60
Updated by Angus Ainslie almost 4 years ago
Marius Strom wrote:
Bummed we're still not able to manage the D74 through CHIRP, which can manage all my other Kenwood rigs. I'm willing to offer a $200 paypal bounty to anyone who can get this across the finish line - success criteria being able to update memory banks, including memory names, and DSTAR repeater info into the D74. Any takers?
Ok half way there. I'll look into the D-Star changes
Updated by Angus Ainslie almost 4 years ago
- File thd74.py thd74.py added
- File platform.py platform.py added
New driver file
- more memory fields mapped out
- corrected number of memories
- better support for modes
better VFO range support
might work EU with version now and show work unmodified and expanded TX ranges
Updated by David McIntyre almost 4 years ago
https://kk4vcz.com/posts/th-d74-firmware/ full firmware dump
Updated by Randy Dunlap over 3 years ago
Hi, what is the current status of support for the Kenwood TH-D74A? Thanks.
Updated by Nate Moore over 3 years ago
I'm with @Marius Storm.
I'm willing to offer $100 via paypal to someone who gets the D74 working with CHRIP for editing analog and dstar entries, etc.
Updated by Dan Smith over 1 year ago
I added initial support for the TH-D74 in live mode in last night's build. There are a couple missing things still, which I will hopefully push tonight for tomorrow.
The big gap is of course the memory names, which really sucks. However, getting the live mode working without names is very easy, so it at least gives us some support for the D74, but we'll likely end up needing the clone mode version to really get decent support.
Updated by Dan Smith over 1 year ago
- Status changed from In Progress to Closed
- Assignee changed from Angus Ainslie to Dan Smith
- Target version changed from chirp-py3 to chirp-legacy
I recently committed a clone mode driver for the D74 so I'll call this done. There are a few other things I want to support, like banks (groups), but it's pretty complete for the memories.