CHIRP

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.)

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?

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

nw.johnson@ieee.org

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.

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

Well, it communicates with the radio fine when I do that, but comes up with Unsupported model `TH-D74'

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.

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

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 am assuming those fields would need to be added and defaulted in the tabs since this is being done in live mode.

I will see if I can find out what the values are that I could not easily find in MCP soon.

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

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.

It looks like Kai has the mem spec documented here: https://github.com/LA3QMA/TH-D74-Kenwood/blob/master/commands/ME.md

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

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.

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.

source:chirp/drivers/kenwood_live.py#L1086

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?

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.:)

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.

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

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.

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

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.

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

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?

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

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.

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.

I just got myself a TH-D74A, so I'll be taking a crack at this over the next few weeks.

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.

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.

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.

I too volunteer as tribute!

Found this on the Yahoo Th-D74 Group, does this help?
https://github.com/LA3QMA/TH-D74-Kenwood

Any status on the update?
I can test or work on update if needed.

I did make some progress on this initially, but I've been side-tracked for some time now, unfortunately.

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.

For sure! I'm out of action for a couple of days though. I'll gather it all together early next week.

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.

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).

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.

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.

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.

Bryan and others -- any progress on this?

This will likely be useful:

https://github.com/LA3QMA/TH-D74-Kenwood/tree/master/commands

Ooops. Meant to use this URL to the top:

https://github.com/LA3QMA/TH-D74-Kenwood

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

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.

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

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 .

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.

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.

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?

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.

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

https://kk4vcz.com/posts/th-d74-firmware/ full firmware dump

Hi, what is the current status of support for the Kenwood TH-D74A? Thanks.

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.

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.