Bug #6757

problem reading data from WLN KD-C1 - Radio identification failed - (white model)

Added by Pablo Escobar 7 months ago. Updated about 1 month ago.

Status:Feedback Start date:04/27/2019
Priority:Normal Due date:
Assignee:Jim Unroe % Done:

0%

Category:-
Target version:chirp-daily
Chirp Version:daily Platform:All
Model affected:WLN KD-C1

Description

Hello,

I am using CHIRP daily-20190424 installed from ubuntu PPA repository to configure WLN KD-C1

When I try "radio >> download from radio" I get the error message "Radio identification failed". I could workaround the problem by commenting these lines and then I can read the device configuration

The walkie that presents the problem is branded as WLN and is white. I have another pair branded as RADTEL (black color) that work perfectly fine without any workaround.

When I generate a debug log I get this:

[2019-04-27 11:14:23,374] chirp.drivers.retevis_rt22 - DEBUG: Incorrect model ID, got this:

000: 50 33 32 30 37 21 f8 ff   P3207!..

chirp.log (3.2 kB) Pablo Escobar, 04/27/2019 08:08 am

retevis_rt22_test.py (19.4 kB) Jim Unroe, 04/27/2019 10:03 am

chirp_failed_to_read_block_100.log (5.3 kB) Pablo Escobar, 04/27/2019 10:26 am

chirp_failed_to_read.log (5 kB) Pablo Escobar, 04/27/2019 10:26 am

History

Updated by Jim Unroe 7 months ago

  • Status changed from New to Feedback

Would you include the full debug.log file?

Updated by Pablo Escobar 7 months ago

I attach the full log file. thanks for looking into it.

Updated by Jim Unroe 7 months ago

  • File retevis_rt22_test.py added
  • Assignee set to Jim Unroe
  • Target version set to chirp-daily
  • Platform changed from Linux to All

Pablo,

Give this test driver a try...

1. save test driver to a convenient location
2. enable "Enable Developer Functions" in the Help menu
3. choose "Load Driver" in the File menu
4. locate and load the driver saved in step 1

Now try to download from and upload to your radio.

Note: Use of this test driver does not permanently change your CHIRP installation in any way. After you close CHIRP you will have to load this test driver again to access your radio.

Jim KC9HI

Updated by Pablo Escobar 7 months ago

I have tried your driver and I could download the first time. After this I tried to upload without doing any change and I got an error (sorry I didn't take note of this error)

After the error I can no longer download. I always get an error "failed to read block" with the new driver and also with the original driver. I attach a log file for driver

Is it safe to dump the firmware from my other walkie and copy it to this device to restore it to its original state? or how should I proceed? I did a quick test and the walkie seems to work fine.

Updated by Jim Unroe 7 months ago

Pablo Escobar wrote:

I have tried your driver and I could download the first time. After this I tried to upload without doing any change and I got an error (sorry I didn't take note of this error)

After the error I can no longer download. I always get an error "failed to read block" with the new driver and also with the original driver. I attach a log file for driver

Is it safe to dump the firmware from my other walkie and copy it to this device to restore it to its original state? or how should I proceed? I did a quick test and the walkie seems to work fine.

You can't dump the firmware for these radios using CHIRP. The firmware is not upgrade-able.

Is is safe to upload the image file from your other radio into this one? I don't know. I take it you didn't save the first successful download from this radio, right?

The only way to return this radio to its original state would be to upload the successful down from this radio. Uploading an image from another radio changes it to the state of the other radio.

I would try unplugging programming cable from computer (unplug from radio first) and plug it in again. Or you might even try rebooting computer.

In any case, this new issue is unrelated to the "Radio identification failed" problem the test driver addresses.

Jim KC9HI

Updated by Pablo Escobar 7 months ago

I have tried in windows virtual machine using the official software and I get similar problems. The software gets stuck and cannot complete to download (the download works fine with other walkies)

I tried to find if there is any way to reset the walkie to default settings but I couldn't find how to do it. I am out of ideas. It seems like the rom of the device is defective and I cannot read it? Maybe I could read it the first time just by chance?

I am going to contact the dealer

Updated by Jim Unroe 7 months ago

I tried to find if there is any way to reset the walkie to default settings but I couldn't find how to do it. I am out of ideas. It seems like the rom of the device is defective and I cannot read it? Maybe I could read it the first time just by chance?

Probably whatever prompted the change of the "radio identification" may have changed the timing slightly.

Jim

Updated by Pablo Escobar 7 months ago

Is there any workaround I could try to try to fix the timing issues?

Any similar case that is documented and I can read as reference?

Thanks in advance for any help or advice.

Updated by Heath Petty 6 months ago

I am also hitting this issue with a black model. I tried the rt21 driver, since it identifies as a P3207, but changed the initial string in the enter programming mode function to match the string in the rt22 driver:

def _rt21_enter_programming_mode(radio):
    serial = radio.pipe

    try:
        #serial.write("PRMZUNE")
        serial.write("PROGRGS")
        ack = serial.read(1)
    except:
        raise errors.RadioError("Error communicating with radio")

This read something from the radio, but it did not read the right thing because chirp threw an error:

RadioError: Failed to read block at 0100

Forging ahead, I added a frequency in channel 1, and wrote it to the radio. The write succeeded, but it changed the voice to chinese.

I don't mind hacking on this, but I'm not sure how to figure out what I need to tweak to get it to talk to this radio. Anyone have any clues?

Updated by Heath Petty 6 months ago

After some hacking around, I have it kind of working. The issue I'm still seeing is that the settings tab is not being populated after I read the config from the radio. Everything else is good.

To get the radio to a good state, I had to use the programming software here on a windows 10 virtual machine (it will also work just fine on a regular windows machine):

http://www.uv3r.com/images/RT22-programming-software.zip

Once I re did the settings (and put it back into english). I did a serial dump of a download operation. Everything seemed the same as before, just a different id. I made the following change to the chirp/drivers/retevis_rt22.py file:

I changed the line that read:

_fileid = ["P32073", "P3" + "\x00\x00\x00" + "3"]

to read:

_fileid = ["P32073", "P3" + "\x00\x00\x00" + "3", "P3207!"]

Updated by Jim Unroe 5 months ago

Retevis is sending me a current RT22 for use in troubleshooting.

Jim KC9HI

Updated by T B 4 months ago

I have newer versions of the WLN KD-C1 and HESENATE HT-U222. Both identify as P3207!. The test driver (retevis_rt22_test.py) was successful in reading and writing to both radios. Thanks for your help as these are great little UHF radios! Please let me know if I can help with any further testing.

Updated by T B 4 months ago

Writing to the HESENATE HT-U222 failed setting the radio ID. Trying to read from the updated radio would give the following:
DEBUG: Incorrect model ID, got this:

000: 04 00 05 02 ff ff f8 ff ........

I modified the test driver to the following so chirp can read the updated radio with the empty ID field:

_fileid = ["P32073", "P3" + "\x00\x00\x00" + "3", "P3207!", ""]

Updated by Bryan Murdock 3 months ago

Hi, I just got a new WLN KD-C1 radio and I too am getting the "Radio identification failed" error when I attempt to download from radio. I'm running CHIRP daily-20190718. I'm new to debugging chirp problems, but if there is anything I can do to help please let me know.

Updated by Bryan Murdock 3 months ago

Here is the debug log that I got:

[2019-08-08 22:29:36,552] chirp.logger - DEBUG: log level=10
[2019-08-08 22:29:36,552] chirp.logger - DEBUG: CHIRP daily-20190718 on Linux malo 5.2.5-arch1-1-ARCH #1 SMP PREEMPT Wed Jul 31 08:30:34 UTC 2019 x86_64 (Python 2.7.16)
[2019-08-08 22:29:36,725] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,725] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,725] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,725] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,725] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,725] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,725] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,726] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,726] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,726] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,726] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,726] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,726] chirp.ui.mainapp - INFO: Skipping existing stock config
[2019-08-08 22:29:36,727] chirp.ui.reporting - DEBUG: Checking for updates
[2019-08-08 22:29:36,855] chirp.ui.reporting - DEBUG: Server reports version daily-20190718 is latest
[2019-08-08 22:29:43,432] chirp.ui.mainapp - DEBUG: User selected WLN KD-C1 on port /dev/ttyUSB1
[2019-08-08 22:29:43,436] chirp.ui.clone - DEBUG: Clone thread started
[2019-08-08 22:29:43,437] chirp.drivers.retevis_rt22 - DEBUG: download
[2019-08-08 22:29:43,487] chirp.drivers.retevis_rt22 - DEBUG: Incorrect model ID, got this:

