Date   

locked Re: Was PE added to the list of sections?

Bill Somerville
 

On 21/06/2020 06:02, Tom Schaefer NY4I wrote:
Was PE added as a new section in WSJT-X?

I ask as I checked the Arrl_sec.txt file and also tried to enter 1D PE as the exchange in special mode (Field Day) but I cannot enter the PE. I can enter P but then it stops me from entering the PE.

PE is the code for Prince Edward Island effective April 1st of 2020 so stations in PE will not be able to set this section in their copy of WSJT-X so they essentially cannot use FT-8 in Field Day unless they just enter the old MAR (which is no longer their section).

http://www.arrl.org/news/radio-amateurs-of-canada-announces-a-new-section

I hope I am wrong for those hams in PE that are playing in Field Day.

Regards,

Tom NY4I
Hi Tom,

thanks for the heads up on this change to the FD rules. We are embarrassed to admit this one slipped passed us when we had an opportunity to make the required change for the WSJT-X v2.2.0 and later releases. Be assured we will sort this out very soon. PE operators and those wishing to work them will not be let down.

73
Bill
G4WJS.


locked Re: FT4 contest logging

Dmitry Dmitriev
 



Отправлено из мобильной Яндекс.Почты: http://m.ya.ru/ymail

14:28, 20 июня 2020 г., Bill Somerville <g4wjs@...>:

On 20/06/2020 00:04, Jay Hall WA6MOK wrote:

 Hello,
 My first post here. I am hoping to use FT4 during field day. I have
 not found enough information yet on the contest logging feature. The
 normal log has me press a button to log the QSO. Does the contest FD
 selection in advanced auto place the QSO's into another log?
 This is my first foray into FT4 and also computer logs. I have only
 done field days and never with a computer log, so any insight would be
 gratefully received. I am in process of RTFM.


Hi Jay,

when you are in one of the WSJT-X contest modes your completed QSOsgo
into the main WSJT-X ADIF log and also to a second log kept in a
database table. That second log is what you see in the "Contest Log"
window ("Menu->View->Contest log"). Log entries are generated
automatically unless there is a problem with the required exchange
fields, in that case the normal "Log QSO" window will pop up where you
can correct the fields before pressing the "Ok" button and continuing.
You can also edit the log records in the "Contest Log" window, but of
course be aware of any contest rules about post contest log adjustments.
Rows can be deleted by selecting and right-clicking. Once the contest is
done you can export a Cabrillo format entry file "Menu->File->Export
Cabrillo log ..." and before starting a new contest clear the log table
down with "Menu->File->Reset Cabrillo log ...".

The WSJT-X contest logging facility is functional but minimal, enough
for a casual entry. If you are doing a more serious effort then using
one of the mainstream contest logging applications that integrate with
WSJT-X (directly or perhaps via JTAlert) maybe a better choice.

See these document for more relevant information:

https://physics.princeton.edu/pulsar/K1JT/NCJ_FT4_FT8_Contesting.pdf
(available on the WSJT-X help menu)

https://physics.princeton.edu/pulsar/K1JT/FT8_RTTY_Roundup.pdf

https://physics.princeton.edu/pulsar/K1JT/NCJ_FT4_FT8_Contesting.pdf

73
Bill
G4WJS.



locked Re: Rig Control Failure FD Mode with N3FJP and JTAlert

Dave_G0WBX
 

From: Bill Somerville
Date: Sun, 21 Jun 2020 19:21:13 PDT

Michael,

VSPE COM port splitter is a dumb splitter, as in it makes no attempt whatsoever to arbitrate traffic. The RS-232 serial protocol is a one-to-one protocol, it is not a networking protocol, unhandled collisions are bound to occur when two way traffic is attempted by multiple clients. We do not support it, because it does not work reliably. The fact that you have discovered this obvious unreliability is not our problem, sorry.


Like Bill, I also say that you cannot have simultaneous use of CAT control of a radio, by more than one application.   Though, you may "appear" to have it working, as you've found, odd things happen at times.

Though VSPE is a good tool for what it was intended.  As Bill says, it has no knowledge of the protocol, or what the radio on the common port can or cant do.  Even if it did, Radio's are dumb devices, not able to appreciate or have any understanding that there is anything other than a single command/control tool in use, in software terms, the CAT port and protocol is not multi threading.

Special purpose software (such as been already mentioned) is NEEDED to achieve this correctly.  And yes, it takes a leap in understanding to realise why, and how to deploy such things.   But isn't that what we're supposed to be doing?  Learning/self-training and all that.

I also do this for a living, where if something goes wrong, stuff gets violently damaged, or worse, so I'm only too aware of the limitations of VSPE.

73.

Dave G0WBX.

--

Created on and sent from a Unix like PC running and using free and open source software:


locked Re: Replying to CQ, etc.

Roger
 

I know about gridtracker but that doesn't solve the problem of updating the WSJTX log.

On 22/06/2020 11:58, Jim Shorney wrote:
Again, don't sweat the small stuff. It's just a hobby. Lighten up.
And have a look at Gridtracker, it comes in a Linux flavor.
73
-Jim
NU0C
On Mon, 22 Jun 2020 10:56:15 +0100
groups@... wrote:

On 22/06/2020 04:59, Jim Shorney wrote:
I guess you just have to consider it a part of the game then. I you were working a contest for example you wouldn't be getting grids during the QSO. Part of the game. Sometimes fun is hard work. Some logging software allows you to fill empty fields from online sources, maybe that could be an option for you.
Then it's a game I'm not prepared to play.

There's been lots of comments on this thread.

There might be logging software which will fill in the grid but that
doesn't fill the grid in in WSJTX which defeats the colour coding in the
Band Activity. Someone even suggest Jtalert which as far as I know is a
windows only package.

I know the minimum needed for a QSO but in my opinion common courtesy
and consideration towards others also apply particularly regarding the
use of 73.

A substantial proportion of QSL cards I receive are from those who
didn't send 73, all wanting a card in return, and I don't see why I
should bother when they haven't shown even a basic courtesy towards me.
I don't bother.

Bypassing the grid stage saves just 15 or 30 seconds during the QSO.
Yet stations wanting the grid are expected to look it up, hope it's
correct, and manually edit their ADIF file. I just can't be bothered
any more. It's easier to avoid having a QSO with them. I do allow a
QSO to go ahead with those using a non-standard calls, some even send
their grid just before the 73.

Ideally I'd like to see WSJTX modified with a little tick box preventing
a response to non-grid replies.

73
Roger
G4HZA




locked Re: Replying to CQ, etc.

Jim Shorney
 

Again, don't sweat the small stuff. It's just a hobby. Lighten up.

And have a look at Gridtracker, it comes in a Linux flavor.

73

-Jim
NU0C

On Mon, 22 Jun 2020 10:56:15 +0100
groups@... wrote:

On 22/06/2020 04:59, Jim Shorney wrote:
I guess you just have to consider it a part of the game then. I you were working a contest for example you wouldn't be getting grids during the QSO. Part of the game. Sometimes fun is hard work. Some logging software allows you to fill empty fields from online sources, maybe that could be an option for you.
Then it's a game I'm not prepared to play.

There's been lots of comments on this thread.

There might be logging software which will fill in the grid but that
doesn't fill the grid in in WSJTX which defeats the colour coding in the
Band Activity. Someone even suggest Jtalert which as far as I know is a
windows only package.

I know the minimum needed for a QSO but in my opinion common courtesy
and consideration towards others also apply particularly regarding the
use of 73.

A substantial proportion of QSL cards I receive are from those who
didn't send 73, all wanting a card in return, and I don't see why I
should bother when they haven't shown even a basic courtesy towards me.
I don't bother.

Bypassing the grid stage saves just 15 or 30 seconds during the QSO.
Yet stations wanting the grid are expected to look it up, hope it's
correct, and manually edit their ADIF file. I just can't be bothered
any more. It's easier to avoid having a QSO with them. I do allow a
QSO to go ahead with those using a non-standard calls, some even send
their grid just before the 73.

Ideally I'd like to see WSJTX modified with a little tick box preventing
a response to non-grid replies.

73
Roger
G4HZA




locked Re: What Does Alive Mean

Seannon Baker (AG0NY)
 

when I get plates, I'll be in AG0NY, as it stands, I'm always in AG0NY

Seannon, AG0NY


On Sat, Jun 20, 2020 at 10:35 AM Jim Shorney <jshorney@...> wrote:

Still an active club call on qrz.

73

-Jim
NU0C

On Sat, 20 Jun 2020 00:04:51 +0000 (UTC)
"Bill Turner via groups.io" <w4wnt=yahoo.com@groups.io> wrote:

> At one time there was a W2SEX, I don't know if it is still in use.
> Bill, W4WNT




--
“It is a simple feat of scientific electrical engineering — only expensive — blind, faint-hearted, doubting world.”

Nikola Tesla



locked Re: Replying to CQ, etc.

Roger
 

