Date   

locked Re: Involuntary CQing

Austin 2E0MNV
 

One thing that has been annoying me lately is that once wsjtx has sent RR73, the TX stops.  By the time you get that next one out, it's too late and the DX station is working someone else.  I've lost many a QSL as a result, because some operators expect a 73 or they won't log you.  Clicking tx again results in an involuntary CQ if you're not careful.

I know there is an RRR option, but that's not a 73. It just draws out the QSO and the OP is still expecting a 73 and he will not log you until he gets it.  (Not all ops, but some).

I log everyone if there is an exchange of signal reports. Waiting for the 73 is just not realistic on FT8 in certain conditions and especially in a pile up, someone is going to jump on top of that 73 anyway. The person working the pile up "should" be experienced enough to realise this, but still, I get many who still won't QSL.

Conclusion, it would be great if 73 could repeat say a maximum of three times until both parties are satisfied the QSO is complete.  Of course, it wouldn't be necessary if people were not so upset about not getting their 73 and refusing to QSL.  
This behaviour also happens after 15 minute SSB QSO's too. I've received a "not in my log" back from them, because QSB closed in before we could say 73.  Wow!


locked Re: Involuntary CQing

Reino Talarmo
 

On Jan 11, 2021, at 14:10, Reino Talarmo <reino.talarmo@...> wrote:
I think that you have a minor failure in your thinking.
After a restart you don’t have a selected target except CQ. Why not first receive and try to find again that super rare DX and select it before enabling TX?
I complained about this long ago and it catches me often. I almost never call CQ, and don’t want to most of the time. On the rare occasion that I do, I typically work 5-10 stations in a row before I hit a period of rest. Also, If I use TX5 to send a directional CQ (i.e. CQ DX, CQ RI, CQ AS, etc.) I seriously don’t want to send out a series of TX6 without wanting to. I’ve sent many a CQ inadvertently when the program decided that it was the thing to do and switched without me noticing it. I’ve love to see a CQ inhibit function right up front so that it can be prevented.
Gary - AG0N
Gary,

You may as well edit TX6 and put there your directed call " CQ EU AG0N " and then you don't send a general CQ at all.

73, Reino OH3mA


locked Re: Involuntary CQing

Gary - AG0N
 

On Jan 11, 2021, at 14:10, Reino Talarmo <reino.talarmo@...> wrote:

I think that you have a minor failure in your thinking.
After a restart you don’t have a selected target except CQ. Why not first receive and try to find again that super rare DX and select it before enabling TX?
I complained about this long ago and it catches me often. I almost never call CQ, and don’t want to most of the time. On the rare occasion that I do, I typically work 5-10 stations in a row before I hit a period of rest. Also, If I use TX5 to send a directional CQ (i.e. CQ DX, CQ RI, CQ AS, etc.) I seriously don’t want to send out a series of TX6 without wanting to. I’ve sent many a CQ inadvertently when the program decided that it was the thing to do and switched without me noticing it. I’ve love to see a CQ inhibit function right up front so that it can be prevented.

Gary - AG0N


locked Re: Request for new wsjt-x beviour #FT8

Jim Shorney
 

With the way "split" works anyone anywhere there is prop could see that your RX slot on "your" frequency appears to be clear to them and choose to transmit there. That's the way it works and that's the way it happens. Assuming that the RX slot is yours because you are transmitting there is faulty logic. If it is clear it is anyone's game. I stand by what I wrote.

73

-Jim
NU0C

On Mon, 11 Jan 2021 20:07:17 -0800
"Jim Forsyth" <jim@...> wrote:

No I don't because it's not true. I choose to transmit on frequencies
that are not already occupied (from my viewpoint). That doesn't mean I
never see "extraneous info" on my frequency but I do find that there is
a lot less there than there often is on frequencies of stations I just
worked.

Jim, AF6O