000: 50 33 32 30 37 21 f8 ff   P3207!..

[2019-08-08 22:29:43,489] chirp.ui.reporting - DEBUG: Reporting exception
[2019-08-08 22:29:43,489] chirp.ui.common - ERROR: -- Exception: --
[2019-08-08 22:29:43,491] chirp.ui.common - ERROR: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/chirp/ui/clone.py", line 256, in run
    self.__radio.sync_in()
  File "/usr/lib/python2.7/site-packages/chirp/drivers/retevis_rt22.py", line 331, in sync_in
    data = do_download(self)
  File "/usr/lib/python2.7/site-packages/chirp/drivers/retevis_rt22.py", line 230, in do_download
    _rt22_enter_programming_mode(radio)
  File "/usr/lib/python2.7/site-packages/chirp/drivers/retevis_rt22.py", line 139, in _rt22_enter_programming_mode
    raise errors.RadioError("Radio identification failed.")
RadioError: Radio identification failed.

[2019-08-08 22:29:43,492] chirp.ui.common - ERROR: ----------------
[2019-08-08 22:29:43,492] chirp.ui.clone - ERROR: Clone failed: Radio identification failed.
[2019-08-08 22:29:43,780] chirp.ui.clone - DEBUG: Clone thread ended
[2019-08-08 22:29:43,781] chirp.ui.reporting - DEBUG: Reporting model usage: WLN_KD-C1,download,True
[2019-08-08 22:29:43,784] chirp.ui.reporting - DEBUG: Reporting exception
[2019-08-08 22:29:43,785] chirp.ui.inputdialog - ERROR: --- Exception Dialog: Radio identification failed. ---
[2019-08-08 22:29:43,787] chirp.ui.inputdialog - ERROR: None

[2019-08-08 22:29:43,787] chirp.ui.inputdialog - ERROR: ----------------------------

Updated by Peter Goodricke about 1 month ago

Ive just got 2 new WLN KD-C1 and have connected a Saleae and between
Send P R O G S 2
Receive 6 P 3 2 0 7 ! 0XF8 0XFF

and its rejected by CHIRP
The progam as suppied from
genuine software provided by WLN at http://www.kai-li.com/uploads/KD-C1_SETUP%201.2.rar
Send PROGS PROGS
Receive 6 P3207!0XF80XFF

Also available in: Atom PDF