On 22/06/2020 04:59, Jim Shorney wrote:
I guess you just have to consider it a part of the game then. I you were working a contest for example you wouldn't be getting grids during the QSO. Part of the game. Sometimes fun is hard work. Some logging software allows you to fill empty fields from online sources, maybe that could be an option for you.
Then it's a game I'm not prepared to play.

There's been lots of comments on this thread.

There might be logging software which will fill in the grid but that doesn't fill the grid in in WSJTX which defeats the colour coding in the Band Activity. Someone even suggest Jtalert which as far as I know is a windows only package.

I know the minimum needed for a QSO but in my opinion common courtesy and consideration towards others also apply particularly regarding the use of 73.

A substantial proportion of QSL cards I receive are from those who didn't send 73, all wanting a card in return, and I don't see why I should bother when they haven't shown even a basic courtesy towards me. I don't bother.

Bypassing the grid stage saves just 15 or 30 seconds during the QSO. Yet stations wanting the grid are expected to look it up, hope it's correct, and manually edit their ADIF file. I just can't be bothered any more. It's easier to avoid having a QSO with them. I do allow a QSO to go ahead with those using a non-standard calls, some even send their grid just before the 73.

Ideally I'd like to see WSJTX modified with a little tick box preventing a response to non-grid replies.

73
Roger
G4HZA


locked Re: #FIELD DAY

Reino Talarmo
 

Hi Ed and All.

Just a minor issue about special operations contest logs. You need by yourself manage the log in the sense that there is no automatic new log function. Contest log is kept in a database that is independent of the normal log (wsjtx_log.adi). Before a contest you need to reset the contest log File -> Reset Cabrillo log… and after the contest export than log by Export Cabrillo log… Of course you may use any other logging software and forget the wsjt-x tools of use the wsjtx_log.adi file as contest log, if accepted in contest.

73, Reino OH3mA

PS  The database is retained, if wsjt-x is uninstalled and re-installed or a new version is installed.

 

>I believe WSJT-X starts a new log for you just for field Day.

 

Ed.. AB4IQ


locked Re: Replying to CQ, etc.

Jim Shorney
 

I guess you just have to consider it a part of the game then. I you were working a contest for example you wouldn't be getting grids during the QSO. Part of the game. Sometimes fun is hard work. Some logging software allows you to fill empty fields from online sources, maybe that could be an option for you.

73

-Jim
NU0C

On Mon, 22 Jun 2020 01:41:48 +0000 (UTC)
"K8BL BOB LIDDY" <k8bl@...> wrote:

Jim,
I do work them. But since I want their Grid in the WSJT Log so itwill tell me if I still need that Grid or not I have to look them up inQRZ for their Grid. Then, I have to enter it before I log the QSO which is easier than going back later to edit the Log. I will alwayswork whoever calls me, I just need their Grid for the Log. I haveno add-ons, just WSJTX working alone since I have seen non-stopmessages here about tons of problems with multiple programs tryingto work together. Bare-bones WSJT on WIN7 with 30W to an End-Fed LW has given me over 24K Q's so far. FT8/4 Rocks!!!
73,   Bob  K8BL

On Sunday, June 21, 2020, 04:12:47 PM EDT, Jim Shorney <jshorney@...> wrote:


Now you have got me curious. Why not just work them and move on?

73

-Jim
NU0C


On Sun, 21 Jun 2020 19:03:56 +0000 (UTC)
"K8BL BOB LIDDY" <k8bl@...> wrote:

It seems that the EU folks are the ones that often like to starta QSO by not using TX1 with their Grid. Maybe they feel theycan make QSOs quicker that way. That's not my preference sinceI have WSJTX set up to indicate "New Grid On Band". If theydon't send it, I am forced to look it up in QRZ. I run WSJTXby itself.


locked Re: Rig Control Failure FD Mode with N3FJP and JTAlert

Michael WA7SKG
 

Well, I can only go by experience. In my case, I have been using VSPE almost daily to allow two, often three applications work with my radio without issue for over three years. The ONLY unreliability/incompatibility is with WSJT-X. I regularly use fldigi and N3FJP for logging and the two work together with my radio just fine. WSJT-X seems to only work with itself and nothing else. I don't need the headache. I'll just forego FT8 for Field Day.

Michael WA7SKG


Bill Somerville wrote on 6/21/20 7:21 PM:

Michael,
VSPE COM port splitter is a dumb splitter, as in it makes no attempt whatsoever to arbitrate traffic. The RS-232 serial protocol is a one-to-one protocol, it is not a networking protocol, unhandled collisions are bound to occur when two way traffic is attempted by multiple clients. We do not support it, because it does not work reliably. The fact that you have discovered this obvious unreliability is not our problem, sorry.
73
Bill
G4WJS.
On 22/06/2020 03:16, Michael WA7SKG wrote:
Actually, I have multiple applications utilizing CAT control all the time. It works fine, except for WSJT-X. I run fldigi, N3FJP, and MS-DMT simultaneously using VSPE to set up a port splitter. All applications can set and read mode and frequency as well as PTT with no issue. But if I try to add WSJT-X to the mix, it simply wads up and dies.

Michael WA7SKG


Bill Somerville wrote on 6/21/20 7:03 PM:
Michael,

you cannot have two applications directly using the same rig for CAT control. If the N3FJP FD logging application does not support one of the rig server programs that WSJT-X also supports (Hamlib rigctld, Omni-Rig, or something that looks like a rig to each application but is more than a dumb serial port splitter), then you will have to disable rig control in one application or the other. WSJT-X will run fine without CAT control of a rig so long as you can still control PTT. Either VOX or a wire-ored hardware PTT arrangement using RTS or DTR on a pair of serial ports will get you PTT. If you intend to use WSJT-X without CAT control then you should stick to Tx audio offsets above 1500 Hz to make sure any audio harmonics are eliminated. You will also have to ensure that WSJT-X is switched to the same band as your rig or your log entries will be incorrect.

TBH, if disabling rig control in the N3FJP FD logging application is as easy as it is in WSJT-X ("Settings->Radio->Rig->None" and "Settings->Radio->PTT Method->VOX", then click "Ok") or simply exit WSJT-X when you are not using it as restarting will bring it right back where you left it, then switching rig control is probably the easiest and quickest option.

73
Bill
G4WJS.

On 22/06/2020 02:44, Michael WA7SKG wrote:
If all I was doing is running FT8, this would be fine. However, most of the time I will be running phone, with WSJT-X and fldigi not running and doing all my logging directly through N3FJP. I want to start N3FJP and leave it running all the time, then start WSJT-X or fldigi as needed to use the digital modes. Then I would stop WSJT-X or fldigi and return to phone. I would like to minimize the transition time between modes and not have to shut everything down and restart the whole works with different sequences between modes.

Michael WA7SKG


neil_zampella wrote on 6/21/20 5:59 PM:
Yes .. Hamlib is built into the WSJT-X executable.    Try starting WSJT-X, JT-Alert, then N3FJP.  I suggest that the reason you're getting the error is that N3FJP is setup to control the rig, if you could turn that off, and let WSJT-X control the rig, you'll be fine.

Neil, KN3ILZ

On 6/21/2020 8:07 PM, Michael WA7SKG wrote:
Additionally, if I go to configurations, all settings are correct, when I hit TEST CAT, the rig changes to 28.335.19 and a box pops up saying "Rig Failure Hamlib error:Command rejected by the rig while exchanging VFOs." Subsequent tests fail for frequency change and mode change.

I guess hamlib must be built into WSJT-X and I don't use it otherwise.

Michael WA7SKG


Michael WA7SKG wrote on 6/21/20 4:45 PM:
Getting ready for Field Day. I have the latest versions of WSJT-X
(2.2.1), JTAlert (2.16.8), and N3FJP Field Day Log (6.3).

My understanding is to start N3FJP > WSJT-X > JTAlert in that order. I have followed the various tutorials and instructions for setting these up. When I start WSJT-X, I get a "Rig Control Error" box asking to set up the rig parameters (IC-7300). These are all correct. Running WSJT-X by itself is no problem. Only when N3FJP is running do I have an issue.

I am obviously missing something. Any suggestions as to what?


locked Re: Replying to CQ, etc.

Jim Brown
 

On 6/21/2020 12:03 PM, K8BL BOB LIDDY wrote:
It seems that the EU folks are the ones that often like to start
a QSO by not using TX1 with their Grid. Maybe they feel they
can make QSOs quicker that way.
On 6M, the vast majority of JA stations call with TX2. It's also common for them to switch to another QSO before giving me RR73. I find this somewhere between dumb and inconsiderate. I've got a 9-call living (for 14 years) in NorCal, so if I'm calling a station who doesn't know me on a band where the other guy is likely using a directional antenna, I'll call with TX1 so that he doesn't turn his antenna in the wrong direction. Without that concern, I would nearly always call with TX2.

I disagree with the advice someone offered that TX3 and TX4 was sufficient. A QSO requires one piece of information in addition to the calls, and RR (or R -6) from both sides. If you CALL with TX3, the other station hasn't given you any info to acknowledge, so it's no QSO.

Now, when in Contest mode, the exchange is grid and the CQing station has sent his grid, I see TX3 as an OK response by the calling station, and RR73 by the CQing station as finishing the QSO.

