Project

General

Profile

Actions

Bug #3349

closed

kenwood tk-760hg and tk-860hg

Added by tom ryan almost 9 years ago. Updated almost 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
02/17/2016
Due date:
% Done:

100%

Estimated time:
Chirp Version:
daily
Model affected:
Kenwood Series 60G
Platform:
Windows
Debug Log:
I read the instructions above:

Description

Hi
Will not read from either radio. Both radios do the same things when trying to read from them. Display shows "pc" for about a second then restarts as if the power had been cycled. The 860g reports "block checksum error! real 17 calculated 6f". The 760g is the same except "calculated 89". I have attached the debug file. I am using an FTDI cable from kj6zwl. I was able to read from a tm-281 with the same cable and pc. Any help you can offer will be greatly appreciated.

Thanks
Tom Ryan
kg7otl
wqsr556


Files

debug.log (49.5 KB) debug.log tm-281 tom ryan, 02/17/2016 09:43 PM
debug.log (23.6 KB) debug.log tk-760hg and tk-860hg tom ryan, 02/17/2016 09:43 PM
LSB-0231.PDF (25.9 KB) LSB-0231.PDF Kenwwod internal note about firmware. Pavel Milanes, 02/18/2016 12:59 PM
tk760g.py (51.2 KB) tk760g.py Modified driver to test, the fix is related to a serial flush before every read. Pavel Milanes, 02/26/2016 08:00 PM
how to portmon.doc (18 KB) how to portmon.doc Instructions to get a log of the comunications between radio and original software Pavel Milanes, 02/26/2016 08:00 PM
chirp error.jpg (53.9 KB) chirp error.jpg John Reinhart, 02/27/2016 06:56 PM
tk760g.py (52.6 KB) tk760g.py Fixed driver, it now works on windows. Pavel Milanes, 03/03/2016 05:32 AM

Related issues 2 (0 open2 closed)

Related to Bug #3211: Kenwood TK-260G bugClosedPavel Milanes01/24/2016

Actions
Related to Bug #3213: Kenwood TK-270GClosedPavel Milanes01/24/2016

Actions
Actions #1

Updated by Pavel Milanes almost 9 years ago

Thanks for the report, I will review the data this night at home.

Can you please take a serial port log of the communication with the radio?

There are many alternatives, portmon is for 32 bit only, but some freeware tools can help you; this will be of much help to determine the problem.

https://www.google.com/search?q=serial+por+monitor+sniffer

This search give a lot of alternatives.

73 Pavel.

Actions #2

Updated by Pavel Milanes almost 9 years ago

Hi, I reviewed your logs and checked the driver.

It seems like your radios are using some different checksum algorithm for communication, what I think is a cause of using a different firmware...

Please I need you to check some things:

  • Is your radios using a SmartTrunk board inside?
  • Have you tested the factory software with the interface to check it work's fine?
  • Can you provide me a log of the serial communication with the original software?