On 1/11/2021 7:46 PM, Jim Shorney wrote:
You do understand that "extraneous info in the RX window" is just as likely to show up on your TX frequency as it is anywhere else in the passband, right? This is a solution looking to a problem IMO.

73

-Jim
NU0C

On Mon, 11 Jan 2021 14:04:07 -0800
"Jim Forsyth" <jim@...> wrote:

Yes it can, it can do what is being requested and thereby avoid the
"extraneous info in the RX window." I've been having the exact same
thoughts myself.

Jim, AF6O



locked Re: Request for new wsjt-x beviour #FT8

Reino Talarmo
 

There is a nice button already that moves RX frequency to TX frequency. Yes, I know that it is an extra click, but there is plenty of time to do that in peace once Enable Tx is clicked and the button  located close to the Enable Tx button.

Just my way of working, when I am not interested to receive e.g. “ TNX 73 HNY ”.

73, Reino OH3mA

 

PS. The proposed new behavior selection would be a new source for plenty of questions such as “ Why my Rx frequency moves to Tx frequency once I call CQ, I what it stay on my previous Rx frequency? “

 

From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Jim Forsyth
Sent: 12. tammikuuta 2021 6:07
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Request for new wsjt-x beviour #FT8

 

No I don't because it's not true. I choose to transmit on frequencies that are not already occupied (from my viewpoint). That doesn't mean I never see "extraneous info" on my frequency but I do find that there is a lot less there than there often is on frequencies of stations I just worked.

Jim, AF6O

On 1/11/2021 7:46 PM, Jim Shorney wrote:

 
You do understand that "extraneous info in the RX window" is just as likely to show up on your TX frequency as it is anywhere else in the passband, right? This is a solution looking to a problem IMO.
 
73
 
-Jim
NU0C
 
On Mon, 11 Jan 2021 14:04:07 -0800
"Jim Forsyth" <jim@...> wrote:
 
Yes it can, it can do what is being requested and thereby avoid the 
"extraneous info in the RX window." I've been having the exact same 
thoughts myself.
 
Jim, AF6O



 
 
 


locked Re: Request for new wsjt-x beviour #FT8

Jim Forsyth
 

No I don't because it's not true. I choose to transmit on frequencies that are not already occupied (from my viewpoint). That doesn't mean I never see "extraneous info" on my frequency but I do find that there is a lot less there than there often is on frequencies of stations I just worked.

Jim, AF6O

On 1/11/2021 7:46 PM, Jim Shorney wrote:

You do understand that "extraneous info in the RX window" is just as likely to show up on your TX frequency as it is anywhere else in the passband, right? This is a solution looking to a problem IMO.

73

-Jim
NU0C

On Mon, 11 Jan 2021 14:04:07 -0800
"Jim Forsyth" <jim@...> wrote:

Yes it can, it can do what is being requested and thereby avoid the 
"extraneous info in the RX window." I've been having the exact same 
thoughts myself.

Jim, AF6O




locked Re: Request for new wsjt-x beviour #FT8

Jim Shorney
 

You do understand that "extraneous info in the RX window" is just as likely to show up on your TX frequency as it is anywhere else in the passband, right? This is a solution looking to a problem IMO.

73

-Jim
NU0C

On Mon, 11 Jan 2021 14:04:07 -0800
"Jim Forsyth" <jim@...> wrote:

Yes it can, it can do what is being requested and thereby avoid the
"extraneous info in the RX window." I've been having the exact same
thoughts myself.

Jim, AF6O


locked Re: #linux Building on Debian Linux #linux

Bill Somerville
 

On 12/01/2021 00:38, Lev wrote:
Hi all,


I've tried but failed building wsjt-x on my Debian stable.

I get this when building:

[...]
Scanning dependencies of target manpages
[ 76%] Generating man/man1/wsjtx.1.gz
[ 76%] Generating man/man1/wsprd.1.gz
[ 77%] Generating man/man1/jt65code.1.gz
[ 77%] Generating man/man1/rigctl-wsjtx.1.gz
[ 77%] Generating man/man1/rigctld-wsjtx.1.gz
a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/home/lev/src/wsjtx-2.2.2/build/wsjtx-prefix/src/wsjtx-build/manpages/man/man1/rigctld-wsjtx.1.xml" returned non-zero exit status 5
make[5]: *** [manpages/CMakeFiles/manpages.dir/build.make:110: manpages/man/man1/rigctld-wsjtx.1.gz] Error 1
make[4]: *** [CMakeFiles/Makefile2:2948: manpages/CMakeFiles/manpages.dir/all] Error 2
make[3]: *** [Makefile:152: all] Error 2
make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:61: wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:233: CMakeFiles/wsjtx-build.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

According to the manual page of xsltproc, return value of 5 means 'Error in the stylesheet'. So I'm not sure if it is a wsjt-x problem. The question is if I can somehow work around this? Like not to build the manpages?


Thanks, 73s de HA5OGL

--
Levente Kovacs
Hi Levente,

you are not the first to report this issue with asciidoc building our manpages on Debian, I don;t have a fix for it but you can work around the issue by defining WSJT_SKIP_MANPAGES=ON when you configure the WSJT-X CMake build. See the INSTALL file for an example.

73
Bill
G4WJS.


locked #linux Building on Debian Linux #linux

Lev <leventelist@...>
 

Hi all,


I've tried but failed building wsjt-x on my Debian stable.

I get this when building:

[...]
Scanning dependencies of target manpages
[ 76%] Generating man/man1/wsjtx.1.gz
[ 76%] Generating man/man1/wsprd.1.gz
[ 77%] Generating man/man1/jt65code.1.gz
[ 77%] Generating man/man1/rigctl-wsjtx.1.gz
[ 77%] Generating man/man1/rigctld-wsjtx.1.gz
a2x: ERROR: "xsltproc" -param man.endnotes.list.enabled 0 -param man.endnotes.are.numbered 0 --stringparam callout.graphics 0 --stringparam navig.graphics 0 --stringparam admon.textlabel 1 --stringparam admon.graphics 0 "/etc/asciidoc/docbook-xsl/manpage.xsl" "/home/lev/src/wsjtx-2.2.2/build/wsjtx-prefix/src/wsjtx-build/manpages/man/man1/rigctld-wsjtx.1.xml" returned non-zero exit status 5
make[5]: *** [manpages/CMakeFiles/manpages.dir/build.make:110: manpages/man/man1/rigctld-wsjtx.1.gz] Error 1
make[4]: *** [CMakeFiles/Makefile2:2948: manpages/CMakeFiles/manpages.dir/all] Error 2
make[3]: *** [Makefile:152: all] Error 2
make[2]: *** [CMakeFiles/wsjtx-build.dir/build.make:61: wsjtx-prefix/src/wsjtx-stamp/wsjtx-build] Error 2
make[1]: *** [CMakeFiles/Makefile2:233: CMakeFiles/wsjtx-build.dir/all] Error 2
make: *** [Makefile:84: all] Error 2

According to the manual page of xsltproc, return value of 5 means 'Error in the stylesheet'. So I'm not sure if it is a wsjt-x problem. The question is if I can somehow work around this? Like not to build the manpages?


Thanks, 73s de HA5OGL

--
Levente Kovacs
Senior Electronic Engineer

W: http://levente.logonex.eu


locked Re: Request for new wsjt-x beviour #FT8

careyfisher@...
 

Nope

On Mon, Jan 11, 2021 at 5:48 PM Jim Forsyth <jim@...> wrote:

No need to vote against it, just make it optional!

On 1/11/2021 1:01 PM, K8BL BOB LIDDY wrote:
Charlie...

