CHIRP

Awesome!! Keep me posted on this

I have not been able to get anywhere with the TK-780 but maybe the more you get going, I may be able to make more sense of it!

The radio has 3 main block of memory that get read independently by different algorithms, for Chirps engine I will concatenate it as follows:

Low memory (Apparently Main CPU data & settings)
0x0000 to 0x4000
Mid memory (Unknown yet)
0x4000 to 0x4090
High memory (Apparently Head memory with channel data)
0x4090 to 0x6090

Data in the mem is at a glance, 73 I get back to work on it.

Interesting, I will review it a few minutes.

I'm giving the final touch to the set_channel now, and the download/upload is working well.

The channel management by it self is working fine, but I need so analyze more closely the other areas in which banks vs. channels are arranged, it's at a glance much similar to the TK-760G one.

I will end the set_channel and give a look to you code, I will call it a good night.

Thanks for sharing it.

73

Just an update, I have completed the download/upload, channel management and bank management.

I have a few kirks to resolve with the offset=off and some banks layouts from real radios not working, this is interesting...

This radio has a bank limit and bank belongings section in the memmap, if you start with a clean program with the KPG44D software my driver works fine, but I have found that the former programming from the radio as it get borrowed to me is a kind of corrupted.

It has 9 channels in 3 banks, banks 1, 2 and 160, hum 160... this is weird...

When you looks to the banks limits you see that only 5 channels are covered and in the bank belongings area there are 9 channels; then the radio display the 5 correct channels in banks 1 & 2 where you expect and the other 4 channels are assigned to banks 160...

I have tried to replicate this from a clean KPG44D software layout and it has been impossible to end with a layout like the described (broken) one...

I think it's the result of mixing a radio body with other radio head, as this radio store data in this two places separately...

We are close... 73

Ha !!!

The driver is capable of recognize the band segment of the radio (K 148-174, K2 136-156) automatically and will refuse to program a radio that is not in the same sub band.

Also I need users of this radios with the complex front (a lot of buttons and no front speaker) to contact me, I need an image of this exact model to compare and mod the driver as needed (if needed).

Good news, with the Help of Tom Hayward we tested the two possible front heads for this radio, and I can tell that at a first look they are the same in the memory business.

That's a good news because I don't have to program separate functions to manage two kinds of front heads and that's saved time & efforts.

The first driver is almost done, I have to polish some issues and validate it against Chirp's test bed... I think that for the weekend we will have a patch for it on the "to release" queue.

This first driver will have only channel & banks management, no settings and no buttons; that will be in a second round.

73.

A pre-release version with full channel support and basic banks management is available for who wants to try it; if you like to try please click on my to see my email and drop me an email for driver + instructions.

73

Hi people, I'm dropping the development for this kind of radio.

I don't have access to any of this radios anymore, I have made a few attempts with the new fleet owner to borrow one of them again and no joy. The other in possession of a ham friend of mine was QRT (actually fried beyond repair) by a lightning stroke.

The partially working driver is available on request to a willing developer to finish the job. Tom Hayward was the leading person on this radios and I know he can follow the development if he have the spare time required.

73 Pavel CO7WT.

What work is remaining? I thought it was complete.

By the way, I tried opening the Kenwood .dat file with this driver and a header offset provided by my FileWrapper patch. It mostly works! The only problem is that your upper memory block starts 16 bytes earlier than in the .dat.

Hi Tom,

You have in your inbox the latest version from my side (past eamils), fell free to update it with your patch and publish at your will, I can't get one of these on my hands any more to test/play/fix/etc (at least in the foreseeable future).

All the basic features are in the driver I sent you in the past, so after tour tweaks/test it can go public.

73 Pavel CO7WT.

Keeping open until somebody can walk it the final mile.

I have a small stack of some TK-790s, I might have a little bit of time to tinker with this code a bit to get it over the line, but I'm new to the CHIRP codebase. Are people still interested in TK-790 programming?

Yes, At least I am interested. I think there are a lot of these in use in the Amateur community and folks are just getting their hands on the Kenwood software, but Chirp support would be great

I'd also be interested in further progress on the TK-790 radios. I've been working with the closely related TK-690 radios recently, and would also be interested in working on modifications to the TK-790 software to handle them as well. Is the tk790.py file from Tom Hayward in 2016 still the latest version of the code? Or is a more up-to-date implementation available somewhere?

Oh also I wonder if it's worth preserving compatibility for existing .dat files from KPG-44D? Since some of the earlier discussion indicates that the 3 blocks of memory each get read and written separately anyway, perhaps it makes sense to keep that 64 byte header, if it's present? This would make it easier to open files from KPG-44D in chirp, then export them back for modifications (perhaps for settings not yet implemented in the chirp driver), rather than deleting the metadata that KPG-44D expects.

I'm not sure if there's any precedent in chirp drivers for keeping data for compatibility with other tools, even if not written to the radio itself, or if that's generally discouraged? It would be a pretty simple modification to make, and I already implemented most of it before realizing that that data was just a header.

Patrick, note that the driver you attached appears to be something that won't work in the current version of chirp. It needs to use bytes communicating with the radio, MemoryMapBytes internally, etc. Just FYI in case you're loading and running it from the legacy build that it will take some work to get it into a format that can be acceptable.

Also, the current CHIRP has the ability to define and handle alternate file formats for your .dat case. Here is an example (see also the load_mmap() method).

Thanks for the heads up Dan. I guess that makes a lot of sense since I've been working on modifying the driver that was originally written by Pavel and Tom in 2016.

Is there a reference document somewhere on the main changes needed for migrating to properly support chirp-next?

Also thanks for the example of the alternate format, that's exactly what I needed! It looks like that example assumes a constant header layout for all files, while in this case there seems to be more metadata in the header that's specific to a given device, but that's a good starting point to work off of anyway, thanks!

There are other examples in the tree that stash the header so it can write them back if it just saves the existing file, but unless you know how to generate the header that's the best you can do.

As far as the conversions required, you can see lots of examples in the tree and git history. Getting a DevelopersPython3Environment environment installed, running tests, and the driver against the current version of CHIRP should make it clear.

That's great news, but I'd really encourage you to focus on getting it passing tests and acceptable in current chirp before expanding it further. I always prefer a minimal driver first, followed by iterative improvements.