CHIRP

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.

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.

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

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.

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

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.

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

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