Kenwood Th-d74 Software Mac

Here's a demonstration of the Kenwood TH-D74 firmware update procedure. If you are not comfortable with this, I recommend that you don't do it.

Th D74 Programming
Kenwood Th D74 Software
Kenwood Th D74 Drivers
Kenwood Th D74 Software Download

TH-D74 Modification of the US version. There have been numerous questions on the internet regarding whether the published and well detailed modification by TH-D74 Mod Extended TX Frequency is applicable to the US version of the TH-D74(A). The usual disclaimers apply. Please do at your own risk, and follow the laws of your country.
The Kenwood TH-D74 OEM software is not bad. But, I wanted to easily transfer programming data from my Yaesu to the TH-D74. RT systems is the way to go to do that. I ordered the RT Systems software and when I opened it was the wrong software but it was labeled correctly.
Here is a video on how to download from www.dstarinfo.com a DSTAR repeater list for the Kenwood TH-D74. I also show how to edit out unnecessary DSTAR repeate.

New Model #4129

Status:	In Progress	Start date:	10/14/2016
Priority:	Normal	Due date:
Assignee:	Angus Ainslie	% Done:	60%
Category:	-
Target version:	chirp-py3
Chirp Version:	daily	Equipment Loan Offered:	Yes

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

kenwood_live.py(43.7 kB)

thd74a_dump.txt(5.7 kB)

kenwood_live.py(47 kB)

thd74.py(12.9 kB)

mcp_dump_d74.py - Use the MCP protocol to get a dump of the settings memory (1.6 kB)

kenwood_live.py - Add the d74 in line mode - can't write names (62.5 kB)

thd72.py - d72 driver with some python3 mods (23.7 kB)

thd74.py - TH-D74 driver (19.9 kB)

platform.py - Add rfcomm for bluetooth radios (15.1 kB)

History

Updated by Tom Haywardover 4 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 Storkeover 4 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 Storkeover 4 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 Johnsonover 4 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 Haywardover 4 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 Johnsonover 4 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 Haywardover 4 years ago

Filekenwood_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 Johnsonover 4 years ago

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

Updated by Nigel Johnsonover 4 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 Haywardover 4 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 Hearnover 4 years ago

Tom Hayward wrote:

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

Updated by Tom Haywardover 4 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.

Updated by Randall Hearnover 4 years ago

Tom Hayward wrote:

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 Haywardover 4 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 Hearnover 4 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.

Th D74 Programming

Will be playing over the Christmas Holiday break, so lots of time to learn the code and whats going on I hope.

Updated by Aaron Pover 4 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 Haywardover 4 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 Pover 4 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 Hearnover 4 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 Haywardover 4 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 Pover 4 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

Kenwood Th D74 Software

Updated by Aaron Pover 4 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 Hearnover 4 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 Haywardover 4 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.

Hope this helps some, below is the hkm file for two memory entries in the D74.

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 Pover 4 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 Hearnover 4 years ago

Aaron P wrote:

No:

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 Hearnover 4 years ago

Randall Hearn wrote:

Aaron P wrote:

No:

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 Pover 4 years ago

Randall Hearn wrote:

HMK export
...

Hope this helps some, below is the hkm file for two memory entries in the D74.

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 Kingalmost 4 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 Wolakover 3 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 Wolakover 3 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 Haywardover 3 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 Wolakover 3 years ago

Filethd74a_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 Mikuckiover 3 years ago

Douglas King wrote:

Likewise, happy to offer myself up as a beta tester. Can test windows, linux, mac.

Updated by Craig Waldmanabout 3 years ago

I too volunteer as tribute!

Updated by Craig Waldmanabout 3 years ago

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

Updated by George Rosvallyabout 3 years ago

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

Updated by Aaron Pabout 3 years ago

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

Updated by George Rosvallyabout 3 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 Pabout 3 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 McKeehanalmost 3 years ago

Filekenwood_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 McKeehanalmost 3 years ago

Filekenwood_live.py added

The previous file missed one critical bit - the offset. This version fixes that issue.

Updated by David McIntyrealmost 3 years ago

Kenwood Th D74 Drivers

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 McKeehanalmost 3 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 Recioalmost 3 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 McWhirtalmost 3 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('IDr')
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 McWhirtalmost 3 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('IDr')
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('IDr') 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 hooverover 2 years ago

