Bug #4993

QYT KT-8900 extra ID wrong

Added by William Besore 5 months ago. Updated 20 days ago.

Status:Feedback Start date:07/09/2017
Priority:Normal Due date:
Assignee:Jim Unroe % Done:

0%

Category:-
Target version:0.5.0
Chirp Version:daily Platform:All
Model affected:QYT KT-8900

Description

Chirp would not communicate with the radio because of a passcode in the radio. Jim provided a work around with a .py file.

Associated revisions

Revision 2912:c56244c58fe8
Added by Jim Unroe 5 months ago

[KT8900] Extra ID Doesn't Match

When a QYT KT8900 radio has had a passcode stored in it by the factory
software, the 'extra ID' will not match the string that CHIRP expects to see.

This patch relaxes the check by removing what are apparently the passcode
bytes from the string that CHIRP expects to see in the 'extra ID'.

Bug #4993

History

Updated by Jim Unroe 5 months ago

  • Assignee set to Jim Unroe
  • Target version set to 0.5.0
  • Chirp Version changed from 0.4.0 to daily
  • Platform changed from Windows to All

Updated by Pavel Milanes 5 months ago

Hi to all.

This can be a sign that we have a new version of this radios on the wild.

Can you provide a serial log for it? (know how to do it here http://chirp.danplanet.com/attachments/2257/how%20to%20portmon.doc)

Make a patch/fix for this is easy, just remove the spaces in the second ID for the QYT KT-8900 as it is matched with a "if radio._id2 not in id2"

But a peek in the serial log will provide (maybe) more intel about it to pin-point some other clues that may lay in the former space filled area od the id2.

73 de Pavel CO7WT.

Updated by William Besore 5 months ago

Sorry, but my computer is windows 10 on a 64 bit system. So, I can not generate the serial log you requested.

This KT-8900 is about 1 year old. I got it from a friend. There is a startup menu function available to enter a "passcode" into the radio. This passcode ends up being the "extra ID wrong" that chirp does not like. I have not been able to find a way to null out the passcode. The radio insists that six characters be entered before it will process the passcode and go on to normal operation.

Thanks for a great software package and outstanding support.

K0WB - Bill

Updated by Jim Unroe 5 months ago

  • Status changed from New to Feedback

Pavel Milanes wrote:

Make a patch/fix for this is easy, just remove the spaces in the second ID for the QYT KT-8900 as it is matched with a "if radio._id2 not in id2"

Pavel,

I had already sent Bill a test driver with this change so he could test it. Once he confirmed that it worked as expected, I had him open this issue so I could submit a patch against it. It was too late for me to do it last night, so I planned on doing it after I got home work today.

Jim KC9HI

Updated by Jim Unroe 5 months ago

William Besore wrote:

There is a startup menu function available to enter a "passcode" into the radio. This passcode ends up being the "extra ID wrong" that chirp does not like. I have not been able to find a way to null out the passcode. The radio insists that six characters be entered before it will process the passcode and go on to normal operation.

Good info. That sheds some light on what the "second ID" is used for. Since CHIRP ignores any passcode, really isn't any need to match anything. All CHIRP really needs to do is check to see that 16 bytes have been returned and continue if they have.

Jim

Updated by giuseppe bonaccorso 20 days ago

HI all,
I have an SURECOM KT8900D and me too don't communicate with CHIRP (last version CHIRP daily-20171104).
With the original software there is not problem to connect to the radio.
what can I do?
My MTU-Version is VC4284
thanks in advance
IW2-DRU

Also available in: Atom PDF