I understand your point and also find it distracting - sometimes. But, the
operator that you just 73'd with may have a quick comment for you that
you'll miss if you instantly QSY your RX. Examples: HNY, NICE SIG,
PWR 2W, ANT VERT, C U SN, TNX NUGRID, TNX CHARLIE,
etc, etc, etc.

Therefore, I would vote against that feature. FT8/4 and sister modes are
already barely a QSO, as is. I'd hate to see things made totally wham/bam
without the chance for even a "Thank You M'am". What we really need
is an easy way to include a short comment within a QSO.

73/GL,  Bob  K8BL

Gil W0MN ----  I think Charlie was only referring to the data that shows
  up in the RX Frequency window (Right) after his QSO has ended.




On Monday, January 11, 2021, 03:30:05 PM EST, Gilbert Baron <w0mn00@...> wrote:


Does it really matter. Doesn’t the decode cover the entire bandwidth so you miss nothing.

 

Outlook Laptop Gil W0MN

Hierro candente, batir de repente

44.08226N 92.51265W EN34rb

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of hamradiosouth@...
Sent: Monday, January 11, 2021 13:23
To: main@WSJTX.groups.io
Subject: [WSJTX] Request for new wsjt-x beviour #FT8

 

I am requesting an additional wsjt-x behavior titled (or something similar) "RX follows TX on CQ". Here is an example: I am in a QSO, TX is on 1800 and RX is on 1400. It doesn't matter if I called or I was called. Upon 73s, I immediately start another CQ at 1800. However, the RX is stranded at 1400 and now picking up extraneous info in the RX window. There are several ways to avoid that but they involve an additional click or key combo. Now if I had a check mark on the new requested behavior, when I started the CQ then WSJT-X would automatically bring the RX back to 1800.
Charlie W4EBB


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop





    





--
Carey Fisher


--
73, Carey, WB4HXE


locked Re: Involuntary CQing

Frode Igland
 

Checking or unchecking "Disable Tx after sending 73" has no effect in popular modes like FT8 and FT4. It only works in modes where it is expected to have to repeat your 73 message many times in order to complete the QSO, e.g. meteor scatter. In these modes it is normally difficult to complete a QSO in one attempt. However, even in these modes conditions may sometimes be such that you can expect to be successful in completing on the first attempt. This is so rare that you reallly don't want to waste the time with unnecessary repetition. THAT is the when you check "Disable Tx after sending 73", i.e. order to avoid repeating otherwise expected repetitions.

In modes where you can expect to complete the QSO on the first attempt, and that sending a 73 actually completes the QSO, you will find that TX is always disabled after sending 73, in order to avoid a fully automated QSO machines or QSO robots. That is why you always have to click "Enable Tx" to start a new CQ or a new QSO in FT8 and FT4. So the situation you describe simply does not happen in FT8 or FT4, because you will never be able to send a CQ and solicit calls unless you have actively clicked on "Enable Tx" and, I repeat, because "Disable tx after sending 73" has no effect in FT8 and FT4.


locked Re: Request for new wsjt-x beviour #FT8

Jim Forsyth
 

No need to vote against it, just make it optional!

On 1/11/2021 1:01 PM, K8BL BOB LIDDY wrote:

Charlie...

I understand your point and also find it distracting - sometimes. But, the
operator that you just 73'd with may have a quick comment for you that
you'll miss if you instantly QSY your RX. Examples: HNY, NICE SIG,
PWR 2W, ANT VERT, C U SN, TNX NUGRID, TNX CHARLIE,
etc, etc, etc.

Therefore, I would vote against that feature. FT8/4 and sister modes are
already barely a QSO, as is. I'd hate to see things made totally wham/bam
without the chance for even a "Thank You M'am". What we really need
is an easy way to include a short comment within a QSO.

73/GL,  Bob  K8BL

Gil W0MN ----  I think Charlie was only referring to the data that shows
  up in the RX Frequency window (Right) after his QSO has ended.