About this last point, if you have a windows at 32bit you can use portmon (search in the site about it http://chirp.danplanet.com/search/index/chirp) or other freeware tool on the Internet.

A log of the serial comm using the factory software will trough some light on this.

See this Kenwood note about firmware (from the attached file):

"Firmware Compatibility: As of Jan. 2000 (S/N 110xxxxx), the "60-G Series" firmware is compatible between all versions (TK-260/270/360/370/762/760/862/860). There are no plans to change this inter-compatibility in the foreseeable future."

The "H" in the model is just a designator for "High Power Version". So you may be using a old firmware version or maybe a shinny new one.

Please check your firmware version as per the instruction of the file attached, extract follow:

"Placing the radio in the firmware mode: With the radio power switch off, place the radio in the firmware mode by holding the front panel "∧" (channel up) key, then turn power on. The LED next to the power switch will be orange when in the firmware mode. The display will indicate "PROG 576". The firmware checksum in the radio can be displayed by pressing the "MON" button."

Cheers.

Actions #3

Updated by tom ryan almost 9 years ago

Thanks Pavel! I will do as you request. However it may take me a few days. I can tell you that the ham who sold me the radios has used the factory software to program both units... his call sign is on both power on messages.

Thanks
Tom

Actions #4

Updated by Pavel Milanes almost 9 years ago

Confirmed: it's a firmware incompatibility problem.

I have searched the Internet and found on a Romanian ham web page with the only reference about Kenwood firmware, BTW, very useful intel about MANY Kenwood's firmware.

http://yo3hjv.blogspot.com is the site, from there I can tell you this:

SN Firmware Checksums
406XXX... F115
302XXX... 1C99
204XXX... 8553

203XXX... 629E

110XXX... BB5B
0XXXXX... ????

So my radio has firmware 1C99 (the one I used to build the "Series-60G" entire Family), so it's a relatively modern one, I tested some fellow ham's radios here and only found another firmware revision: 8553, older than mine and I can confirm it has the SAME PROBLEM you and others described.

I will work to determine the differences and get support in chirp for at least this other firmware version.

Thanks for report and I will keep updating this issue about this.

73 and sorry for the inconvenience.

Actions #5

Updated by Pavel Milanes almost 9 years ago

Last days I ask some friends that works and have a lot of info on the Kenwood TK-760G and others in the "Serie 60G" about firmware versions.... huffff...

It's even more confusing, I get a bunch of firmwares for the 60G Series, the hard part is that any of them has a date or a consecutive index/order to know what is more modern of what features fix/provide...

I have spotted the BB5B and 8553 from the list in the last post, but there are others as

A065, 7ADB, 96A2, 929F ... and 3 more...

I will try to load the 8553 and implement support for it as I have detected already that this particular firmware is not support in my driver.

Then I will try the BB5B... as you can imagine this is a time consuming task that I do in my free time, if you want to "buy me a beer/coffee" to make the task more pleasant drop me an email to know how.

Actions #6

Updated by Pavel Milanes almost 9 years ago

  • % Done changed from 0 to 50

Hum... things get more complicated.

I have tested to upload every firmware I have in hand to my radio; and then for each one tried a download/upload with a modification of one channel to verify it worked, jumped to a near and a distant repeater and get a good response on both.

Chirp worked just fine with EVERY firmware... hum...

Different MCU versions with non modifiable firmware that behave different? can be... but as theory says "99% of the time is the simples solution", so I will back to the Chirp's driver...

I must arrange a swap of the radios with the ham that have the TK-760G with firmware 8553 that doesn't work with Chirp.

With a "no working" sample in hand I have to play to find the problem, I will keep you informed of the progress

73 CO7WT.

Actions #7

Updated by tom ryan almost 9 years ago

Pavel
Finally had a chance to get back to my radios. here is a little info for you.
tk-760hg firmware F115 sn 50600380
tk-860hg BAAF 70200151

Actions #8

Updated by Pavel Milanes almost 9 years ago

Thanks for the report Tom,

None of your mentioned firmware are in my list; I have contacted the radio owner that has the TK-760G with firmware BB5B that can't be read with Chirp and it's out of town.

I have to wait until next week to temporary trade the radio to inspection.

73

Updated by Pavel Milanes almost 9 years ago

Hi to all the users that follow this issue,

I have found an issue that can cure the fail you are experiencing, attached to this post are two files, one is the mod driver for you to test (tk760g.py)

How to do this? simple, follow the following steps:

1 - Get the file tk760g.py attached to this post to a know place, for example the desktop.
2 - Go to Chirp's download page and get the latest version for your Operating System, install it.
3 - Open Chirp and go to the "Help" menu, once in there click the option "Enable Developer Functions"
4 - Go to File menu and an option named "Load Module" has appeared, click on it and load the file tk760g.py from your desktop (or where you put it)

Now your Chirp has support for the modified series 60G driver until it's closed. If you close it, you will have to repeat the procedure to gain access to the modified driver.

After you loaded the new module you will no see a change because the actual driver is replaced silently by the new one.

This modified driver has support for the following radios:

TK-260G/270G/272G/278G
TK-760G/762G/768G (including the HG versions)
TK-860G/862G/868G (including the HG versions)

Please try to read and work with your radio and report back any error or success, if you found and error try to locate the debug.log file, zip it and attach it on a email message to me, it will contain useful debug data. I invite you to read the web page about reporting an issue to know where to find the debug.log file. (http://chirp.danplanet.com/projects/chirp/wiki/How_To_Report_Issues)

If all goes wrong and you still can't get Chirp to work with your radio then follow the procedure described in the file attached named "how to portmon.doc", to get the download/upload logs, then zip it and send it to me. (or upload it to this issue)

Cheers

Actions #10

Updated by Pavel Milanes almost 9 years ago

  • Assignee set to Pavel Milanes
  • Model affected changed from (All models) to Kenwood Series 60G
  • Platform changed from Windows to All
Actions #11

Updated by John Reinhart almost 9 years ago

When I try to load the module I am getting this error:

"Unable to load module:list.remove(x): x not in list"

I also attached a screen shot of the error.

Actions #12

Updated by Pavel Milanes almost 9 years ago

  • % Done changed from 50 to 90

Good news, working on the btech driver I found a similar problem:

Microsoft Windows being lazy with the serial IO and the time.sleep() function with not enough granularity; Linux is a better "JIT" OS and manages to keep up.

Microsoft Windows fail with this and python feel it, I have to introduce several time.sleep() calls in the read/write procedure to keep Chirp happy.

I'm solving the "+list.remove(x): x not in list+" and other minor bugs and improvements detected, wait for a patch and in a few days a new version.

The only drawback is that windows users will get a slow download/upload than the linux/MAC users.

73

Actions #13

Updated by Pavel Milanes almost 9 years ago

  • % Done changed from 90 to 100
  • Platform changed from All to Windows

Fixed, Tested and working on WinXP laptop, Win10 PC and even a WinXP virtual machine over Ubuntu Linux.

Mental note: ALWAYS test the code and tune the timeouts for Windows before release it.

I'm working on some improvements and hidden bugs and validations. Patch soon on the queue.

73 CO7WT.

Actions #14

Updated by John Reinhart almost 9 years ago

Pavel,

I just tried the tk760g_fix and am getting an error: "Unable to load module: invalid syntax (tk760g_fix line 7)

Actions #15

Updated by Pavel Milanes almost 9 years ago

Yes it will no work, that's the patch to the devel queue; that was just a notice about the fixed problem. Sorry if I confuse you.

The fixed python driver is attached to this post for your consideration, please test and report back.

73

Actions #16

Updated by Pavel Milanes almost 9 years ago

  • Status changed from In Progress to Resolved

As the driver is updated in the daily from a while and no issues are reported I will declare this issue as resolved.

Actions #17

Updated by Pavel Milanes almost 9 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF