Added the first logs about this radios

73 Pavel CO7WT

Hi to all,

Taking a peek and stating to build the skeleton of the new driver I can tell you that this radio is very similar to the Kenwood 60G family (TK-760G/TK272G and friends).

The serial handshake, the ID, the empty block flagging and whole download process are pretty much the same.

Inspecting one image from the OEM software the mem organization are very similar to the ones in the Kenwood 60G Family, chances are good, I will come up with a testing develop driver soon (just to confirm that downloads are working)

73 Pavel CO7WT

I have the logs now.

Attached is the portmon log with full hex support thanks to David KG7ZMX, I will process it on the coming days and will come up with a alpha driver to test.

73 Pavel CO7WT.

First try to download a image for this radios.

Attached to this post is a developer driver, to try it you must follow this steps:

Save the file attached to this post to where you keep your chirp radio image files¶

Open Chirp (check that you have the most recent version)¶

Click "Help"¶

Click enable "Enable Developer Functions"¶

Click "File" in the menu¶

Click "Load Module"¶

Find and load the file that was saved in step 1¶

Note: This special test module only temporarily changes your CHIRP. You must load this module every time you load CHIRP to test it, otherwise you will wet the default installed chirp.

The task now is to connect a Kenwood TK-280 and try to read it to get a chirp .img file

This must be capable of read the radio... no matter if it complain about channels or other error, keep reading

If the download process works, you can be able to go to "File" and "Save" the content of the radio mem, please if success attach your saved image to this issue. (it will be ~30 Kbytes)

No working stories are also appreciated.

I repeat: the goal here is no download the contents of a radio, not to interpret the channel data or other details, in fact the channel data will no work in the present state, and uploading back to the radio is disabled for obvious reasons.

If you see that someone has uploaded an image already, please do upload yours! The more data I get more easy will be to reverse the memory map.

I wait for your tests to keep the work on this driver.

73 Pavel CO7WT.

Hi to all,

Modified version of the dev driver for download a Chirp image from one of this drivers is attached, all investigation points to a DTR/RTS dance before starting the upload/download process.

Please test it and report back.

Update the dev driver, last one has an error in the code, sorry.

I tried the tk280.py from post 12 with my tk-981 since they are related but I got this error...
global name 'length' is not defined

It doesn't appear to have gotten to the point of communicating with the radio. I am attaching the debug log for details. Hope this helps the "80 series" along. I will do what I can if you need more info.

Thanks Jim! I updated line 513 and it got me past that error. Now it won't get past entering program mode.
The error is The radio doesn't accept program mode

Attaching debug log. I don't know if this is because I have a 981 but I thought it might be helpful.

Hi -

Using the tk280.py script to read from a tk-981 (with the fix from Jim for line 513), I get an exception. Full debug log attached.

[2022-01-02 14:09:44,043] chirp.ui.common - ERROR: -- Exception: --
[2022-01-02 14:09:44,045] chirp.ui.common - ERROR: Traceback (most recent call last):
File "chirp\ui\clone.pyo", line 255, in run
File "C:\Users\adam\Downloads\tk280.py", line 962, in sync_in
File "C:\Users\adam\Downloads\tk280.py", line 583, in do_download
File "C:\Users\adam\Downloads\tk280.py", line 499, in _open_radio
AttributeError: 'Serial' object has no attribute 'reset_input_buffer'

I was able to progress a little with my TK-981. My last 2 posts were caused by user error so ignore them.

Progress: I was able to connect to the radio and it went into PROGRAM mode. Here are the steps I had to take editing tk280.py.

1. Fix the 'length' syntax error as Jim Unroe details above.
2. Comment out the 'reset_input_buffer' and 'reset_output_buffer' lines to temporarily bypass those errors detailed by Adam Bartlett. I'm sure this will need a better permanent solution.
3. The tk280.py file uses 'No' parity for the serial connection. This radio uses 'Even'. Changed that line from N to E.

The radio finally went into PROGRAM mode after step 3!!! BUT was obviously returning an unexpected radio "TYPE".

1. Changed the TYPE = "P0280" to TYPE = "M0981" (obtained from Chirp error and debug.log)

As of now, Chirp attempts to "Clone" the radio but returns an error "The radio send 1 bytes, we need 258". Maybe someone with more experience can take the next steps or guide me how to proceed. I would be happy to contribute as much as possible to get these radios onboard.

My fully edited module file(TK-981 ONLY!) and debug.log files are attached. I have also included a Wireshark USB capture of a successful download/clone from the radio using the original KPG-49D software for reference.

FWIW: I'm not sure if the radio actually uses 'Even' parity on serial because 'Odd' returns similar results while 'None' won't even open the radio in PROGRAM mode.