On Monday, January 11, 2021, 03:30:05 PM EST, Gilbert Baron <w0mn00@...> wrote:


Does it really matter. Doesn’t the decode cover the entire bandwidth so you miss nothing.

 

Outlook Laptop Gil W0MN

Hierro candente, batir de repente

44.08226N 92.51265W EN34rb

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of hamradiosouth@...
Sent: Monday, January 11, 2021 13:23
To: main@WSJTX.groups.io
Subject: [WSJTX] Request for new wsjt-x beviour #FT8

 

I am requesting an additional wsjt-x behavior titled (or something similar) "RX follows TX on CQ". Here is an example: I am in a QSO, TX is on 1800 and RX is on 1400. It doesn't matter if I called or I was called. Upon 73s, I immediately start another CQ at 1800. However, the RX is stranded at 1400 and now picking up extraneous info in the RX window. There are several ways to avoid that but they involve an additional click or key combo. Now if I had a check mark on the new requested behavior, when I started the CQ then WSJT-X would automatically bring the RX back to 1800.
Charlie W4EBB


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop







locked Re: Request for new wsjt-x beviour #FT8

Jim Forsyth
 

Yes it can, it can do what is being requested and thereby avoid the "extraneous info in the RX window." I've been having the exact same thoughts myself.

Jim, AF6O


On 1/11/2021 12:53 PM, Bill Somerville wrote:

On 11/01/2021 19:22, hamradiosouth@... wrote:
I am requesting an additional wsjt-x behavior titled (or something similar) "RX follows TX on CQ". Here is an example: I am in a QSO, TX is on 1800 and RX is on 1400. It doesn't matter if I called or I was called. Upon 73s, I immediately start another CQ at 1800. However, the RX is stranded at 1400 and now picking up extraneous info in the RX window. There are several ways to avoid that but they involve an additional click or key combo. Now if I had a check mark on the new requested behavior, when I started the CQ then WSJT-X would automatically bring the RX back to 1800.
Charlie W4EBB

Charlie,

until someone answers your CQ the software has no idea what audio offset they will be on, as soon as you double-click their call your Rx offset will be moved to their offset. The software cannot do any better than that.

73
Bill
G4WJS.





locked Re: Request for new wsjt-x beviour #FT8

Jim Forsyth
 

I agree.

Jim, AF6O

On 1/11/2021 11:22 AM, hamradiosouth@... wrote:

I am requesting an additional wsjt-x behavior titled (or something similar) "RX follows TX on CQ". Here is an example: I am in a QSO, TX is on 1800 and RX is on 1400. It doesn't matter if I called or I was called. Upon 73s, I immediately start another CQ at 1800. However, the RX is stranded at 1400 and now picking up extraneous info in the RX window. There are several ways to avoid that but they involve an additional click or key combo. Now if I had a check mark on the new requested behavior, when I started the CQ then WSJT-X would automatically bring the RX back to 1800.
Charlie W4EBB



locked Re: Missing Audio Output Choice

Joe Subich, W4TV
 

Note: the information on hybrid sleep here:

https://www.pugetsystems.com/labs/support-software/How-to-disable-Sleep-Mode-or-Hibernation-793/

Is *WRONG*. You want to disable hybrid sleep *EVEN IF* you have
disabled hibernation and sleep. Hybrid sleep will allow Windows
to reload a potentially invalid kernel image (incorrect drivers
or memory corruption) after a shutdown and/or Reboot.

Without disabling hybrid sleep *ONLY RESTART* will force Windows
to reload the kernel and individual drivers (including sound card
enumeration) on boot up.

When the developers of WSJTX (and other software) recommend rebooting
as the first step in trouble shooting, they really mean *RESTART* to
clear the "garbage" from the Windows kernel.

73,

... Joe, W4TV