Bryan and others -- any progress on this?

Updated by christopher hooverover 2 years ago

This will likely be useful:

Updated by christopher hooverover 2 years ago

Ooops. Meant to use this URL to the top:

Updated by Jesse Bayerover 2 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 McIntyreover 2 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 Ellsonabout 2 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 Ellsonabout 2 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..

Updated by Randall Hearnalmost 2 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 Hearnalmost 2 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 Wolakalmost 2 years ago

Kenwood Th D74 Software Download

Filethd74.py added

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 Stromover 1 year 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 Benzover 1 year 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 Ainslie11 months ago

Filemcp_dump_d74.py added
Filekenwood_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

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 Ainslie11 months ago

Filethd74.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 Ainslie11 months ago

Filethd72.py added

Updated by Angus Ainslie11 months ago

Status changed from Feedback to In Progress
Assignee set to Angus Ainslie
% Done changed from 0 to 60

Updated by Angus Ainslie11 months ago

Marius Strom wrote:

Ok half way there. I'll look into the D-Star changes

Updated by Angus Ainslie11 months ago

File deleted (~~thd74.py~~)

Updated by Angus Ainslie11 months ago

Filethd74.py added
Fileplatform.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 McIntyre10 months ago

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

Updated by Randy Dunlap5 months ago

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

Updated by Nate Moore4 months 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.

Also available in: AtomPDF

I’m a Mac user. If you’re a Mac user in the ham world, you’re probably as familiar with how difficult it is to find good software for ham radio for the Mac.

With Portland NET, I’m being encouraged to get Winlink up and running if at all possible. Being on a Mac, this is not the easiest proposition. I’m not a fan of running things under WINE or running unsigned binaries or whatever. I’m fine with using a VM and running Linux inside it, but I made a bit of a mistake when I bought this laptop and thought 128GB of storage would be plenty. Pro tip: it’s not. But that’s ok. Because I have other options.

Fortunately, there’s a piece of software that looks actually quite good called Pat. It’s written in golang. It has a nice command line interface (my day job is working on linux servers and has been forever, so command line is life). It has a web based gui. And it says it supports KISS. I have a Kenwood TH-D74a which has a KISS TNC built in. Of course, I didn’t see the “linux only” part before I started playing around with it. Oops. And it seems the direct serial interface it has both doesn’t work with my setup and is very much not supported anymore.

It does seem that someone has gotten this working in the past using a proxy that Pat can talk to via some sort of TCP based protocol and the proxy translates that to KISS/AX25, but it’s quite old and I can’t seem to get it working. The KISS/AX25 projects it’s based on are self-described as “do not use” and the rewritten versions don’t seem to be fully done, so it’s kind of in a state of limbo. I considered trying to rewrite the proxy itself using a different language that has supported or at least functioning kiss/ax25 libraries, but without really knowing what I’m doing at all, I figure this is probably the wrong route to take at the moment.

Pat’s suggestion is to use Linux, which has native support for AX25, the protocol that winlink uses for transmitting packets over the air. Given my limited amount of storage on my laptop, I’m not really able to run a full VM just for that at the moment, so other options are required. One of those options is the ever awesome Raspberry Pi. The latest version, 3B+, has bluetooth, wifi, 4 usb ports, is plenty fast enough for my needs, etc. I picked one up on Amazon for about $35, along with a 32GB microsd card for about $8. Given that it has bluetooth, I’m thinking I should be able to connect it to my radio wirelessly, which allows me to stuff the rpi in the back of my tv cabinet somewhere after I get it up and running and not have to think about it too much anymore.

After hooking it up to my tv and a usb keyboard, I enabled ssh and hooked it up to wifi and went back to my couch with my laptop instead of sitting 3 feet in front of my TV on my ottoman. And then of course I couldn’t get the pi and the radio to see each other, no matter which one I set to discoverable and which one I set to scan. I was able to get the pi to see the radio, but establishing a connection wasn’t working. Before I gave up on the bluetooth route, I searched for a message I saw Failed to connect: org.bluez.Error.NotAvailable and found a forum post which talks about what I suspected that error meant, that the radio and the pi couldn’t establish a common profile, in this case the serial port profile. Sadly, after much mucking about with it, I was still unable to get it working, so I bailed on that and am just going to use USB for now.