73, Jim K9YC


locked Re: wsjt-x and fkex 6700 transmit issues

Bill Somerville
 

On 22/06/2020 03:23, Don - kx9q wrote:
Bill

I have also experienced the same issue with the same setup.  So how do you determine what device or devices are getting powered down?

Don - kx9q
Hi Don,

the problem seems to revolve around anything that could carry audio and supports hot-plugging. that boils down to USB and things that carry USB connections. Setting all USB hubs to not be powered down to save energy in their properties under Device Manager, and setting the system Power Plan not to suspend USB devices both are essential. Another problem area is HDMI monitor connections, HDMI carries USB connections and some graphics cards seem to have no easy way to stop them powering down the monitor when idle. As a last resort, there are applications that simulate mouse movements on a regular basis to try and persuade Windows that the system is not idle.

73
Bill
G4WJS.


locked Re: Rig Control Failure FD Mode with N3FJP and JTAlert

Bill Somerville
 

Michael,

VSPE COM port splitter is a dumb splitter, as in it makes no attempt whatsoever to arbitrate traffic. The RS-232 serial protocol is a one-to-one protocol, it is not a networking protocol, unhandled collisions are bound to occur when two way traffic is attempted by multiple clients. We do not support it, because it does not work reliably. The fact that you have discovered this obvious unreliability is not our problem, sorry.

73
Bill
G4WJS.

On 22/06/2020 03:16, Michael WA7SKG wrote:

Actually, I have multiple applications utilizing CAT control all the time. It works fine, except for WSJT-X. I run fldigi, N3FJP, and MS-DMT simultaneously using VSPE to set up a port splitter. All applications can set and read mode and frequency as well as PTT with no issue. But if I try to add WSJT-X to the mix, it simply wads up and dies.

Michael WA7SKG


Bill Somerville wrote on 6/21/20 7:03 PM:
Michael,

you cannot have two applications directly using the same rig for CAT control. If the N3FJP FD logging application does not support one of the rig server programs that WSJT-X also supports (Hamlib rigctld, Omni-Rig, or something that looks like a rig to each application but is more than a dumb serial port splitter), then you will have to disable rig control in one application or the other. WSJT-X will run fine without CAT control of a rig so long as you can still control PTT. Either VOX or a wire-ored hardware PTT arrangement using RTS or DTR on a pair of serial ports will get you PTT. If you intend to use WSJT-X without CAT control then you should stick to Tx audio offsets above 1500 Hz to make sure any audio harmonics are eliminated. You will also have to ensure that WSJT-X is switched to the same band as your rig or your log entries will be incorrect.

TBH, if disabling rig control in the N3FJP FD logging application is as easy as it is in WSJT-X ("Settings->Radio->Rig->None" and "Settings->Radio->PTT Method->VOX", then click "Ok") or simply exit WSJT-X when you are not using it as restarting will bring it right back where you left it, then switching rig control is probably the easiest and quickest option.

73
Bill
G4WJS.

On 22/06/2020 02:44, Michael WA7SKG wrote:
If all I was doing is running FT8, this would be fine. However, most of the time I will be running phone, with WSJT-X and fldigi not running and doing all my logging directly through N3FJP. I want to start N3FJP and leave it running all the time, then start WSJT-X or fldigi as needed to use the digital modes. Then I would stop WSJT-X or fldigi and return to phone. I would like to minimize the transition time between modes and not have to shut everything down and restart the whole works with different sequences between modes.

Michael WA7SKG


neil_zampella wrote on 6/21/20 5:59 PM:
Yes .. Hamlib is built into the WSJT-X executable.    Try starting WSJT-X, JT-Alert, then N3FJP.  I suggest that the reason you're getting the error is that N3FJP is setup to control the rig, if you could turn that off, and let WSJT-X control the rig, you'll be fine.

Neil, KN3ILZ

On 6/21/2020 8:07 PM, Michael WA7SKG wrote:
Additionally, if I go to configurations, all settings are correct, when I hit TEST CAT, the rig changes to 28.335.19 and a box pops up saying "Rig Failure Hamlib error:Command rejected by the rig while exchanging VFOs." Subsequent tests fail for frequency change and mode change.

I guess hamlib must be built into WSJT-X and I don't use it otherwise.

Michael WA7SKG


Michael WA7SKG wrote on 6/21/20 4:45 PM:
Getting ready for Field Day. I have the latest versions of WSJT-X
(2.2.1), JTAlert (2.16.8), and N3FJP Field Day Log (6.3).

