New Model #217

Kenwood TS-2000

Added by James Beckner over 8 years ago. Updated about 5 years ago.

Status:Closed Start date:06/13/2012
Priority:Normal Due date:
Assignee:Tom Hayward % Done:

50%

Category:-
Target version:-
Chirp Version:daily Equipment Loan Offered:No

Description

Hello, was wondering if this software would be able to support the TS-2000?

Is anyone working on this know?

Have a great day.

James KC9KTV

ts2000.py (7.1 kB) Tom Hayward, 07/05/2012 10:34 am

debug.log - Debug file (4.4 kB) Anthony Cash, 07/25/2012 09:22 pm

debug.log (5.7 kB) Anthony Cash, 07/26/2012 08:19 pm

10-21-2012 4-54-28 PM.jpg (89.4 kB) Anthony Cash, 10/21/2012 02:06 pm

ts2000.py (7.1 kB) Charles Stewart, 03/24/2015 09:15 pm

kenwood_live.py - Refactored kenwood_live.py driver (43.5 kB) Charles Stewart, 03/25/2015 08:50 pm

ts2000.py - Semi-fixed ts2000.py driver (7.2 kB) Charles Stewart, 03/25/2015 08:50 pm

kenwood_live.py - latest update (43.7 kB) Charles Stewart, 03/27/2015 07:49 pm

ts2000.py - read/write capable driver, split mode operation broken (7.5 kB) Charles Stewart, 03/27/2015 07:49 pm

ts2000.py - Feature complete revision. Split mode VFO and deleting channels working. (10.4 kB) Charles Stewart, 03/28/2015 08:15 pm


Related issues

duplicated by Bug #260: TS-2000 Rejected 07/24/2012
duplicated by Bug #669: ham please firmware Rejected 03/06/2013

Associated revisions

Revision 2546:e5c23688bffb
Added by Charles Stewart almost 6 years ago

[ts2000] Add support for Kenwood TS-2000 with style fixes. Fixes #217

History

Updated by Tom Hayward over 8 years ago

  • Status changed from New to In Progress
  • Assignee set to Tom Hayward
  • Target version set to 0.3.0
  • % Done changed from 0 to 50

I've started writing support for the TS-2000 based on the CAT documentation in the manual, but progress is currently stalled as I have no radio to test with.

Updated by Tom Hayward over 8 years ago

  • File ts2000.py added
  • Status changed from In Progress to Blocked

This is blocked until someone with a radio can test it. Use the Load Module feature in Chirp developer mode to load the attached file.

Updated by Anthony Cash over 8 years ago

I just joined this group/bug whatever it is and I love the CHIRP program and would love to see
it working with my TS-2000, so bare with me because I am not familiar with the format of this
bug reporting form but I would be glad to help in testing CHIRP with the TS-2000.
I just downloaded and loaded the TS-2000 module into CHIRP and have not had any luck with it.
First of all CHIRP doesn't recognize the com ports (COM2 and COM14) where the TS-2000 is. I have
a microHAM micro KEYER which creates 2 virtual serial ports where the TS-2000 can be located on
one or both of the ports, I have it assigned to COM3 and COM14 because I usually run 2 different
programs that access the TS-2000 at the same time. CHIRP NEVER sees COM14 and only sees COM2 about
half the time. When it does see the com port and I click OK to download from the radio, NOTHING
happens, no error message and no download.
________________________________

Updated by Tom Hayward over 8 years ago

Please post your debug log.

This is a partial implementation intended to give a head start to other developers. I don't expect it to be completely functional, but it should at least detect the radio.

Updated by Dan Smith over 8 years ago

Tony,

I expect the ability to open COM3 or not is related to other stuff having the port open already. CHIRP tests for presence of a port by trying to open it. If it doesn't show up in the list, then that means CHIRP can't open it (for some reason unrelated to CHIRP itself).

For COM14, you can type that into the box directly and attempt to open that port.

