Hi Ron:

Sorry for the problem. I am not sure what happened. We didn't make any change to the radio interfaces in .38. There was a change mid-.37 to fix some Icom issues, but that shouldn't have affected the K3.


Is anyone else using the K3 on .38?

The error message indicates that the Com port object is not getting created. Look in the Windows device manager under Ports Com & LPT and make sure that the device is shown. However, if the port were not there you would get another error earlier in the process.


Please do this for me:


Install .37 and see if it still works. If it does, capture some Com port data for me. See
http://www.hosenose.com/...a-Logging.aspx#post8878

Install .38 again. Assuming it still doesn't work, capture some more com port data for me.


Tnx & 73,

Dennis WN4AZY

I noticed that the "Set Rig" function works the way it should, despite the fact that the frequency box in the rig control window reads 0.000000 and none of the buttons work. That's OK, since the only thing I use the rig control function for is to set the frequency and mode from the Spot Log.

The COM port I'm using is a virtual port. The RCForb client creates a virtual K3 on port 45 which is 'paralleled' to port 44. Port 44 is used by LOGic. Although it's complicated, it has always worked well in the past.

Ron N6IE

Just dropped back to .37 and it does not work either. No error messages.

Ron N6IE

Ok, do you remember if .36 worked? If so, try that.


And please get me a com port data log on .38.
http://www.hosenose.com/...a-Logging.aspx#post8878

Tnx & 73,

Dennis WN4AZY

I'm trying to attach the com log, but not having much success. For the most part, it looks like this:

8-10-23 20:16:16.06 LogComment
18-10-23 20:16:16.06 LogComment ------------------------------------------------------------------------------
18-10-23 20:16:16.06 LogComment LOGic Version: 9.1.38
18-10-23 20:16:16.06 LogComment Class: elecraft_k3
18-10-23 20:16:16.06 LogComment Module: rigifc9.vcx
18-10-23 20:16:16.06 LogComment Descr: Elecraft K3, Smart SDR
18-10-23 20:16:16.06 LogComment Notes:
18-10-23 20:16:16.06 LogComment Ifc#: 55
18-10-23 20:16:16.06 LogComment Address (hex):
18-10-23 20:16:16.06 LogComment Poll: May poll
18-10-23 20:16:16.06 LogComment Poll interval: 1000
18-10-23 20:16:16.06 LogComment Port: COM44
18-10-23 20:16:16.06 LogComment Baud: 38400
18-10-23 20:16:16.06 LogComment Stop Bits: 1
18-10-23 20:16:16.06 LogComment DTR: False
18-10-23 20:16:16.06 LogComment RTS: False
18-10-23 20:16:16.06 LogComment Overlapped: False

18-10-23 20:17:32.22 Write AI0;
18-10-23 20:17:32.22 tx WriteBinary 41 49 30 3B
18-10-23 20:17:32.22 LogComment RThreshold set to 1. It was 0
18-10-23 20:17:32.22 LogComment RThreshold set to 0. It was 1
18-10-23 20:17:32.23 rx DiscardInBuffer
18-10-23 20:17:32.23 Write IF;
18-10-23 20:17:32.23 tx WriteBinary 49 46 3B
18-10-23 20:17:32.23 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:35.06 rx DiscardInBuffer
18-10-23 20:17:35.06 Write IF;
18-10-23 20:17:35.06 tx WriteBinary 49 46 3B
18-10-23 20:17:35.06 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;
18-10-23 20:17:35.06 rx DiscardInBuffer
18-10-23 20:17:35.06 Write IF;
18-10-23 20:17:35.06 tx WriteBinary 49 46 3B
18-10-23 20:17:35.07 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;
18-10-23 20:17:35.07 rx DiscardInBuffer
18-10-23 20:17:35.07 Write IF;
18-10-23 20:17:35.07 tx WriteBinary 49 46 3B
18-10-23 20:17:35.07 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:36.16 rx DiscardInBuffer
18-10-23 20:17:36.16 Write IF;
18-10-23 20:17:36.16 tx WriteBinary 49 46 3B
18-10-23 20:17:36.16 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:37.16 rx DiscardInBuffer
18-10-23 20:17:37.16 Write IF;
18-10-23 20:17:37.16 tx WriteBinary 49 46 3B
18-10-23 20:17:37.16 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:38.17 rx DiscardInBuffer
18-10-23 20:17:38.17 Write IF;
18-10-23 20:17:38.17 tx WriteBinary 49 46 3B
18-10-23 20:17:38.18 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:39.19 rx DiscardInBuffer
18-10-23 20:17:39.19 Write IF;
18-10-23 20:17:39.19 tx WriteBinary 49 46 3B
18-10-23 20:17:39.19 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:40.20 rx DiscardInBuffer
18-10-23 20:17:40.20 Write IF;
18-10-23 20:17:40.20 tx WriteBinary 49 46 3B
18-10-23 20:17:40.20 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:41.22 rx DiscardInBuffer
18-10-23 20:17:41.22 Write IF;
18-10-23 20:17:41.22 tx WriteBinary 49 46 3B
18-10-23 20:17:41.22 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:42.23 rx DiscardInBuffer
18-10-23 20:17:42.23 Write IF;
18-10-23 20:17:42.23 tx WriteBinary 49 46 3B
18-10-23 20:17:42.23 rx ReadTo ; IF00014078000 퍍㓓 0002000001 ;

18-10-23 20:17:43.25 rx DiscardInBuffer
18-10-23 20:17:43.25 Write IF;
18-10-23 20:17:43.25 tx WriteBinary 49 46 3B