My understanding is to start N3FJP > WSJT-X > JTAlert in that order. I have followed the various tutorials and instructions for setting these up. When I start WSJT-X, I get a "Rig Control Error" box asking to set up the rig parameters (IC-7300). These are all correct. Running WSJT-X by itself is no problem. Only when N3FJP is running do I have an issue.

I am obviously missing something. Any suggestions as to what?



locked Re: Rig Control Failure FD Mode with N3FJP and JTAlert

Michael WA7SKG
 

Actually, I have multiple applications utilizing CAT control all the time. It works fine, except for WSJT-X. I run fldigi, N3FJP, and MS-DMT simultaneously using VSPE to set up a port splitter. All applications can set and read mode and frequency as well as PTT with no issue. But if I try to add WSJT-X to the mix, it simply wads up and dies.

Michael WA7SKG


Bill Somerville wrote on 6/21/20 7:03 PM:

Michael,
you cannot have two applications directly using the same rig for CAT control. If the N3FJP FD logging application does not support one of the rig server programs that WSJT-X also supports (Hamlib rigctld, Omni-Rig, or something that looks like a rig to each application but is more than a dumb serial port splitter), then you will have to disable rig control in one application or the other. WSJT-X will run fine without CAT control of a rig so long as you can still control PTT. Either VOX or a wire-ored hardware PTT arrangement using RTS or DTR on a pair of serial ports will get you PTT. If you intend to use WSJT-X without CAT control then you should stick to Tx audio offsets above 1500 Hz to make sure any audio harmonics are eliminated. You will also have to ensure that WSJT-X is switched to the same band as your rig or your log entries will be incorrect.
TBH, if disabling rig control in the N3FJP FD logging application is as easy as it is in WSJT-X ("Settings->Radio->Rig->None" and "Settings->Radio->PTT Method->VOX", then click "Ok") or simply exit WSJT-X when you are not using it as restarting will bring it right back where you left it, then switching rig control is probably the easiest and quickest option.
73
Bill
G4WJS.
On 22/06/2020 02:44, Michael WA7SKG wrote:
If all I was doing is running FT8, this would be fine. However, most of the time I will be running phone, with WSJT-X and fldigi not running and doing all my logging directly through N3FJP. I want to start N3FJP and leave it running all the time, then start WSJT-X or fldigi as needed to use the digital modes. Then I would stop WSJT-X or fldigi and return to phone. I would like to minimize the transition time between modes and not have to shut everything down and restart the whole works with different sequences between modes.

Michael WA7SKG


neil_zampella wrote on 6/21/20 5:59 PM:
Yes .. Hamlib is built into the WSJT-X executable.    Try starting WSJT-X, JT-Alert, then N3FJP.  I suggest that the reason you're getting the error is that N3FJP is setup to control the rig, if you could turn that off, and let WSJT-X control the rig, you'll be fine.

Neil, KN3ILZ

On 6/21/2020 8:07 PM, Michael WA7SKG wrote:
Additionally, if I go to configurations, all settings are correct, when I hit TEST CAT, the rig changes to 28.335.19 and a box pops up saying "Rig Failure Hamlib error:Command rejected by the rig while exchanging VFOs." Subsequent tests fail for frequency change and mode change.

I guess hamlib must be built into WSJT-X and I don't use it otherwise.

Michael WA7SKG


Michael WA7SKG wrote on 6/21/20 4:45 PM:
Getting ready for Field Day. I have the latest versions of WSJT-X
(2.2.1), JTAlert (2.16.8), and N3FJP Field Day Log (6.3).

My understanding is to start N3FJP > WSJT-X > JTAlert in that order. I have followed the various tutorials and instructions for setting these up. When I start WSJT-X, I get a "Rig Control Error" box asking to set up the rig parameters (IC-7300). These are all correct. Running WSJT-X by itself is no problem. Only when N3FJP is running do I have an issue.

I am obviously missing something. Any suggestions as to what?


locked Re: Replying to CQ, etc.

K8BL BOB LIDDY <k8bl@...>
 

Tony,

Thanks for your comments. I don't work many JA's with 30W
and a LW, so your info is news to me. I do see it a lot from EU's.

I have my WD Timer set for 10 minutes since I sometimes walk
away doing other things and find it fun to come back and see that
I worked someone. Maybe some Stations set their timers for a very
long time for various reasons.

My intent was not trying to tell anyone how they should operate. I
was merely sharing a pet peeve of mine. Some folks look for reasons
to be "offended".  I have two words for them - "f--- off!".

GL/73,    Bob  K8BL

P.S.  I tried responding direct, but your adr kept getting bounced.