However, I'd highly recommend that you try connecting directly to the radio (without your microHAM) for debugging purposes. It takes a few variables out of the equation.

Updated by Anthony Cash over 8 years ago

Tom Hayward wrote:

Please post your debug log.

This is a partial implementation intended to give a head start to other developers. I don't expect it to be completely functional, but it should at least detect the radio.

What is the name of the debug log? Where is is stored? I am running Windows 7 Ultimate 64 bit

Updated by Anthony Cash over 8 years ago

Dan Smith wrote:

Tony,

I expect the ability to open COM3 or not is related to other stuff having the port open already. CHIRP tests for presence of a port by trying to open it. If it doesn't show up in the list, then that means CHIRP can't open it (for some reason unrelated to CHIRP itself).

For COM14, you can type that into the box directly and attempt to open that port.

However, I'd highly recommend that you try connecting directly to the radio (without your microHAM) for debugging purposes. It takes a few variables out of the equation.

I know the COM port is not open by anything else bucause I can connect to the TS-2000 using it with other programs.
As for the microHAM, I have never had any other program fail to connect to the TS-2000 using it's serial ports.

Updated by Anthony Cash over 8 years ago

Anthony Cash wrote:

Tom Hayward wrote:

Please post your debug log.

This is a partial implementation intended to give a head start to other developers. I don't expect it to be completely functional, but it should at least detect the radio.

What is the name of the debug log? Where is is stored? I am running Windows 7 Ultimate 64 bit

Ok, I found it and have attached the debug.log file.

Updated by Anthony Cash over 8 years ago

OK, I have bypassed the microHAM and using native serial port com1, still can not download from the radio.
I am uploading a new debug.log

Updated by Tom Hayward over 8 years ago

Anthony,

It appears you still have some issues with your serial port. This was in the debug log:

could not open port COM1: (5, 'CreateFile', 'Access is denied.')

Updated by Anthony Cash over 8 years ago

Tom Hayward wrote:

Anthony,

It appears you still have some issues with your serial port. This was in the debug log:

could not open port COM1: (5, 'CreateFile', 'Access is denied.')

Nope, I tried it with other programs and it worked fine There must be some problem with CHIRP's
Serial port access protacol, maybe timing issue. I also tried differend serial port speeds on the
radio, sitll no go.

Updated by Anthony Cash over 8 years ago

Nope, I tried it with other programs and it worked fine There must be some problem with CHIRP's
Serial port access protacol, maybe timing issue. I also tried differend serial port speeds on the
radio, sitll no go.
I will try the same serial port with my VX-5R on Saturday.

Updated by Dan Smith over 8 years ago

Anthony,

Can you set the radio's data rate to 9600? Please do that, close out of CHIRP completely, reset the radio, reboot your computer (just to be sure), and then try again.

Tom, he's getting something from the radio during the initial rate probing, and it looks like maybe it's getting hung up after that fails a first time. Since the probe tries 9600 first, I figure trying with that for starters might get us somewhere.

Updated by Anthony Cash over 8 years ago

Dan Smith wrote:

Anthony,

Can you set the radio's data rate to 9600? Please do that, close out of CHIRP completely, reset the radio, reboot your computer (just to be sure), and then try again.

Tom, he's getting something from the radio during the initial rate probing, and it looks like maybe it's getting hung up after that fails a first time. Since the probe tries 9600 first, I figure trying with that for starters might get us somewhere.

Dan,
Ok, Just tried 9600 baud and still no go.
I also tried the pickest programs that I know of as far as timing, serial ports etc (the Kenwood MCP-2000 and ARCP-2000 programs) and both works first time every time on the same serial port, speed, etc. I also use Ham Radio Deluxe and DXBase on a daily basic and they both connect and work perfect all the time. There has to be something wrong in the CHIRP TS-2000 module. I have used CHIRP with my Yaesu VX-5R and BaoFeng UV-5R and they both work good with my setup. But I am not a programmer so I have to leave it to ya'll to figure out the programming end HI.

