CHIRP

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.

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.

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.

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

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.

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.')@

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.

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.

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 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.

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?

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.

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?

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.

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

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.

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

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.

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

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

Changed line 26 to chirp_common.OLD_TONES and module loaded

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.

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

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.

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

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.

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.

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