On Sunday, June 21, 2020, 08:50:32 PM EDT, Tony Collett via groups.io <tony.nbs@...> wrote:


To answer Roger's initial question - I've only experienced this with stations "in demand". I call them with Tx1 but somehow get Tx3 back so I log a QSO without me ever sending my report. I guess they are treating data as an expedition type QSO and reports are superfluous? Never had it in answer to my CQ though.

Bob K8BL - I've yet to have a JA station answer my CQ call with anything other than Tx2, it isn't that common a practice in Europe yet.

And while I agree with the comments re software JTAlert does not always (in my experience) provide the locator unless you have already worked the station. Since WSJT highlights the worked before status by using its own Log.ADI file unless you edit that file or enter the Locator before you hit the log QSO button you are left with your peeve!

Does seem to me BTW that there are still way too many that insist on not using split. I thought WSJT was programmed so that if you called on someones frequency but they answered somebody else then your Tx was disabled.

There must be a different program out there that doesn't do this as I watched a Spanish station on 10m the other night that continually called a station on their frequency without any form of watchdog timeout and despite that station somehow managing lots of QSO's with other callers. Now that would peeve me off! 

73's Tony G4NBS


locked Re: Rig Control Failure FD Mode with N3FJP and JTAlert

Bill Somerville
 

Michael,

you cannot have two applications directly using the same rig for CAT control. If the N3FJP FD logging application does not support one of the rig server programs that WSJT-X also supports (Hamlib rigctld, Omni-Rig, or something that looks like a rig to each application but is more than a dumb serial port splitter), then you will have to disable rig control in one application or the other. WSJT-X will run fine without CAT control of a rig so long as you can still control PTT. Either VOX or a wire-ored hardware PTT arrangement using RTS or DTR on a pair of serial ports will get you PTT. If you intend to use WSJT-X without CAT control then you should stick to Tx audio offsets above 1500 Hz to make sure any audio harmonics are eliminated. You will also have to ensure that WSJT-X is switched to the same band as your rig or your log entries will be incorrect.

TBH, if disabling rig control in the N3FJP FD logging application is as easy as it is in WSJT-X ("Settings->Radio->Rig->None" and "Settings->Radio->PTT Method->VOX", then click "Ok") or simply exit WSJT-X when you are not using it as restarting will bring it right back where you left it, then switching rig control is probably the easiest and quickest option.

73
Bill
G4WJS.

On 22/06/2020 02:44, Michael WA7SKG wrote:

If all I was doing is running FT8, this would be fine. However, most of the time I will be running phone, with WSJT-X and fldigi not running and doing all my logging directly through N3FJP. I want to start N3FJP and leave it running all the time, then start WSJT-X or fldigi as needed to use the digital modes. Then I would stop WSJT-X or fldigi and return to phone. I would like to minimize the transition time between modes and not have to shut everything down and restart the whole works with different sequences between modes.

Michael WA7SKG


neil_zampella wrote on 6/21/20 5:59 PM:
Yes .. Hamlib is built into the WSJT-X executable.    Try starting WSJT-X, JT-Alert, then N3FJP.  I suggest that the reason you're getting the error is that N3FJP is setup to control the rig, if you could turn that off, and let WSJT-X control the rig, you'll be fine.

Neil, KN3ILZ

On 6/21/2020 8:07 PM, Michael WA7SKG wrote:
Additionally, if I go to configurations, all settings are correct, when I hit TEST CAT, the rig changes to 28.335.19 and a box pops up saying "Rig Failure Hamlib error:Command rejected by the rig while exchanging VFOs." Subsequent tests fail for frequency change and mode change.

I guess hamlib must be built into WSJT-X and I don't use it otherwise.

Michael WA7SKG


Michael WA7SKG wrote on 6/21/20 4:45 PM:
Getting ready for Field Day. I have the latest versions of WSJT-X
(2.2.1), JTAlert (2.16.8), and N3FJP Field Day Log (6.3).

My understanding is to start N3FJP > WSJT-X > JTAlert in that order. I have followed the various tutorials and instructions for setting these up. When I start WSJT-X, I get a "Rig Control Error" box asking to set up the rig parameters (IC-7300). These are all correct. Running WSJT-X by itself is no problem. Only when N3FJP is running do I have an issue.

I am obviously missing something. Any suggestions as to what?



locked Re: Rig Control Failure FD Mode with N3FJP and JTAlert

Michael WA7SKG
 

