I don't think so. If you know how to use Chirp - read my post above
-
To anyone looking to acquire commercial radio programming software:
Please do not make requests for copies of radio programming software which is sold (or was sold) by the manufacturer for any monetary value. All requests will be deleted and a forum infraction issued. Making a request such as this is attempting to engage in software piracy and this forum cannot be involved or associated with this activity. The same goes for any private transaction via Private Message. Even if you attempt to engage in this activity in PM's we will still enforce the forum rules. Your PM's are not private and the administration has the right to read them if there's a hint to criminal activity.
If you are having trouble legally obtaining software please state so. We do not want any hurt feelings when your vague post is mistaken for a free request. It is YOUR responsibility to properly word your request.
To obtain Motorola software see the Sticky in the Motorola forum.
The various other vendors often permit their dealers to sell the software online (i.e., Kenwood). Please use Google or some other search engine to find a dealer that sells the software. Typically each series or individual radio requires its own software package. Often the Kenwood software is less than $100 so don't be a cheapskate; just purchase it.
For M/A Com/Harris/GE, etc: there are two software packages that program all current and past radios. One package is for conventional programming and the other for trunked programming. The trunked package is in upwards of $2,500. The conventional package is more reasonable though is still several hundred dollars. The benefit is you do not need multiple versions for each radio (unlike Motorola).
This is a large and very visible forum. We cannot jeopardize the ability to provide the RadioReference services by allowing this activity to occur. Please respect this.
Kenwood TK-762G Firmware Question
- Thread starter 762mm
- Start date
mmckenna
I ♥ Ø
At this point, I think the radio either has a fried component or a corrupt firmware. I cannot proceed without a copy of the firmware, unfortunately. Something like $60 in cables and adapters and I'm still not any further along...
This can be the proverbial 'slippery slope' of chasing things. You've spent 60 bucks plus untold labor hours trying to make a $50 radio work.
It's fun if you are into the challenge, but there are better radios out there that will give you a lot less headaches.
This might have some odd firmware that would require specific software. Not sure, but some other Kenwood radios can do Passport trunking and use a special firmware. That requires a specific software to program. Again, not sure that is your issue, but I wouldn't sink much more time, effort or money into this.
Thank you for your input, much appreciated!
I've tried the things you mentioned (please see post above) and I'm still having the same result. KPG56D v4.00 still gives me the same "check radio type" error under all possible models of the 762G. I also tried the other radio models + with/without the option board (in case someone programmed it wrong previously) and none of them work.
Indeed, I do know how to work in developer mode in CHIRP, as I also have a few Quansheng UV-K5(8) radios with the Egzumer firmware on them. I do not know how to program drivers though, or how to program any code at all for that matter. If you could brew up a custom module, that would be awesome!
KPG-56D v4.00 :
Yeah, I hear you and you are indeed correct.
At this point this is no longer a project, though.... It has become a QUEST!
(It's not about how much it is worth, as I do indeed have other better radios. I just like to make old radios, computers, etc. great again, lol. I like the way this clunky old radio looks, so very 80's.....)
Interesting call on the Passport firmware being possibly on it, I haven't thought of that. I searched Google and the AI overlord says it shouldn't be capable of it. I also looked inside the radio and I don't think there is any expansion card in it :
Last edited:
@762, there you go. Check if Chirp recognizes your radio first. If it does, save the .img file. Also save debug log and last serial trace.
If it does not, we'll work from there.
* Since I'm a noob here, my messages are being moderated and might appear much later.
** To moderators - attached Python file is open source, so no copyright infringment here.
If it does not, we'll work from there.
* Since I'm a noob here, my messages are being moderated and might appear much later.
** To moderators - attached Python file is open source, so no copyright infringment here.
mmckenna
I ♥ Ø
Yeah, I think these predated Passport. I think it was the 80 series that had that option.
I understand the challenge of it.
These predate my Kenwood experience by a few years, I came to the Kenwood side in the 80/90 series timeframe.
There's a couple of ideas that pop into my head based on other radios:
Market Code, not sure if the software looks for that, or even if it's an option on these older radios, but the newer stuff will look at the market code of the radio and it must match the software. That usually gets hobbyists that buy radios from overseas and try to use North American software on them, or buy North American market radio and then try to use bootlegged software with activation codes for other markets.
Pretty sure that doesn't apply to these older radios, especially the ones using DOS software.
Specialty firmware is always a possibility.
I see mention of a KPG-29D, which seems to be for the KPG-4 cable, and KPG-67d software, which looks like it is for European market radios. With the FCC ID on your tags, this is probably a North American Market radio at birth, but who knows what someone else did to it.
You can read the FW checksum, so the radio/software are talking at that level. That says that your cable/computer/radio are all talking fine. Question is the programming software.
I checked through what service bulletins I had on this radio, and there wasn't anything that looked like it pertained to yours, but there were some hardware changes along the way that required updated programming software. Newer software should talk to older firmware radios just fine, so make sure you have the latest KPG you can get your fingers on.
I don't have that software on this computer, and not sure if I have it anywhere, but take a look and make sure there's not an option to select the product/model number. The newer software figures that out for you, but I don't recall if the DOS versions will figure it out on their own.
With a radio this old, there's always the chance something corrupted in the memory and it's not able to answer properly.
You might want to sniff around for a copy of KPG-29D and see if that'll work. That appears to be for the older radios (pre serial number 809xxxxx) Not sure how KPG-56 does, it may talk to these older radios just fine.
Just some guesses, might be totally wrong, but are offered free of charge.
I understand the challenge of it.
These predate my Kenwood experience by a few years, I came to the Kenwood side in the 80/90 series timeframe.
There's a couple of ideas that pop into my head based on other radios:
Market Code, not sure if the software looks for that, or even if it's an option on these older radios, but the newer stuff will look at the market code of the radio and it must match the software. That usually gets hobbyists that buy radios from overseas and try to use North American software on them, or buy North American market radio and then try to use bootlegged software with activation codes for other markets.
Pretty sure that doesn't apply to these older radios, especially the ones using DOS software.
Specialty firmware is always a possibility.
I see mention of a KPG-29D, which seems to be for the KPG-4 cable, and KPG-67d software, which looks like it is for European market radios. With the FCC ID on your tags, this is probably a North American Market radio at birth, but who knows what someone else did to it.
You can read the FW checksum, so the radio/software are talking at that level. That says that your cable/computer/radio are all talking fine. Question is the programming software.
I checked through what service bulletins I had on this radio, and there wasn't anything that looked like it pertained to yours, but there were some hardware changes along the way that required updated programming software. Newer software should talk to older firmware radios just fine, so make sure you have the latest KPG you can get your fingers on.
I don't have that software on this computer, and not sure if I have it anywhere, but take a look and make sure there's not an option to select the product/model number. The newer software figures that out for you, but I don't recall if the DOS versions will figure it out on their own.
With a radio this old, there's always the chance something corrupted in the memory and it's not able to answer properly.
You might want to sniff around for a copy of KPG-29D and see if that'll work. That appears to be for the older radios (pre serial number 809xxxxx) Not sure how KPG-56 does, it may talk to these older radios just fine.
Just some guesses, might be totally wrong, but are offered free of charge.
That's a good idea, I haven't thought of that. I will try it with KPG-29D via DOS, just in case someone programmed it as a "non-G" model. I also downloaded a version of KPG-56D (v2.1) that seems to run under DOS only. Weird, but I will try it too.
That being said, I tried it in CHIRP already as a TK-762 (no G) and it crashes the download from radio right away, saying that this is not the right driver. When I use TK-762G in CHIRP, the download starts for about 20 seconds, but then spits out an error about wrong ID or variant at the end... (?)
I would love to zap this thing with a fresh firmware and see what happens.... if it will even accept a firmware, that is. I tried putting it into prog mode by holding one of the buttons (channel up, I think) while powering on and it didn't seem to go into firmware prog mode. I sure hope that the last person to program this unit did not remove "firmware programming" from the options! (that would be the ultimate dick move, lol)
Anyway, my TK-762G adventure continues tomorrow after work...
.
That being said, I tried it in CHIRP already as a TK-762 (no G) and it crashes the download from radio right away, saying that this is not the right driver. When I use TK-762G in CHIRP, the download starts for about 20 seconds, but then spits out an error about wrong ID or variant at the end... (?)
I would love to zap this thing with a fresh firmware and see what happens.... if it will even accept a firmware, that is. I tried putting it into prog mode by holding one of the buttons (channel up, I think) while powering on and it didn't seem to go into firmware prog mode. I sure hope that the last person to program this unit did not remove "firmware programming" from the options! (that would be the ultimate dick move, lol)
Anyway, my TK-762G adventure continues tomorrow after work...
.
I tried KPG56D v2.10, it is indeed a DOS program. Unfortunately it doesn't work any better and also says that the model is wrong. It can however read the ESN and checksum, same as KPG67D in DOS. It would be nice if it could give me a model / variant instead, but I guess it was too much for Kenwood to figure back in the day. The most crucial piece of information is not verifiable in the software, despite it knowing that it's the "wrong model". No ability to bypass the stupid model check, either. Great.
I tried KPG29D in DOS, it does not work either. The 762G listed is a 2-channel unit and not an 8-channel like mine. The software says it's the wrong model and won't proceed with download, upload, etc.
Finally, the radio will not go into firmware programming mode either (via channel up + power on). I guess whoever programmed it last made sure future firmware updates would not be possible without accessing the radio via PC first to change this setting and enable firmware programming.... Thanks buddy, whoever and wherever you are! (previous owner)
Tomorrow I will open it up and test some basic things with a voltmeter... anything in particular I should be looking for in there? My knowledge of circuit boards is limited, beyond changing a fuse or a capacitor.
:/
I tried KPG29D in DOS, it does not work either. The 762G listed is a 2-channel unit and not an 8-channel like mine. The software says it's the wrong model and won't proceed with download, upload, etc.
Finally, the radio will not go into firmware programming mode either (via channel up + power on). I guess whoever programmed it last made sure future firmware updates would not be possible without accessing the radio via PC first to change this setting and enable firmware programming.... Thanks buddy, whoever and wherever you are! (previous owner)
Tomorrow I will open it up and test some basic things with a voltmeter... anything in particular I should be looking for in there? My knowledge of circuit boards is limited, beyond changing a fuse or a capacitor.
:/
Last edited:
Yessss!!!! You are a lifesaver!
The .py driver for CHIRP worked like a charm! It downloaded the radio right away and I was able to change the frequencies and re-upload the new frequencies back to the unit! I also activated all the options : clone, self-programming, firmware update. I saved the original .img file as well. Let me know if you need any of these files and I'll post them.
The only thing that doesn't seem to work is the squelch level in settings. I get static on MURS channels and VHF calling frequency, even if I crank up the squelch to 7. This seems to be worst on Wide band channels. I believe that, for some reason, the radio sensitivity is cranked too high and this can only be accessed via the official software. But at least I now can program the damn thing and get a new firmware in there, once I get a copy somehow! That's a huge improvement!
A million thanks to you, good Sir! I was close to making a doorstop or a boat anchor out of this radio.....
Here is what CHIRP reports :
Last edited:
Another observation : KPG56D still doesn't recognize this radio and CHIRP won't open the .img file unless I load your custom .py driver module first.
This is what I get when attempting to open the saved .img file without loading the custom module first :
Debug Log :
[2025-10-31 12:17:00,247] chirp.logger - DEBUG: CHIRP next-20251024 on Win32 (Unknown 10.0:19045) (Python 3.10.8)
[2025-10-31 12:17:00,316] chirp.wxui - DEBUG: Using locale: en_US (276)
[2025-10-31 12:17:00,316] chirp.wxui - DEBUG: Translation loaded=True for CHIRP: en_US (bg_BG,de,el,en_US,es,fr,hu,it,ja_JP,nl,pl,pt_BR,ro_RO,ru,tr_TR,uk_UA,zh_CN) from C:\Program Files (x86)\CHIRP\chirp\locale
[2025-10-31 12:17:00,332] chirp.wxui - DEBUG: Translation loaded=False for wxstd: en_US (af,an,ar,ca,ca@valencia,co,cs,da,de,el,es,eu,fa_IR,fi,fr,gl_ES,hi,hr,hu,id,it,ja,ka,ko_KR,lt,lv,ms,nb,ne,nl,pl,pt,pt_BR,ro,ru,sk,sl,sq,sv,ta,tr,uk,vi,zh_CN,zh_TW)
[2025-10-31 12:17:00,748] main - INFO: Python/3.10.8 // Windows/Windows-10-10.0.19045-SP0 // CHIRP/next-20251024 // wx/4.2.0 msw (phoenix) wxWidgets 3.2.0
[2025-10-31 12:17:00,748] chirp.wxui - WARNING: Developer mode is enabled
[2025-10-31 12:17:00,780] chirp.wxui.main - DEBUG: Recent is now ['D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_NEW_FREQUENCIES_20251031.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-760_20251029.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_20251031.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\TK-3140 Fixed (2025-10-29).dat', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\TK-3140 Fixed2 (2025-10-29).dat', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-3140K_20251029.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\TK-3180-K Fixed (2025-10-24).dat']
[2025-10-31 12:17:01,096] chirp.wxui.main - INFO: Server reports next-20251031 is latest
[2025-10-31 12:17:12,807] chirp.wxui.main - DEBUG: Doing open from 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_20251031.img'
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:12,892] chirp.drivers.tk760g - DEBUG: Wrong Kenwood radio, ID or unknown variant
[2025-10-31 12:17:12,892] chirp.drivers.tk760g - DEBUG: 000: 4d 37 36 32 30 14 ff M7620...
[2025-10-31 12:17:12,892] chirp.wxui.common - WARNING: Failure while capturing logs (showing=True): Wrong Kenwood radio, ID or unknown variant, see LOG output.
[2025-10-31 12:17:12,892] chirp.wxui.common - WARNING: Not showing 0 lines of logs (error=True,show=True)
[2025-10-31 12:17:12,892] chirp.wxui.common - ERROR: <function ChirpMain.open_file at 0x000001F3E41896C0> raised unexpected exception
Traceback (most recent call last):
File "chirp\drivers\tk760g.py", line 821, in _set_variant
KeyError: b'M7620\x14\xff'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "chirp\wxui\common.py", line 652, in run_safe
File "chirp\wxui\main.py", line 582, in open_file
File "chirp\directory.py", line 200, in get_radio_by_image
File "chirp\chirp_common.py", line 1496, in __init__
File "chirp\chirp_common.py", line 1594, in load_mmap
File "chirp\drivers\tk760g.py", line 876, in process_mmap
File "chirp\drivers\tk760g.py", line 844, in _set_variant
chirp.errors.RadioError: Wrong Kenwood radio, ID or unknown variant, see LOG output.
[2025-10-31 12:17:43,415] chirp.wxui.main - DEBUG: Doing open from 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_20251031.img'
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:43,516] chirp.drivers.tk760g - DEBUG: Wrong Kenwood radio, ID or unknown variant
[2025-10-31 12:17:43,516] chirp.drivers.tk760g - DEBUG: 000: 4d 37 36 32 30 14 ff M7620...
[2025-10-31 12:17:43,516] chirp.wxui.common - WARNING: Failure while capturing logs (showing=True): Wrong Kenwood radio, ID or unknown variant, see LOG output.
[2025-10-31 12:17:43,516] chirp.wxui.common - WARNING: Not showing 0 lines of logs (error=True,show=True)
[2025-10-31 12:17:43,516] chirp.wxui.common - ERROR: <function ChirpMain.open_file at 0x000001F3E41896C0> raised unexpected exception
Traceback (most recent call last):
File "chirp\drivers\tk760g.py", line 821, in _set_variant
KeyError: b'M7620\x14\xff'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "chirp\wxui\common.py", line 652, in run_safe
File "chirp\wxui\main.py", line 582, in open_file
File "chirp\directory.py", line 200, in get_radio_by_image
File "chirp\chirp_common.py", line 1496, in __init__
File "chirp\chirp_common.py", line 1594, in load_mmap
File "chirp\drivers\tk760g.py", line 876, in process_mmap
File "chirp\drivers\tk760g.py", line 844, in _set_variant
chirp.errors.RadioError: Wrong Kenwood radio, ID or unknown variant, see LOG output.
This is what I get when attempting to open the saved .img file without loading the custom module first :
Debug Log :
[2025-10-31 12:17:00,247] chirp.logger - DEBUG: CHIRP next-20251024 on Win32 (Unknown 10.0:19045) (Python 3.10.8)
[2025-10-31 12:17:00,316] chirp.wxui - DEBUG: Using locale: en_US (276)
[2025-10-31 12:17:00,316] chirp.wxui - DEBUG: Translation loaded=True for CHIRP: en_US (bg_BG,de,el,en_US,es,fr,hu,it,ja_JP,nl,pl,pt_BR,ro_RO,ru,tr_TR,uk_UA,zh_CN) from C:\Program Files (x86)\CHIRP\chirp\locale
[2025-10-31 12:17:00,332] chirp.wxui - DEBUG: Translation loaded=False for wxstd: en_US (af,an,ar,ca,ca@valencia,co,cs,da,de,el,es,eu,fa_IR,fi,fr,gl_ES,hi,hr,hu,id,it,ja,ka,ko_KR,lt,lv,ms,nb,ne,nl,pl,pt,pt_BR,ro,ru,sk,sl,sq,sv,ta,tr,uk,vi,zh_CN,zh_TW)
[2025-10-31 12:17:00,748] main - INFO: Python/3.10.8 // Windows/Windows-10-10.0.19045-SP0 // CHIRP/next-20251024 // wx/4.2.0 msw (phoenix) wxWidgets 3.2.0
[2025-10-31 12:17:00,748] chirp.wxui - WARNING: Developer mode is enabled
[2025-10-31 12:17:00,780] chirp.wxui.main - DEBUG: Recent is now ['D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_NEW_FREQUENCIES_20251031.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-760_20251029.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_20251031.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\TK-3140 Fixed (2025-10-29).dat', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\TK-3140 Fixed2 (2025-10-29).dat', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-3140K_20251029.img', 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\TK-3180-K Fixed (2025-10-24).dat']
[2025-10-31 12:17:01,096] chirp.wxui.main - INFO: Server reports next-20251031 is latest
[2025-10-31 12:17:12,807] chirp.wxui.main - DEBUG: Doing open from 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_20251031.img'
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:12,807] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:12,892] chirp.drivers.tk760g - DEBUG: Wrong Kenwood radio, ID or unknown variant
[2025-10-31 12:17:12,892] chirp.drivers.tk760g - DEBUG: 000: 4d 37 36 32 30 14 ff M7620...
[2025-10-31 12:17:12,892] chirp.wxui.common - WARNING: Failure while capturing logs (showing=True): Wrong Kenwood radio, ID or unknown variant, see LOG output.
[2025-10-31 12:17:12,892] chirp.wxui.common - WARNING: Not showing 0 lines of logs (error=True,show=True)
[2025-10-31 12:17:12,892] chirp.wxui.common - ERROR: <function ChirpMain.open_file at 0x000001F3E41896C0> raised unexpected exception
Traceback (most recent call last):
File "chirp\drivers\tk760g.py", line 821, in _set_variant
KeyError: b'M7620\x14\xff'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "chirp\wxui\common.py", line 652, in run_safe
File "chirp\wxui\main.py", line 582, in open_file
File "chirp\directory.py", line 200, in get_radio_by_image
File "chirp\chirp_common.py", line 1496, in __init__
File "chirp\chirp_common.py", line 1594, in load_mmap
File "chirp\drivers\tk760g.py", line 876, in process_mmap
File "chirp\drivers\tk760g.py", line 844, in _set_variant
chirp.errors.RadioError: Wrong Kenwood radio, ID or unknown variant, see LOG output.
[2025-10-31 12:17:43,415] chirp.wxui.main - DEBUG: Doing open from 'D:\\-= HAM Radios =-\\-= UHF Radio Backups =-\\Kenwood_TK-762G_20251031.img'
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Loaded metadata: {'mem_extra': {}, 'rclass': 'DynamicRadioAlias', 'vendor': 'Kenwood', 'model': 'TK-762G', 'variant': '', 'chirp_version': 'next-20251024'}
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:43,415] chirp.chirp_common - DEBUG: Parsed version 'next-20251024' to (0,)
[2025-10-31 12:17:43,516] chirp.drivers.tk760g - DEBUG: Wrong Kenwood radio, ID or unknown variant
[2025-10-31 12:17:43,516] chirp.drivers.tk760g - DEBUG: 000: 4d 37 36 32 30 14 ff M7620...
[2025-10-31 12:17:43,516] chirp.wxui.common - WARNING: Failure while capturing logs (showing=True): Wrong Kenwood radio, ID or unknown variant, see LOG output.
[2025-10-31 12:17:43,516] chirp.wxui.common - WARNING: Not showing 0 lines of logs (error=True,show=True)
[2025-10-31 12:17:43,516] chirp.wxui.common - ERROR: <function ChirpMain.open_file at 0x000001F3E41896C0> raised unexpected exception
Traceback (most recent call last):
File "chirp\drivers\tk760g.py", line 821, in _set_variant
KeyError: b'M7620\x14\xff'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "chirp\wxui\common.py", line 652, in run_safe
File "chirp\wxui\main.py", line 582, in open_file
File "chirp\directory.py", line 200, in get_radio_by_image
File "chirp\chirp_common.py", line 1496, in __init__
File "chirp\chirp_common.py", line 1594, in load_mmap
File "chirp\drivers\tk760g.py", line 876, in process_mmap
File "chirp\drivers\tk760g.py", line 844, in _set_variant
chirp.errors.RadioError: Wrong Kenwood radio, ID or unknown variant, see LOG output.
Last edited:
I don't. You do..
It might be useful to troubleshoot any further issues with your radio. So yes, zip the files and post themAlso, go to 'Menu' -> 'Help' -> 'Open last serial trace', save that file and attach it here together with others.
I don't think so, but I'll have a look at the above mentioned files. Chirp driver for various 60 series radios was created by one brilliant reverser some 9 years ago. He obviously didn't have access to all models, so it is possible that he have missed something.
Also, not all features that are available in Kenwood software are present in Chirp. Chirp offers only some basic functions, but it does so for zillion of radios.
This is normal behaviour for KPG and Chirp. Save the Python module and use it until changes are implemented in official release version of Chirp. Judging by my previous experience with its devels, it might take months, though. (I can go on rant here..)
Maybe there is a way to force KPG56 to recognize this variant of the radio, but that would call for debugging it first.
Don't blame previous owner. These weren't your regular amateur radios back in the day. They were used by agencies, business entities and so on. Programming was done by dealers or service providers and, to prevent mishaps, disabling access to firmware update option by the end user was always recommended by the manufacturer. Joe Doe only had to "press that button".
---------
As to these being $50 radios and better ones available these days, I have to disagree. Putting transmission power and DSP features aside, your radio is only as good as its front end. A double superheterodyne is a double superheterodyne. Nothing has changed in that department for the last few decades. In fact, it might have become a bit worse, since sevaral Japanese semiconductor companies have closed their low noise FET production lines. They were champions in that field back in the day, btw.
Also, keeping those old-ish radios alive and producing less electronic waste is always a good thing.
Note the silkscreened numbers on the main RX/TX pcb and post them. Those might help to identify what exactly you have there. Pictures will be useful as well.
Hello,
I am attaching the .img file that downloaded initially from the radio, as well as the serial trace. Thank you again for all your help, you've been a savior!
I have also managed to find a HAM operator's website with a bunch of files on it, including a copy of 1C99 firmware from 2001 (by the looks of it). I feel adventurous and will try to upload that firmware file into the radio.
Wish me luck!
I am attaching the .img file that downloaded initially from the radio, as well as the serial trace. Thank you again for all your help, you've been a savior!
I have also managed to find a HAM operator's website with a bunch of files on it, including a copy of 1C99 firmware from 2001 (by the looks of it). I feel adventurous and will try to upload that firmware file into the radio.
Wish me luck!
Last edited:
Update : Fresh copy of 1C99 firmware successfully loaded into radio using KPG56D's Fpro utility.
No change whatsoever. KPG56D still doesn't recognize the radio type. CHIRP still only works with the custom module.
This is weird.... perhaps I need a newer version of firmware (?) I have found an old post saying that the firmware versions are tied to the serial numbers :
SN Firmware Checksums :
406XXX... F115
302XXX... 1C99
204XXX... 8553
203XXX... 629E
110XXX... BB5B
No change whatsoever. KPG56D still doesn't recognize the radio type. CHIRP still only works with the custom module.
This is weird.... perhaps I need a newer version of firmware (?) I have found an old post saying that the firmware versions are tied to the serial numbers :
SN Firmware Checksums :
406XXX... F115
302XXX... 1C99
204XXX... 8553
203XXX... 629E
110XXX... BB5B
Last edited:
It is the front PCB in your photo, but you have to look at main PCB. It might have different numbers.
Attachments
This is the deepest I can go into this unit.
Unfortunately I cannot flip the motherboard to see the other side fully without de-soldering components, that I would probably damage in the process. That rectangular black component with the Mitsubishi logo on it seems glued on and won't move, even after removing the screws :
Unfortunately I cannot flip the motherboard to see the other side fully without de-soldering components, that I would probably damage in the process. That rectangular black component with the Mitsubishi logo on it seems glued on and won't move, even after removing the screws :
Update : I've located another firmware online, which is the oldest of the bunch (BB5B). I flashed this to the radio with Fpro in DOS mode. It flashed ok and the checksum was verified as correct. Still no communication with the radio (wrong model error), except that the KPG56D DOS program now said the firmware is "too old" to do an ESN serial number check in KPG56D / KPG67D.
I then flashed it back to 1C99. Checksum verified as correct. No change, still shows as incorrect radio model when trying to download / upload to it via the official Kenwood apps, no matter which model I select.
After looking at the chart in post # 32, I believe that I possibly have the TK-762HG-K2 unit. The Kenwood software only seems to support the K units, based on the selection of variants in the menu. Could this be the issue...?
I then flashed it back to 1C99. Checksum verified as correct. No change, still shows as incorrect radio model when trying to download / upload to it via the official Kenwood apps, no matter which model I select.
After looking at the chart in post # 32, I believe that I possibly have the TK-762HG-K2 unit. The Kenwood software only seems to support the K units, based on the selection of variants in the menu. Could this be the issue...?
Last edited:
These pictures will do. I'll take a look at them a bit later.
You have some strange, possibly franken-radio. Contents of the Chirp's image file show that it is a TK-762GHˇ, market code K, but your radio responds to commands with a string of non-existent TK-762GH model, market code M! No wonder KPG56D doesn't recognize it.
It's also interesting that it was programmed by software version V1.0.
All is not lost, though, I have to think about possible solution.. Are you willing to take the risk of bricking it?
That's the power module. Tighten the screws and don't touch it anymore, or your radio might go up in smoke!
I haven't seen that one.
It doesn't surprise me at all. Flashing different firmwares won't help in your case.
You have some strange, possibly franken-radio. Contents of the Chirp's image file show that it is a TK-762GHˇ, market code K, but your radio responds to commands with a string of non-existent TK-762GH model, market code M! No wonder KPG56D doesn't recognize it.
It's also interesting that it was programmed by software version V1.0.
All is not lost, though, I have to think about possible solution.. Are you willing to take the risk of bricking it?
Last edited:
mmckenna
I ♥ Ø
K vs. K2 is just the band split.
K = 148-174MHz
K2=136-162MHz
The M model, as mentioned above, was 146-174MHz.