Updated by Anthony Cash over 8 years ago

Anthony Cash wrote:

Dan Smith wrote:

Anthony,

Can you set the radio's data rate to 9600? Please do that, close out of CHIRP completely, reset the radio, reboot your computer (just to be sure), and then try again.

Tom, he's getting something from the radio during the initial rate probing, and it looks like maybe it's getting hung up after that fails a first time. Since the probe tries 9600 first, I figure trying with that for starters might get us somewhere.

Dan,
Ok, Just tried 9600 baud and still no go.
I also tried the pickest programs that I know of as far as timing, serial ports etc (the Kenwood MCP-2000 and ARCP-2000 programs) and both works first time every time on the same serial port, speed, etc. I also use Ham Radio Deluxe and DXBase on a daily basic and they both connect and work perfect all the time. There has to be something wrong in the CHIRP TS-2000 module. I have used CHIRP with my Yaesu VX-5R and BaoFeng UV-5R and they both work good with my setup. But I am not a programmer so I have to leave it to ya'll to figure out the programming end HI.

Any updates on this?

Updated by Tom Hayward over 8 years ago

Anthony Cash wrote:

Any updates on this?

We are waiting for someone with a TS-2000 to debug the code. I know there is at least one TS-2000 owner subscribed to the chirp-devel list, but he hasn't yet found the time.

Updated by Anthony Cash over 8 years ago

Tom Hayward wrote:

Anthony Cash wrote:

Any updates on this?

We are waiting for someone with a TS-2000 to debug the code. I know there is at least one TS-2000 owner subscribed to the chirp-devel list, but he hasn't yet found the time.

Well, I am not a coder but IF I have what it takes to debug the code I would be glad to help. I have a TS-2000 and a computer, what else do I need?

Updated by Tom Hayward over 8 years ago

You might try communicating with the TS-2000 with a terminal emulator to figure out the correct settings to get it to respond to the ID command.

Updated by Anthony Cash over 8 years ago

Tom Hayward wrote:

You might try communicating with the TS-2000 with a terminal emulator to figure out the correct settings to get it to respond to the ID command.

The only thing you should need to get it to respond is the ID command in the format "ID;" and it should answer with "019" according to the manual

ID Reads the transceiver ID number.

Parameters: P1

Read Command = ID;

