New Model #4145
closedWLN KD-C1
Added by Steven Janssen about 8 years ago. Updated almost 5 years ago.
100%
Description
Maybe someone could try to add a driver for this radio?
I find the original software really annoying to use and they don't have a version for Mac OS.
Apparently this radio is a clone of the Zastone ZT-X6 (and also the Retevis RT22)
Best regards,
Steven
on1BSJ
Files
| KD-C1_orig.dat (1.61 KB) KD-C1_orig.dat | Steven Janssen, 10/18/2016 12:17 AM | ||
| read COM3 Monitoring Session.spm (1.17 MB) read COM3 Monitoring Session.spm | Steven Janssen, 10/18/2016 04:15 AM | ||
| write COM3 Monitoring Session.spm (129 KB) write COM3 Monitoring Session.spm | Steven Janssen, 10/18/2016 04:15 AM | ||
| html export.zip (225 KB) html export.zip | Steven Janssen, 10/20/2016 01:09 AM | ||
| retevis_rt22.py (16.8 KB) retevis_rt22.py | test driver module - please provide feedback | Jim Unroe, 11/12/2016 03:57 PM | |
| WLN_KD-C1_20161113.img (840 Bytes) WLN_KD-C1_20161113.img | Steven Janssen, 11/12/2016 05:07 PM | ||
| Zastone_ZT-X6_20161113.img (840 Bytes) Zastone_ZT-X6_20161113.img | Steven Janssen, 11/12/2016 05:07 PM | ||
| retevis_rt22.py (17.6 KB) retevis_rt22.py | test driver module #2 | Jim Unroe, 11/12/2016 08:11 PM | |
| Retevis_RT22.img (1.01 KB) Retevis_RT22.img | Jim Unroe, 11/16/2016 06:35 PM | ||
| WLN_KD-C1.img (1.01 KB) WLN_KD-C1.img | Jim Unroe, 11/16/2016 06:35 PM | ||
| Zastone_ZT-X6.img (1.01 KB) Zastone_ZT-X6.img | Jim Unroe, 11/16/2016 06:35 PM | ||
| wln_kd-c1_debug-log.txt (21.8 KB) wln_kd-c1_debug-log.txt | Jeroen PD1ODE, 11/22/2016 01:45 PM | ||
| retevis_rt22.py (17.9 KB) retevis_rt22.py | Jim Unroe, 11/22/2016 02:02 PM | ||
| wln_kd-c1_debug-log_huge.txt (78.9 KB) wln_kd-c1_debug-log_huge.txt | Jeroen PD1ODE, 11/22/2016 02:15 PM | ||
| debuglog_from_linuxpatch.txt (35.3 KB) debuglog_from_linuxpatch.txt | Jeroen PD1ODE, 11/22/2016 02:22 PM | ||
| retevis_rt22_test.py (18 KB) retevis_rt22_test.py | Jim Unroe, 11/22/2016 03:39 PM | ||
| debuglog_all_in_one_go.txt (39.7 KB) debuglog_all_in_one_go.txt | Not rebooting the radio in between | Jeroen PD1ODE, 11/23/2016 03:29 AM | |
| debuglog_poweroffon_before_reading.txt (31.9 KB) debuglog_poweroffon_before_reading.txt | Powering the radio off and on between reading | Jeroen PD1ODE, 11/23/2016 03:29 AM | |
| LUITON_LT-316.img (1.01 KB) LUITON_LT-316.img | Image provided by Luiton | Jim Unroe, 12/17/2016 04:21 PM |
Updated by Steven Janssen about 8 years ago
- File KD-C1_orig.dat KD-C1_orig.dat added
I added the data from the original radio,
Updated by Steven Janssen about 8 years ago
- File read COM3 Monitoring Session.spm read COM3 Monitoring Session.spm added
- File write COM3 Monitoring Session.spm write COM3 Monitoring Session.spm added
Adding the COM port monitoring files, one contains the data reading from the radio, the other writing to the radio.
Updated by Jim Unroe about 8 years ago
- Status changed from New to Feedback
Unfortunately those attached files are binary files and must be opened with the specific software that you use to capture them. Is there any way that you could export them as a text file, html file or some other non-specific software format?
Jim KC9HI
Updated by Steven Janssen about 8 years ago
- File html export.zip html export.zip added
Uploading the .hmtl exports:
1 = table view
2 = line view
3 = dump view
73's
Steven
Updated by Jim Unroe about 8 years ago
Much better. Especially the "dump view". Which software are you using?
I will try to study these files a bit this weekend. I may be getting access to a radio as well.
Jim KC9HI
Updated by Steven Janssen about 8 years ago
I used this soft:
http://www.eltima.com/products/serial-port-monitor/
And I bought this radio for about 14$ on ebay, they work very well for that money.
73's
Seven, on1bsj
Updated by Steven Janssen about 8 years ago
Looking at the file, I just figured out that digits 2 & 3 contain the memory number, 5 - 8 the rx frequency from right to left, 9 - 12 the tx frequency and 13 - 16 the rx and tx the tone squelch settings...
For example:
57 00 10 10 00 75 28 45 00 75 28 45 39 03 39 03 00 30 00 00
01 45287500 * 45287500 ?CTCSS?
Updated by Jeroen PD1ODE about 8 years ago
I have been sniffing the radio as well and found a few nice pointers!
My work: https://gist.github.com/anonymous/7546b64d6a53d2372c9dc2111edbd39d and https://revspace.nl/WLN_KD-C1
This radio identifies itself as "P32073".
The KYD NC-630A has the same identification, and looks like it has the same set of features (16 channels, 400-520MHz).
It has been added to CHIRP a while back http://chirp.danplanet.com/issues/1525
However this radio requires "PROGRGS" to go into programming mode, not "PROGRAM" as the KYD...
Yet the \x06 looks like device ack, and the \x02 host ack, letter 'E' for End programming mode, same BCD memory banks, etc etc.
My first step would be editing the KYD NC-630A code to send out PROGRGS to get the WLN into programming mode.
Updated by Jim Unroe about 8 years ago
I received an RT22 from Retevis and have been looking at it when I have time.
Jim
Updated by Jim Unroe about 8 years ago
- File retevis_rt22.py retevis_rt22.py added
- Assignee set to Jim Unroe
- Target version set to 0.5.0
- % Done changed from 0 to 90
I finally got downloads and uploads working today. After that, the rest was fairly easy.
The attached driver module should work for a WLN KD-C1, Zastone ZT-X6 and Retevis RT22. Give it a try and provide some feedback.
To use the attached driver module...
Save the driver module to where you keep your CHIRP Radio Images (*.img) files.
Enable "Enable Developer Functions" in the Help menu.
Select "Load Module" in the File menu to locate and load the driver module you saved previously.
This driver module does not permanently change your CHIRP installation. It will have to be loaded every time you load CHIRP.
I would very much like to look at at images saved from KD-C1 and ZT-X6 radios. Please attach them to this issue.
Jim KC9HI
Updated by Steven Janssen about 8 years ago
- File WLN_KD-C1_20161113.img WLN_KD-C1_20161113.img added
- File Zastone_ZT-X6_20161113.img Zastone_ZT-X6_20161113.img added
Hi,
Adding the images of both the KD-C1 and ZT-X6 radios,
Writing back the image to the radioq gives me an error Failed to send block to radio at 0320
I'll have a deeper look tomorrow,
73's Steven on1bsj
Updated by Jim Unroe about 8 years ago
- File retevis_rt22.py retevis_rt22.py added
I believe this driver module takes care of the "Failed to send block to radio at 0320" error. Apparently the radio stop "ACKing" the data blocks after so many characters. I had to more closely simulate how the "factory" software downloads and uploads.
So this changes the file size of the CHIRP Radio Images (*.img) file (it is bigger). In other words, you will have to download from the radio again and save it. The earlier (smaller) files will no longer be detected.
I also added the Embedded Messages settings.
Jim
Updated by Steven Janssen about 8 years ago
I'll do some more testing this afternoon but at the first looks everything seems to work perfectly now with the new driver,
thank you for your fine work Jim
73"s Steven, on1bsj
Updated by Jim Unroe about 8 years ago
- File Retevis_RT22.img Retevis_RT22.img added
- File WLN_KD-C1.img WLN_KD-C1.img added
- File Zastone_ZT-X6.img Zastone_ZT-X6.img added
I have attached 3 images to be added to the repository.
Updated by Jim Unroe about 8 years ago
- Status changed from Feedback to In Progress
- % Done changed from 90 to 100
A patch to add support for the Retevis RT22, WLN KD-C1 and Zastone ZT-X6 has been submitted.
Jim KC9HI
Updated by Jeroen PD1ODE about 8 years ago
I have successfully downloaded from the WLN. Once. Now I only get "No ACK reading block 03c0.", "block 00c0.", "block 0100.", "block 0040.", "block 0240.".
Combination of power-cycling the radio and downloading the configuration again does not help. Neither does fiddling with the original programming to get it into programming mode/etc.
Updated by Jeroen PD1ODE about 8 years ago
Oh, so far no problems with uploading an image towards the radio with your provided .img!
Updated by Vladimir Kondratiev about 8 years ago
There is inconsistency regarding frequencies for RT22:
accordingly to manual, it is 400..470 MHz; spec on site says 400..480 MHz, while driver defines:
rf.valid_bands = [(400000000, 520000000)]
I think upper bound should be set to 480 or 470, but not 520
Updated by Jim Unroe about 8 years ago
- Status changed from In Progress to Feedback
It is not unusual for there to be an inconsistency between the specifications and manuals of these Chinese two-way radio products. The driver was set to 400-520 because that is what the factory programming software supports.
Jim KC9HI
Updated by Steven Janssen almost 8 years ago
Hi,
I just installed the daily 20161122, both Zastone and WLN radios give me the error 'Radio refused to enter programming mode' when reading.
73's Steven on1bsj
Updated by Jim Unroe almost 8 years ago
- Status changed from Closed to Feedback
It works OK for me. How about a debug.log file?
The one thing that I did change from the earlier tests was to remove the 5 tries that CHIRP makes to get cloning to start. It was so reliable here that I reduced it to a single try like most other drivers.
Once you get the error, power the radio off, then back on and try again to see if it goes.
Jim
Updated by Jeroen PD1ODE almost 8 years ago
- File wln_kd-c1_debug-log.txt wln_kd-c1_debug-log.txt added
Powering off the radio and trying again was not sufficient. Tried with two WLN's. both unable to read the memory.
I included the log file.
Updated by Jim Unroe almost 8 years ago
- File retevis_rt22.py retevis_rt22.py added
I think Linux is sending too fast for the radio. CHIRP reads a few blocks and then the radio stop ACKing.
Try the attached file with File > Load Module (you'll need Help > Enable Developer Functions checked).
Report back the results of your test.
Jim KC9HI
Updated by Jeroen PD1ODE almost 8 years ago
Another logfile
Updated by Jeroen PD1ODE almost 8 years ago
Whoops, thats the old file. Here is another log file from the latest module.
There are no hex-dumps?
Will check later tonight/tomorrow.
Updated by Jim Unroe almost 8 years ago
- File retevis_rt22_test.py retevis_rt22_test.py added
Jeroen,
I went into my Linux computer and gave it a try. It worked fine except I have to download twice to get it to start. So I added back in the code to have CHIRP try 5 times.
As far as the debug.log file goes, it doesn't make sense that with the original driver CHIRP successfully download load 5 or so blocks before the error occurs. That last debug.log shows that the clone process doesn't even download the first block. I wouldn't have thought the change I made would have affected that.
So attached is the file the I added the "tries". I also added a small delay between the start of each block. Try it a let me know what happens.
Jim
Updated by Jeroen PD1ODE almost 8 years ago
- File debuglog_all_in_one_go.txt debuglog_all_in_one_go.txt added
- File debuglog_poweroffon_before_reading.txt debuglog_poweroffon_before_reading.txt added
Hi Jim,
I tried your latest .py module. No luck, see included log files.
Will check on Windows.
Updated by Jim Unroe almost 8 years ago
Hi Jeroen,
With the addition of the "tries" I am unable to get it to fail where with my Windows 7 64-bit computer and Linux Mint 17.3 computer.
You debug logs show that you have gotten a failure on the very first block and sometimes as read all the way to 4 blocks before not receiving an ACK from the radio.
Have you used this programming cable cable with other radio models? Do you have someone that you can borrow another programming cable from?
Also, give the retevis_rt22.py driver from post #12 a try and report back.
Jim
Updated by Jeroen PD1ODE almost 8 years ago
Hi Jim,
I just tried with the latest windows build (20161122), and the version over there seems to work after one initial "Failed to enter programming mode". After that first message you can read again and it works flawlessly. I tried reading a few times in a row (ten times) and this also works just fine.
However I did have to cheat the prolific usb to serial driver... Original prolific drivers gives "code 10" generic failure (counterfeit chip, obviously). So some shady old driver had to be installed.
The same programming cable works under GNU/Linux Debian with Wine, original software. I will try the .py driver from post 12 later today.
Awesome work!
Jeroen
Updated by Jim Unroe almost 8 years ago
- File LUITON_LT-316.img LUITON_LT-316.img added
Attached is a LUITON LT-316 "image" file that can be used for the CHIRP "tests".
Updated by Bernhard Hailer almost 5 years ago
- Status changed from Feedback to Closed
This appears to be complete.