Through experimenting I now have the radio sending Chirp it's memory but it fails at around 10 blocks in with a "Handshake failed after checksum" error. I have all the data dumping to the log to confirm my existing 981 programming is there. At least some of it anyway.

I am just struggling with the data manipulation or how Chirp deals with what the radio sends. Attaching my current module file. I hope this helps someone understand what's going on.

Attaching the file would be smart....

UPDATE: After a lot of changes here is where things currently stand with the TK-981.

The radio is now sending all 128 blocks successfully without pop-up errors allowing Chirp to display the typical interface.
Unfortunately, the script doesn't handle the received data correctly and Chirp ends up unpopulated. See the .img file for reference.

The log ends with the following:

• File "/home/me/Documents/TK-981/tk981.py", line 1278, in get_settings TOT.index(str(int(sett.tot)))])) ValueError: '1728' is not in list*

AND

• File "/app/lib/python2.7/site-packages/chirp/ui/settingsedit.py", line 220, in _build_ui raise Exception("Invalid Radio Settings") Exception: Invalid Radio Settings*

I will still poke around but I am NOT a python programmer so I might have reached my limit. My hopes are that someone such as Pavel will see the progress and recognize the rest as trivial to complete. Again, I am happy to assist with any request. All related files are attached.

Thanks Pavel! Happy to contribute. I'll be thrilled when Chirp finally supports these 8 more models.

UPDATE: I added the rest of the 80 series models and all? of their variants. The complete list is below. They just need their Ident strings populated and channels specified.
Although they are commented out until the class is fixed, I thought people might want to test their 80 series radios in the meantime. If anyone obtains Ident strings please let us know so we can fully populate the list.
TK-981
TK-980
TK-880
TK-780
TK-480
TK-481
TK-380
TK-280

Hi again, I hope that codeplug has helped.
UPDATE: I mapped a good portion of the Chirp version. It is not complete however. The Key Assignment, DTMF and FleetSync sections are yet to be mapped.

Hope this helps!

SUCCESS: Working Kenwood 80 Series driver(TK-280, TK-380, TK-780, TK-880)

TLDR: This driver is for radios formatted ONLY with Conventional mode, NOT Trunked mode. This means no TK-480, tk-481, tk-980 or tk-981(Trunk only radios). Still experimental, use at your own risk.

I finally got the 80 series to work... partially. When I started I only had the TK-981 and didn't understand why it was so different than the Kenwood 60 series. Once I realized the formatting was the problem it all started to come together. I obtained more radios and finished (most of) the mapping for these radios. I'm NO expert on python so I couldn't make everything appear in the GUI but the map is there for anyone more experienced than me. Having said that, there ARE many options I was able to put in the GUI. I have tested them within reason but there may be bugs. The one major known bug is a checksum error writing block '50' to the radios which is after the majority of the settings and all channels/groups so 90% of people can use this as-is. The block in question is the DTMF memories 1 through 8 and the write stops after that error. The only KNOWN settings after that mem location are FleetSync settings. Maybe the checksum is related to a mem read-only area? Hopefully someone can take a look because FleetSync is kinda cool.

A word about TRUNKING: Most of the mem map is identical in radios formatted as trunked... except the channels(groups)/banks(systems) which change mem location AND format so an entirely different driver needs to be written. I have already started on this but it might be a compromise/limited driver based on what I've seen. We'll see what I can do. I started this just to make my TK-981 easier to program so I'm determined to finish at least a rudimentary driver for the trunked radios.

NOTE: I have a handful of these radios but not every variant/version so not all identifiers are included. If you attempt to read your radio and it gives a model match error or similar PLEASE click ok and save the file anyway. Upload it and the debug.log to this thread so your version can be added to the driver. The modification is trivial, I just don't have the identifiers to do it myself.

Please use at your own risk. I have read and written to all of my radios without damaging anything but I can't guarantee those results. Make a backup of your radio with OEM software first!

I have provided the driver and a dump of my TK-380 that you can test this driver with if you don't have an appropriate radio. You should ignore all previous drivers in this thread.

Thanks to everyone that has contributed so far, I couldn't have gotten this far without you. Let me know if you find bugs or have questions.

In order for a driver to be accepted into mainline chirp, it has to be submitted via github and pass tests (on the -next) code. Unless you developed it with python3 in mind, it will likely require changes in order to work (and from a quick glance I can tell it won't function at all in python3/next). It sounds like you're not interested in doing that work, so someone will have to pick it up, make the required changes, and submit. Just FYI, in case you were expecting it to go from an attachment here to present in a chirp build.