New Model #9816
closedNew KT-8900R fingerprint
100%
Description
Hi there,
FYI, I just bought a new KT-8900R and found it has a new fingerprint, M3B064, and it apparently does not use an extra ID.
Attached is a modified module that is working well for me.
I also added a line to enable the 12.5KHz steps in memory channels. Not sure if this was always an issue, or just in the module I'm working with.
(I found the .py module in another Issue entry for an unrelated topic)
Relevant lines are commented with my callsign, AC3MB.
Files
Updated by Jim Unroe over 2 years ago
- Status changed from New to In Progress
- Assignee set to Jim Unroe
- Target version set to chirp-legacy
Hi Matthew,
Thanks for submitting the needed information. I will try to get this submitted today.
Jim KC9HI
Updated by Jim Unroe over 2 years ago
Where did you get that old btech.py driver to modify? You must not be using a current version of CHIRP. The "step" issue was addressed back in 2019!
Jim KC9HI
Updated by Jim Unroe over 2 years ago
- File btech_M3B064.py btech_M3B064.py added
Matthew,
Are you sure that a radio with the M3B064 MCU Version doesn't have an "extra ID"? Or does it use the second "extra ID" that was added to the current driver back in September of 2021?
I'm going to assume the latter is true and attach the driver that I currently expect to submit. Would you please test it in order to confirm the second "extra ID" works with your radio? If it doesn't, attach a debug.log file that I can study.
Thanks,
Jim KC9HI
Updated by Matthew Breit over 2 years ago
Hi Jim,
Thanks for this! Your driver works fine over here. It's slower, but still very usable and it makes sense after I read the notes about the static delay.
I found the driver I posted from some other post buried in here somewhere; yes it is pretty old I see now.
(I downloaded the daily about two days ago and got the 'radio identification failed' error, which prompted my searching).
Thanks so much again!
- Matt
Updated by Jim Unroe over 2 years ago
- File btech_M3B064_fast.py btech_M3B064_fast.py added
Matthew Breit wrote:
Hi Jim,
Thanks for this! Your driver works fine over here. It's slower, but still very usable and it makes sense after I read the notes about the static delay.
I found the driver I posted from some other post buried in here somewhere; yes it is pretty old I see now.
(I downloaded the daily about two days ago and got the 'radio identification failed' error, which prompted my searching).Thanks so much again!
- Matt
Yeah... the "slower" has been a problem for a few year. Using the older driver that you were using probably predated the change that made things slow, so you never noticed.
Recently I have been making an effort to figure out what is causing the driver to be slow at uploading and try to eliminate it. A new build was released today that should help but I am even working on a better solution.
The test driver that I just attached to this issue incorporates this new method. Would you please test this and let me know if it works or fails for you. I am anxious to get this new method tested. If I can get favorable report from several volunteers I can get it submitted.
In the mean time I will submit a patch to add the M3B064 MCU Version support to CHIRP. Thank you for your help.
Jim KC9HI
Updated by Jim Unroe over 2 years ago
Matthew,
If you don't mind, would you attach a CHIRP Radio Images (*.img) file from your radio. I would have one from a KT-8900R for my files. It can be a copy of what you currently use, a "factory" image or one after the radio has been RESET. It doesn't matter to me as long as it is from a KT-8900R.
Thanks,
Jim KC9HI
Updated by Jim Unroe over 2 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
A patch has been submitted to add this new MCU Version for the KT-8900R. Support will be in the next CHIRP daily build following acceptance.
Jim KC9HI
Updated by Anonymous over 2 years ago
- Status changed from Resolved to Closed
Applied in changeset commit:4d991cdfc502.