On 2021-01-11 3:07 PM, Joel wrote:
Kelly
I had an issue with my Surface Pro laptop not restarting properly every time it went into hibernation. It would boot up into the text/options menu and not proceed to boot into windows. As it is always plugged in and used as a dedicated “desktop” for my ham apps I permanently disabled hibernation. He is a link to how to do that with additional options if it is a laptop and you will be using it as such.
https://www.pugetsystems.com/labs/support-software/How-to-disable-Sleep-Mode-or-Hibernation-793/
I also set my screen saver to a blank screen when it engages.
Good luck
73
Joel


locked Re: Request for new wsjt-x beviour #FT8

Larry Banks
 

Agree, and goes against the KISS principle.   But then I use JTAlert to find my next DX target so what is seen on WSJT-X is inconsequential.

73 -- Larry -- W1DYJ

 
Sent: Monday, January 11, 2021 16:46
Subject: Re: [WSJTX] Request for new wsjt-x beviour #FT8
 
Bill,
 
I believe Charlie would like his RX freq to revert to his own
TX freq automatically after a QSO so he doesn't have random
data showing in his RX Window. My vote would be against
such an option.
 
73,   Bob  K8BL
 
 
On Monday, January 11, 2021, 04:00:44 PM EST, Bill Somerville <g4wjs@...> wrote:
 
 
On 11/01/2021 19:22, hamradiosouth@... wrote:
> I am requesting an additional wsjt-x behavior titled (or something
> similar) "RX follows TX on CQ". Here is an example: I am in a QSO, TX
> is on 1800 and RX is on 1400. It doesn't matter if I called or I was
> called. Upon 73s, I immediately start another CQ at 1800. However, the
> RX is stranded at 1400 and now picking up extraneous info in the RX
> window. There are several ways to avoid that but they involve an
> additional click or key combo. Now if I had a check mark on the new
> requested behavior, when I started the CQ then WSJT-X would
> automatically bring the RX back to 1800.
> Charlie W4EBB

Charlie,

until someone answers your CQ the software has no idea what audio offset
they will be on, as soon as you double-click their call your Rx offset
will be moved to their offset. The software cannot do any better than that.


73

Bill
G4WJS.




locked Re: Request for new wsjt-x beviour #FT8

K8BL BOB LIDDY <k8bl@...>
 

Bill,

I believe Charlie would like his RX freq to revert to his own
TX freq automatically after a QSO so he doesn't have random
data showing in his RX Window. My vote would be against
such an option.

73,   Bob  K8BL


On Monday, January 11, 2021, 04:00:44 PM EST, Bill Somerville <g4wjs@...> wrote:


On 11/01/2021 19:22, hamradiosouth@... wrote:
> I am requesting an additional wsjt-x behavior titled (or something
> similar) "RX follows TX on CQ". Here is an example: I am in a QSO, TX
> is on 1800 and RX is on 1400. It doesn't matter if I called or I was
> called. Upon 73s, I immediately start another CQ at 1800. However, the
> RX is stranded at 1400 and now picking up extraneous info in the RX
> window. There are several ways to avoid that but they involve an
> additional click or key combo. Now if I had a check mark on the new
> requested behavior, when I started the CQ then WSJT-X would
> automatically bring the RX back to 1800.
> Charlie W4EBB

Charlie,

until someone answers your CQ the software has no idea what audio offset
they will be on, as soon as you double-click their call your Rx offset
will be moved to their offset. The software cannot do any better than that.


73

Bill
G4WJS.






locked Re: Involuntary CQing

Reino Talarmo
 

Hi,

 

> You quickly kill WSJT-X, and Restart
You enable Tx, and suddenly 6 stations are calling you, and the DX is long gone.  You're calling CQ unintentionally.

I think that you have a minor failure in your thinking.

After a restart you don’t have a selected target except CQ. Why not first receive and try to find again that super rare DX and select it before enabling TX?

Of course you could also type the rare DX call into “DX call” field and select proper “Tx even/1st” depending what DX happened to use and put your TX to a free spot and only then Enable Tx, I think.