Thanks for posting the log.

I have actually seen this problem before -- from one of our K3 beta testers. Specifically, the Chinese or whatever characters.

A reset of the K3 solved the problem.

FYI, here is what the data from the K3 should look like. Nice clean ASCII text.

2018-07-16 21:47:01.78 Write IF;
2018-07-16 21:47:01.79 tx WriteBinary 49 46 3B
2018-07-16 21:47:01.80 rx ReadTo IF00050306566 -000000 0003000001 ;

44 Com ports -- that has to be a record!

73,

WN4AZY

What I would do next is connect directly to the rig with our loopback tester.
http://www.hosenose.com/...1_Loopback-testing.aspx

Set the baud rate, COM port, etc up. to match the rig and what you have in LOGic and your other software.

Send

IF;

to the rig. See if it responds with a legitimate packet or not. It may not show Chinese characters, but there should be some indication that something is amiss in those column positions. If that comes back clean, then that points to the problem being LOGic. If there is still garbage, then it is the rig.

Ok, so other software works with the exact same setup that LOGic will not work with? If that is the case, it could be that they are using a different command than IF; to get what they need.

Please backgrade to .29 and see if that works. That was well before we added the new COM port library, which was added with .37. It is possible, but unlikely, that the rig is sending the correct data, but the new Com port library is reading it improperly for some reason. It is working for everyone else, but it could be an incompatibility with the RCForb software. And try the .37 update too. That will prove one way or the other if the .38 update is to blame.

You can also try the Legacy kenwood interface. It uses a different Com port library. The Kenwood interface is very similar to the K3 interface. The main difference is is setting Split and swapping A/B VFOs.

Also try what Kyle suggests -- turn off polling. If there is a problem with the rig and the IF; command, LOGic's freq display will track as you tune the rig. However, it still will not log the frequency properly, as LOGic always explicitly requests the frequency when it needs to log it.

Here's what we do know. The Chinese characters are not correct. The question is where are they coming from? They have to be coming from the rig, or are being introduced by LOGic and/or the virtual ports.

I will try to find out more what our tester did to reset the rig. I think there are different levels of rebooting and resetting that you can do. Incidentally, he was using some Com0Com virtual ports, but I don't know if they were between the rig and LOGic or not.

Tnx & 73,

Dennis WN4AZY

Ok, thanks for the research. We're learning something. I'll bet that .35 will work. .36 was actually a beta of .37, so it has the new COM port libraries. That has to be the culprit. I also bet that the legacy Kenwood interface would work.

I disagree. So what if they are virtual? Windows has to see them and send and receive data from them, otherwise LOGic .29 and your other software wouldn't talk to it. If Windows sees it, then the loopback tester should see it too. Not sure if it goes to COM44 tho…. Any Windows terminal program would work.


Let me sleep on this.

73,


Dennis WN4AZY

I already tried the 2 vs. 1 stop bits and found it worked exactly the same either way regardless of version. As far as reducing bit rate, I don't think I can since the RCForb client is also connected to the Elecraft K3/0 Mini control head and I think that's fixed at 38400 and can't be changed or mixed with other bit rates within the client. Bit rate might be an issue with slow hardware, but this all runs on a bullet-fast i7 box with a lot of RAM.

BTW, the reason for so many COM ports is that I went through a series of iterations of remote systems, starting with a a remote Orion II coupled to a Perseus SDR in the local shack and a RemoteRig connection to the remote site. When I switched to the K3 K3/0 Mini, I went through pure hell trying to get various combinations and configurations of software and hardware to give me seamless remote control and a real-time band scope, along with SteppIR control, CW Skimmer, N1MM, LOGic, RTTY & CW keying, rotor control, ACOM control, etc. It takes 22 pieces of hardware and 22 pieces of software to make N6IE Remote work! Most of the COM ports between 1 and 45 are no longer in use, although I have two RemoteRigs, each of which spew out 4 COM ports automatically.

Ron N6IE

I am on the phone with the other customer who had the same problem. It happened again to him. We verified that the garbage "Chinese" characters are being sent. It works with N1MM but not LOGic.

To fix it, he simply ran the K3 Utility Software, and loaded his last good K3 configuration that he saved a while ago back into the rig.

You can download the K3 Utility here:
https://elecraft.com/pages/k3-k3s-software-page
It is version 1.16.7.25

You can apparently update to factory configuration etc. from this software. I see an option to "COPY NEW FIRMWARE FILES EVERY 6 HOURS" :shock:

He says there is a way to set the rig to factory configuration -- some combination of buttons you hold while turning the radio on or something like that, but he doesn't know what it is. And he didn't want to do that because there would be a lot of setup to do again (assuming he couldn't just reload his last saved configuration).

He is running version 5.64 firmware in the rig, BTW.

If you cannot or will not reload the configuration, and want to try to continue to get it to work in it's current state, please try the legacy innterface on 9.1.38 and see if it works, and also run the loopback tester and get me the reply from the IF; command. I need to verify if there is indeed something going on between the 9.1.38 com port libraries and the rig. If that is the case (and I suspct it is), I have no idea WHAT is going on or how I would fix it. If the spacing between characters coming from the rig were off a bit, you'd think 2 stop bits would fix that. Perhaps the baud rate is slightly off or something.

Another idea is to rewrite the Kenwood interface talk to the K3 in binary instead of ASCII mode. That has a long shot of fixing anything, however.

Let me know your thoughts.

73,

Dennis WN4AZY