USB worked just fine out of the box. On the TH-D74a you need to set the KISS mode to USB (menu 983) and the USB Function to COM+AF/IF Output (menu 980) and plug it in. A lot of other types of radios have a USB adapter you can buy which is almost always just a USB to serial adapter with an FTDI chip and a the correct wiring to get it to talk to the radio (either UART or I2C). RT systems sells these as well, except they are “branded” and don’t work with standard FTDI drivers and, at least on the mac, the drivers they provide don’t work because they aren’t signed. I don’t recommend any RT systems cables to anyone. Anywho. The TH-D74a basically just has one built in and it’s FTDI compatible!

If I screen /dev/ttyACM0 9600 and type ID I get back ID TH-D74, so I know it’s working! Hooray!

Ok, so on to trying to set up Pat. First, to install it. Which has some dependencies of its own. First, I need golang to be installed. I used apt-get install golang on the pi to grab go, which is version 1.7. Then I needed git because go get uses git under the hood, so I installed that. I set my GOPATH environment variable to $HOME/go and once all of that was done, go get github.com/la5nta/pat finally worked correctly.

From there it was following along on the AX.25 Linux instructions which were easy to follow along with. When I got to the axlisten part, I got a bit sad, as the local frequency I’m trying to use isn’t very active, so I don’t know if it’s working or not. But onward I press!

I got to configuring pat and setting up the ax25 interface and such and all seemed well. Then I got this error: 2019/05/05 03:22:29 Unable to establish connection to remote: AX.25 support not included in this build. I thought to myself… WHAT?! Isn’t that the whole point of this? Perhaps it’s a raspberry pi issue, maybe the code doesn’t work on ARM or something. No. Not so much. According to some other docs I needed to add build tags to get ax25 support. Which also required me to install libax25-dev.

Connect!

Nothing happened.

I forgot to mention that in the middle here I had to relocate the pi. I’d gotten a couple of messages about under voltage and thought maybe I needed a beefier USB power supply, so I shut the pi down and moved the whole setup to the kitchen. When I got logged back into the pi everything seemed fine, but I couldn’t use screen to connect anymore, for some reason. Strange. So I think that’s what’s happening right now. I’m going to reboot everything and see if that fixes it. “Have you tried turning it off and on again?” :)

Success! At least, success using screen to connect and send an ID command. Let’s try the rest of it again. Nope. I didn’t hear anything from my radio. I didn’t see any activity indication, and no output. When I finally gave up and hit ctrl-c, I got 2019/05/05 03:36:42 Unable to establish connection to remote: Dial timeout as output, so something isn’t quite right.

Google to the rescue! According to The Fine Manual™, I need to set the TNC into KISS mode. Oops.

Ok, so I got that set up. Then I was trying some winlink nodes I found on winlink.org but not really having any luck. A quick google search for “portland packet repeater” turned up the Portland Amateur Radio Club repeater list, which mentions a packet repeater that had been replaced with a winlink node. 144.910 / W7LT-10. So I tuned my radio to that frequency and tried to connect. Suddenly I was deafened by my radio. I’d turned the volume way up trying to hear if there was anything, and hadn’t turned it down. So when that winlink node started talking to me I heard it. It was glorious.

So, it worked? There was lots of back and forth between my radio and the remote system, but judging by the output, everything worked!

So, what now? Well, Pat has a web interface. So I fired it up: pat http -a 0.0.0.0:8080 (the 0.0.0.0 makes it listen on all interfaces, not just localhost, and since I’m connecting from my laptop to the raspberry pi I need to do this). Opening my browser to the web interface, and I’m greeted with what looks like a webmail view!

Success!

And it looks like I have mail!

Great!

Then I updated my password and sent myself a test message!

A couple of round trips connecting to the winlink system later and I have a new piece of mail!

Awesome!

Now, since AE7XP has been one of the folks hounding me about getting winlink going, I dropped him a message just to see if it’s all working. As far as I know winlink is also able to send and receive email from the internet, so one final test:

And a short time later…

Excellent! Now I have something to talk about on the NET net tomorrow night! :)

Please enable JavaScript to view the comments powered by Disqus.comments powered by Disqus