Answer ID P1 P1 P1 ; (where P! P! P1 = 019

Updated by Tom Hayward over 8 years ago

  • Target version deleted (0.3.0)
  • Chirp Version changed from 0.2.2 to 0.2.3

Removing target version as I have no idea when this will be completed.

Anthony, I read the manual too. That's what this driver is doing, but you report that it's not working. I was asking you to test and confirm that this works as described in the manual with your radio, because so far it seems that it doesn't work.

Updated by Anthony Cash over 8 years ago

OK, I finally found a little program that I could use to do this and here are the results. The ID command works just find and returns a value of 019.
you can see the connection parameters in the attached screen shot. Well I don't think I know how t attach or insert a .jpg file into this site so here are the
parameters. COM 14 8 N 1 57600 baud RTS, It actually worked with RTS only or RTS and CTS or None of these checked but I know I usually have to run a program with CTS only asserted when I use 57600 baud.

Updated by Anthony Cash over 8 years ago

Anthony Cash wrote:

OK, I finally found a little program that I could use to do this and here are the results. The ID command works just find and returns a value of 019.
you can see the connection parameters in the attached screen shot. Well I don't think I know how t attach or insert a .jpg file into this site so here are the
parameters. COM 14 8 N 1 57600 baud RTS, It actually worked with RTS only or RTS and CTS or None of these checked but I know I usually have to run a program with RTS only asserted when I use 57600 baud.

Updated by Tom Hayward almost 8 years ago

  • Chirp Version changed from 0.2.3 to daily
  • Equipment Loan Offered set to No

Updated by Bill Crossley almost 7 years ago

Hi developers,

I would like to help get this feature implemented and this bug closed out.

I just bought a shiny new ts-2000 that I'd be happy to test with. I also happen to be an experienced software developer with lots of experience related to serial communications, so I am cautiously optimistic that I can figure out whatever else remains to be fixed with the ts-2000 module.

My main development machine is running Linux, but I can also do Windows 7 if need be. Just need to know where to start.

73,

Bill

Updated by Tom Hayward almost 7 years ago

Take a look at Developers for basic information on getting started with Chirp development.

As a developer, you'll probably appreciate looking at source code. source:chirp/kenwood_live.py and the ts2000.py file attached to this issue should be helpful.

Updated by Ted Nelke over 6 years ago

Unable to load module: 'module' object has no attribute 'OLD_TONES'

when I tried to load the current TS-2000 module.

Updated by Ted Nelke over 6 years ago

Changed line 26 to chirp_common.OLD_TONES and module loaded

Updated by Tom Hayward over 6 years ago

If by current you mean partially-complete work-in-progress from 2 years ago, then I'm not too surprised it doesn't load cleanly.

Updated by Johan Adler over 6 years ago

I too have one of these now, a TS-2000E, no 23 cm module inside, European model.

Any progress, Ted? Any news from you, Tom?

73 SA0CLI, Johan

Updated by Charles Stewart almost 6 years ago

I've got a TS-2000 handy for testing. I'm able to get the module to load, but there's an issue with the character used for the command message separator. Looks like the Kenwood HT and mobiles use '\r' as the command separator, but the TS-2000 uses ';' as the message separator. Some of the issue appears to be in kenwood_live.py, but I haven't successfully gotten the driver to get the radio ID properly due to this issue.

Looks like the directory structure of chirp changed since this was last looked at. Incorporated Ted's change in this diff.

--- ts2000.py 2015-03-25 00:08:32.159163700 -0400
+++ ts2000.py.new 2015-03-25 00:07:25.293885100 -0400
@ -13,7 +13,8 @ # You should have received a copy of the GNU General Public License # along with this program. If not, see <http://www.gnu.org/licenses/>.

-from chirp import chirp_common, directory, kenwood_live
+from chirp import chirp_common, directory
+from chirp.drivers import kenwood_live

TS2000_SSB_STEPS = [1.0, 2.5, 5.0, 10.0]
TS2000_FM_STEPS = [5.0, 6.25, 10.0, 12.5, 15.0, 20.0, 25.0, 30.0, 50.0, 100.0]
@ -23,7 +24,7 @
TS2000_MODES = ["?", "LSB", "USB", "CW", "FM", "AM",
"FSK", "CR-R", "?", "FSK-R"]
TS2000_TMODES = ["", "Tone", "TSQL", "DTCS"]
-TS2000_TONES = list(kenwood_live.OLD_TONES)
+TS2000_TONES = list(chirp_common.OLD_TONES)
TS2000_TONES.remove(69.3)
@directory.register

Updated by Charles Stewart almost 6 years ago

Ok, I was able to get the TS-2000 to ID as ID019;, but the kenwood_live.py ID parser expects space separated. TS-2000 appears to not have space separated commands at all and depends on message definitions in their manual to determine field spacing in requests/responses. I'll need to make some edits to kenwood_live.py that first detects the type of separator in use while detecting baudrate, and modify the ID response code to handle the TS-2000 special case as well as the no space separated response.

Updated by Charles Stewart almost 6 years ago

Ok, have the radio IDing to the kenwood_live driver properly, and modified it to correctly detect the command delimiters in use at the time it detects the baud rate. There were some exceptions and cleanups to make, but I'm able to read the memory from my TS-2000 successfully. Unfortunately, I have some characters in the channel names that chirp rejects (notably '-'), so I am not yet able to successfully write the memory bank back to the radio as a test.

Updated by Tom Hayward almost 6 years ago

Do something like this to set the acceptable characters:

    def get_features(self):
        rf = chirp_common.RadioFeatures()
        ...
        rf.valid_characters = chirp_common.CHARSET_ASCII
        return rf

Updated by Charles Stewart almost 6 years ago

Thanks for the tip! I did some more work after this, and there's a few additional issues.

- There's an issue with DCS codes, and I need to follow up with checking the PL/CTCSS tones output from the read operation, too. I have a simplex channel with a 243 DCS code that shows up incorrectly, so need to investigate how those values are decoded/encoded and fix it for TS-2000.
- Reading a channel with a ' ' was causing an issue with detecting a split memory channel. I was able to get that memory to read properly after disabling the split detection logic, but I need to program a split VFO setting into a memory to see how to properly detect split operation in the driver code.
- Memory channels with a ';' character in the name only return the string up to the ';'. This appears to be an issue with the TS-2000 because verifying with minicom shows that's exactly what the radio sends and isn't an issue with the driver.
- Writing a new, unnamed channel for 146.520,00 MHz to the radio memory is throwing an error because TS-2000 is returning '?;' in response to the memory write command. Need to trace this and debug the command with minicom to figure out what chirp needs to send.

So far, detecting the radio type from kenwood_live is working, I'm able to get it to ID properly, and I'm able to read the memories. Close, very close.

Updated by Charles Stewart almost 6 years ago

Charles Stewart wrote:

Thanks for the tip! I did some more work after this, and there's a few additional issues.

- There's an issue with DCS codes, and I need to follow up with checking the PL/CTCSS tones output from the read operation, too. I have a simplex channel with a 243 DCS code that shows up incorrectly, so need to investigate how those values are decoded/encoded and fix it for TS-2000.
- Reading a channel with a ' ' was causing an issue with detecting a split memory channel. I was able to get that memory to read properly after disabling the split detection logic, but I need to program a split VFO setting into a memory to see how to properly detect split operation in the driver code.
- Memory channels with a ';' character in the name only return the string up to the ';'. This appears to be an issue with the TS-2000 because verifying with minicom shows that's exactly what the radio sends and isn't an issue with the chirp driver.
- Writing a new, unnamed channel for 146.520,00 MHz to the radio memory is throwing an error because TS-2000 is returning '?;' in response to the memory write command. Need to trace this and debug the command with minicom to figure out what chirp needs to send.

So far, detecting the radio type from kenwood_live is working, I'm able to get it to ID properly, and I'm able to read the memories. Close, very close.

Updated by Charles Stewart almost 6 years ago

Got read/write functionality working. Split offset mode is still broken, but I'll look at that later this weekend.

The tip about ASCII helped a lot. The DTCS issue was related to PL/CTCSS tone indexes being 1 indexed by the radio but DTCS was 0 indexed. The write was caused by a double channel number in the serial command to the radio, so removed the part adding it to the memory spec for writing out and just have it in the memory write command function. The memory write command sets the channel name, so removed the part setting the channel name through the separate function.

One quirk is that writing a memory channel you currently have selected, the TS-2000 will not update the radio panel unless you tune off and tune back to that memory channel. Not what I'd consider a major bug, and the split mode is more important.

Updated by Charles Stewart almost 6 years ago

Ok, only changes to ts2000.py this time.

Got deleting channels and split mode operation working. I added a feature to reset the memory recall if on the channel that's being programmed. Could add a bit to deal with main/sub receivers, but that's a lot more work than I mean to get into.

Stick a fork in it. It's done.

Updated by Alex Perez about 5 years ago

This sounds complete, so shouldn't the ticket be closed?

Updated by Tom Hayward about 5 years ago

  • Status changed from Blocked to Closed

Alex Perez wrote:

This sounds complete, so shouldn't the ticket be closed?

Sure.

Also available in: Atom PDF