If all I was doing is running FT8, this would be fine. However, most of the time I will be running phone, with WSJT-X and fldigi not running and doing all my logging directly through N3FJP. I want to start N3FJP and leave it running all the time, then start WSJT-X or fldigi as needed to use the digital modes. Then I would stop WSJT-X or fldigi and return to phone. I would like to minimize the transition time between modes and not have to shut everything down and restart the whole works with different sequences between modes.

Michael WA7SKG


neil_zampella wrote on 6/21/20 5:59 PM:

Yes .. Hamlib is built into the WSJT-X executable.    Try starting WSJT-X, JT-Alert, then N3FJP.  I suggest that the reason you're getting the error is that N3FJP is setup to control the rig, if you could turn that off, and let WSJT-X control the rig, you'll be fine.
Neil, KN3ILZ
On 6/21/2020 8:07 PM, Michael WA7SKG wrote:
Additionally, if I go to configurations, all settings are correct, when I hit TEST CAT, the rig changes to 28.335.19 and a box pops up saying "Rig Failure Hamlib error:Command rejected by the rig while exchanging VFOs." Subsequent tests fail for frequency change and mode change.

I guess hamlib must be built into WSJT-X and I don't use it otherwise.

Michael WA7SKG


Michael WA7SKG wrote on 6/21/20 4:45 PM:
Getting ready for Field Day. I have the latest versions of WSJT-X
(2.2.1), JTAlert (2.16.8), and N3FJP Field Day Log (6.3).

My understanding is to start N3FJP > WSJT-X > JTAlert in that order. I have followed the various tutorials and instructions for setting these up. When I start WSJT-X, I get a "Rig Control Error" box asking to set up the rig parameters (IC-7300). These are all correct. Running WSJT-X by itself is no problem. Only when N3FJP is running do I have an issue.

I am obviously missing something. Any suggestions as to what?


locked Re: Replying to CQ, etc.

K8BL BOB LIDDY <k8bl@...>
 

Jim,

I do work them. But since I want their Grid in the WSJT Log so it
will tell me if I still need that Grid or not I have to look them up in
QRZ for their Grid. Then, I have to enter it before I log the QSO 
which is easier than going back later to edit the Log. I will always
work whoever calls me, I just need their Grid for the Log. I have
no add-ons, just WSJTX working alone since I have seen non-stop
messages here about tons of problems with multiple programs trying
to work together. Bare-bones WSJT on WIN7 with 30W to an End-
Fed LW has given me over 24K Q's so far. FT8/4 Rocks!!!

73,   Bob  K8BL


On Sunday, June 21, 2020, 04:12:47 PM EDT, Jim Shorney <jshorney@...> wrote:



Now you have got me curious. Why not just work them and move on?

73

-Jim
NU0C


On Sun, 21 Jun 2020 19:03:56 +0000 (UTC)
"K8BL BOB LIDDY" <k8bl@...> wrote:

> It seems that the EU folks are the ones that often like to starta QSO by not using TX1 with their Grid. Maybe they feel theycan make QSOs quicker that way. That's not my preference sinceI have WSJTX set up to indicate "New Grid On Band". If theydon't send it, I am forced to look it up in QRZ. I run WSJTXby itself.


locked Re: #FIELD DAY

Charles Fricks, AF5FB
 

Found it--thanks!


locked Re: Rig Control Failure FD Mode with N3FJP and JTAlert

neil_zampella
 

Yes .. Hamlib is built into the WSJT-X executable.    Try starting WSJT-X, JT-Alert, then N3FJP.  I suggest that the reason you're getting the error is that N3FJP is setup to control the rig, if you could turn that off, and let WSJT-X control the rig, you'll be fine.

Neil, KN3ILZ

On 6/21/2020 8:07 PM, Michael WA7SKG wrote:
Additionally, if I go to configurations, all settings are correct, when I hit TEST CAT, the rig changes to 28.335.19 and a box pops up saying "Rig Failure Hamlib error:Command rejected by the rig while exchanging VFOs." Subsequent tests fail for frequency change and mode change.

I guess hamlib must be built into WSJT-X and I don't use it otherwise.

Michael WA7SKG


Michael WA7SKG wrote on 6/21/20 4:45 PM:
Getting ready for Field Day. I have the latest versions of WSJT-X
(2.2.1), JTAlert (2.16.8), and N3FJP Field Day Log (6.3).

My understanding is to start N3FJP > WSJT-X > JTAlert in that order. I have followed the various tutorials and instructions for setting these up. When I start WSJT-X, I get a "Rig Control Error" box asking to set up the rig parameters (IC-7300). These are all correct. Running WSJT-X by itself is no problem. Only when N3FJP is running do I have an issue.

I am obviously missing something. Any suggestions as to what?




    

Virus-free. www.avg.com