Excellent advice, Reino.

One VERY important observation about antennas and earth connections. The earth is a big resistor, except for sea water, so a driven rod is a lousy return for antenna current -- it can easily burn most of the transmitter's output. That's far less important if the end-fed wire is very close to a half-wave, because current at the feedpoint is small. But it's a VERY BIG DEAL if the antenna is close to a quarter wave, because the current is high at the feedpoint.

We use a counterpoise or radials in place of a driven rod because they have much lower resistance than the earth, so there's less loss. In fact, a good radial system SHIELDS (screens in British English) the antenna's field from the lossy earth.

And Reino's observations about the antenna with no counterpoise or radials putting return current on the coax shield is also right on. The length of the feedline and how it's connected in the shack (or in the field) can put that RF current in your shack, where "Pin One Problems" in equipment in the shack couples that current into that equipment to cause mischief.

There's lots of tutorial stuff on my website about the Pin One Problem, so-named because it was a ham working in pro audio who figured it out and alerted the pro audio world to it back in 1994, and because Pin One of XLR audio cables is the cable shield, and because the Pin One Problem is failure of equipment mfrs to bond the shield to the chassis at the point of entry.

k9yc.com/publish.htm

The last time I was at Dayton, EVERY rig had Pin One Problems at most or all of their accessory connectors. Virtually all consumer electronics is built with Pin One Problems. They are the primary cause of hum, buzz, and RFI.

73, Jim K9YC

Bill

Are you willing to comment on this error when it comes from V2.2 of the software?

When I see this error, nothing is happening, no transmitting just monitoring.  In my case, the details portion of the message read:
 

On 08/02/2021 17:00, Kenneth Williams wrote:

Bill

Are you willing to comment on this error when it comes from V2.2 of the software?

When I see this error, nothing is happening, no transmitting just monitoring.  In my case, the details portion of the message read:
-------
Hamlib error: Protocol error while getting current VFO
--------

My setup is Windows 7, rig=TS-570S.

Thanks

Ken

Hi Ken,

your first step should be to upgrade to the current supported GA version which is v2.3.0.

73
Bill
G4WJS.

OK

I upgraded to v2.3.0 and let the setup run overnight, monitoring only.  hen I checked this morning, I saw the error message.  A copy/paste gives me:

On 09/02/2021 15:26, Kenneth Williams wrote:

[Edited Message Follows]

OK

I upgraded to v2.3.0 and let the setup run overnight, monitoring only.  hen I checked this morning, I saw the error message.  A copy/paste gives me:

---------------------------
Hamlib error:                    Protocol error
rig.c(2358):rig_get_vfo return while getting current VFO
Timestamp: 2021-02-09T09:23:04.259Z
---------------------------

Any suggestions from here?

Before you respond, let me add that I followed the log creation steps that you provided to Jason and I do have a log file.  It is over 500 MB but the last few lines leading up to the protocol error message are shown below.  If it works, I can easily grab the last few hundred lines around the error and send those.

[2021-02-09 09:23:04.107568][14:52:14.562517][RIGCTRL:error] kenwood_safe_transaction: wrong answer; len for cmd IF: expected = 37, got 36^M
[2021-02-09 09:23:04.157568][14:52:14.612379][RIGCTRL:debug] kenwood_transaction called^M
[2021-02-09 09:23:04.157568][14:52:14.612437][RIGCTRL:trace] elapsed_ms: start = 1612862583,757568800^M
[2021-02-09 09:23:04.157568][14:52:14.612461][RIGCTRL:trace] elapsed_ms: elapsed_msecs=400^M
[2021-02-09 09:23:04.157568][14:52:14.612473][RIGCTRL:trace] kenwood_transaction: cache hit, age=399ms^M
[2021-02-09 09:23:04.157568][14:52:14.612487][RIGCTRL:error] kenwood_safe_transaction: wrong answer; len for cmd IF: expected = 37, got 36^M
[2021-02-09 09:23:04.207568][14:52:14.662368][RIGCTRL:debug] kenwood_transaction called^M
[2021-02-09 09:23:04.207568][14:52:14.662394][RIGCTRL:trace] elapsed_ms: start = 1612862583,757568800^M
[2021-02-09 09:23:04.207568][14:52:14.662413][RIGCTRL:trace] elapsed_ms: elapsed_msecs=450^M
[2021-02-09 09:23:04.207568][14:52:14.662424][RIGCTRL:trace] kenwood_transaction: cache hit, age=449ms^M
[2021-02-09 09:23:04.207568][14:52:14.662439][RIGCTRL:error] kenwood_safe_transaction: wrong answer; len for cmd IF: expected = 37, got 36^M
[2021-02-09 09:23:04.257568][14:52:14.712388][RIGCTRL:trace] elapsed_ms: start = 1612862581,748568800^M
[2021-02-09 09:23:04.257568][14:52:14.712428][RIGCTRL:trace] elapsed_ms: elapsed_msecs=10000^M
[2021-02-09 09:23:04.257568][14:52:14.712824][RIGCTRL:error] rig_get_vfo: returning -8(                 Protocol error^M

Thanks

Ken
KC6PUQ

Hi Ken,

delete the huge WSJT-X_RIgControl.log and then run a minimal test that demonstrates the issue, then quit WSJT-X. Send me the new log file (g4wjs <at> classdesign <dot> com).

73
Bill
G4WJS.

Hmm.  I am trying to understand how I might do that.  
The error seems to occur with time only. No transmit or other action is necessary on my part.
It can happen in 10 minutes or 10 hours and with the log file growing at upwards of 50 lines a second I am trying to get a handle on how to do this.

Can the log level be set lower and still give you enough information?

I am comfortable with text processing and general guidance if you want to give a go at asking me to grab certain parts of the existing log file.  Otherwise, I have restarted WSJT-X (after renaming the existing log file) and I am going for coffee.  I will see what I get when I return.

Ken
KC6PUQ

On 09/02/2021 16:28, Kenneth Williams wrote:

Hmm.  I am trying to understand how I might do that.
The error seems to occur with time only. No transmit or other action is necessary on my part.
It can happen in 10 minutes or 10 hours and with the log file growing at upwards of 50 lines a second I am trying to get a handle on how to do this.

Can the log level be set lower and still give you enough information?

I am comfortable with text processing and general guidance if you want to give a go at asking me to grab certain parts of the existing log file.  Otherwise, I have restarted WSJT-X (after renaming the existing log file) and I am going for coffee.  I will see what I get when I return.

Ken
KC6PUQ

Hi Ken,

OK, just send the last Mbyte of so of the log. Also send the first Mbyte or so separately so I can see the startup settings.

73
Bill
G4WJS.