Or have I missed something?

 

73, Reino OH3mA


locked Re: Request for new wsjt-x beviour #FT8

K8BL BOB LIDDY <k8bl@...>
 

Charlie...

I understand your point and also find it distracting - sometimes. But, the
operator that you just 73'd with may have a quick comment for you that
you'll miss if you instantly QSY your RX. Examples: HNY, NICE SIG,
PWR 2W, ANT VERT, C U SN, TNX NUGRID, TNX CHARLIE,
etc, etc, etc.

Therefore, I would vote against that feature. FT8/4 and sister modes are
already barely a QSO, as is. I'd hate to see things made totally wham/bam
without the chance for even a "Thank You M'am". What we really need
is an easy way to include a short comment within a QSO.

73/GL,  Bob  K8BL

Gil W0MN ----  I think Charlie was only referring to the data that shows
  up in the RX Frequency window (Right) after his QSO has ended.




On Monday, January 11, 2021, 03:30:05 PM EST, Gilbert Baron <w0mn00@...> wrote:


Does it really matter. Doesn’t the decode cover the entire bandwidth so you miss nothing.

 

Outlook Laptop Gil W0MN

Hierro candente, batir de repente

44.08226N 92.51265W EN34rb

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of hamradiosouth@...
Sent: Monday, January 11, 2021 13:23
To: main@WSJTX.groups.io
Subject: [WSJTX] Request for new wsjt-x beviour #FT8

 

I am requesting an additional wsjt-x behavior titled (or something similar) "RX follows TX on CQ". Here is an example: I am in a QSO, TX is on 1800 and RX is on 1400. It doesn't matter if I called or I was called. Upon 73s, I immediately start another CQ at 1800. However, the RX is stranded at 1400 and now picking up extraneous info in the RX window. There are several ways to avoid that but they involve an additional click or key combo. Now if I had a check mark on the new requested behavior, when I started the CQ then WSJT-X would automatically bring the RX back to 1800.
Charlie W4EBB


--

W0MN EN34rb 44.08226 N 92.51265 W

Hierro candente, batir de repente

HP Laptop




locked Re: #Cat_RigControl rig control for SDR-Console SDR-Radio (advice requested) #Cat_RigControl

N8CVW
 

Hi Bill

I installed com0com, but I’m admittedly just a button pusher, and cannot seem to push the right combination 😐

after installing I see these com0com devices as shown listed in Device Manager :

com15
com16
CNCB2
CNCA0
CNCA2
CNCB0

my understanding is that pairs are comprised of :

com15 - com16
CNCA0 - CNCB0
CNCA2 - CNCB2

there are 4 potential “consumers” for ports :

A) SDR Console emulating a TS2000, configuration in TOOLS —> SETTINGS —> OPTIONS

B) WSJT-X TS2000 Radio configuration in FILE —> SETTINGS —> RADIO —> RIG: (TS2000 entry)

C) OmniRig2 SETTINGS —> RIG1, RIG2 ,,, which weirdly sometimes shows a RIG3 and a RIG4 but other times only shows RIG1 & RIG2 options

D) SDR Console “External Radio”

so the $64,000 Question : What goes where ???

On Jan 11, 2021, at 12:52 PM, Bill Somerville <g4wjs@...> wrote:

On 11/01/2021 16:31, N8CVW wrote:
i should probably just install com0com and this would likely all fall into place with the needed com port appearing both in SDRC & WSJTX (?)
Hi Paul,

com0com is one of a number of utilities that can provide a virtual serial port loopback. Like a cross-ver modem cable but all within software. Once you configure a serial port loopback pair you will have two new virtual serial ports, connect one to the Kenwood TS-2000 rig emulating in SDR-Console and the other to WSJT-X as if it were talking to TS-2000.

73
Bill
G4WJS.



19421 - 19440 of 39792