CHIRP

Pavel,

Thanks. Will set up a "portmon" in a 32-Bit Win 7 VM (and I know this VM works); will also attempt a "Serial Port Monitor" V5 dump as well from the base 64-bit system. Give me a few hours to make this happen.

Regards,

Steve I
VK3VM / VK3SIR
(direct reply vk3vm @ hotmail . com)

Dennis & Stephen,

Any logs of a serial port capture software is valid as it's setup in a way that I can get this:

• Hex dump of the data, the default is almost always ASCII, and it's worthless as non printable chars get masked by a dot.
• You can set/check the queue size for the biggest packet and it's about at least 256 bytes long, this is to not lose any byte on long packets.

Sure, I have the tools to automatically parse the portmon logs (I can even retrieve a partial radio image from it) and that makes the process a matter of minutes, but any other that meet the above points will do it, just will take more time to process.

I'm getting your file as a corrupted one, I'm downloading it for the second time... (slow internet here, sorry)

73

Hi Dennis, yup, I got the file now.

The "Dumpview" is the one, it's of no value for a new radio, but it works for this with a known comm protocol aka: I can read it.

That file told me that you have an simple KT8900 (did you see the notice in the recent version when you tied to read it?)

I put recently a comment on the last version of Chirp just for this case, update your Chirp and try to read it, this time pay attention to the error's comment...

Spoiler: It will suggest you to use the Waccom Mini8900 instead as some units of the KT8900 behave as the Waccom Mini8900.

I call this ones "early KT8900" as by now all know variants use the default protocol in Chirp for the KT8900.

Stephen, please try that also.

73 CO7WT.

Hi Pavel,

Weird, I did try both the Waccom Mini8900 as well as the KT8900. The KT8900 said that it couldn't find the radio and the Mini8900 said something about not being able to put the radio into clone mode. When using the Mini8900 it did blink the display on the radio for a second and seemed like it was going to work after.

Prior to trying, I did grab the nightly build for 5/17 and installed it. So the tests were done with the latest version I saw.

Any other ideas?

Thanks! 73

I meant that it seemed like it was going to work but did not. That's when the error about going into clone mode came up.

I'll check at the additional information on the error next time I try. I'm not in from of that laptop right at the moment.

Yes, there is a know bug about the Waccom Mini8900 and the BTECH 2501 not working on the first tries, please try it a few times.

73

Hi Folks,

oops... for some reason PortMon has NOT save it as Hex dumps... Will investigate and repost ASAP.

And NO... The WACCOM MINI-8900 does NOT WORK !

Regards,

Steve I

Stephen Ireland wrote:

Hi Folks,

[ oops... for some reason PortMon has NOT save it as Hex dumps... Will investigate and repost ASAP.... No ... double-checked... The Dumps OK... ]

And NO... The WACCOM MINI-8900 does NOT WORK !

Regards,

Steve I

Stephen Ireland wrote:

Hi All,

Sorry for the crap above... made a mistake. Attached is the "portmon" dump produced EXACTLY according to the document supplied along with the standard CPS and VIP software used to create the dump.

73

Steve I

Got it, I will process and report back later today.

73 Pavel CO7WT

Hi Pavel,

I tried The WACCOM MINI-8900 multiple times in succession with the latest version of chirp and it doesn't work at all for me.

The screen on the radio blinks as if it is going to work but then chirp says "An Error has occurred. Error reading data from radio".

No still issues... At least the Waccom selection gets closest causing the "reset" into Programming Mode... but then the detection fails. There is no radio "reset-into-programming-mode" taking place under the QYT settings.

Hi to all.

This is a known bug with the WACCOM Mini-8900 and the some of the QYT KT-8900 that is a clone of the WACCOM (or vice versa), sadly I don't have much free time lately to craft a solution now; but this task is in #1 of priority on the TODO list.

The "reset" upon programming tell me that this radios are indeed a clone of the WACCOM (as it responds to the magic code to turn it into program mode) but then we have this radios insisting on sending a misplaced byte in whatever position it likes.

I have drafted a new strategy that I need to implement and test but it (maybe, 50% chance) requires some fundamental changes on the whole driver.

Sorry for the inconvenience.

73 Pavel CO7WT.