Date   

locked Re: Using radios for wajtx and remote #Cat_RigControl

Gerald Klotz
 

I do have power out now both locally on the server and remotely. I am not sure but I believe the problem was with the com ports. I ended up installing a few things then reinstalling it and then renamed the cöm ports for the radio. Windows update is not your friend as far as com ports are involved.

Gerry Klotz

On Apr 19, 2021, at 7:46 PM, Joel <styx@...> wrote:


Gerry

Do you now have power out on transmit - it appeared that was the original problem that you were concerned about?

Joel
AC8WS

On Apr 19, 2021, at 8:19 PM, Gerald Klotz <KB9PKI@...> wrote:

Yes the settings are separate. I have the radios working locally with wsjtx and through rsbs1 locally. The radios now work remotely but I am trying to get FLdigi and flrig set up. 
I have flrig and Fldigi working locally on the 7300 but not on the 9700. I haven’t gotten Fldigi or flrig working remotely yet.

Gerry Klotz
Kb9pki

On Apr 19, 2021, at 6:25 PM, Dave Garber <ve3wej@...> wrote:


are you settings things separate under the configurations tab??

Dave Garber
VE3WEJ / VE3IE


On Tue, Apr 13, 2021 at 4:02 PM Gerald Klotz <KB9PKI@...> wrote:

Good afternoon. I got my income 7300 and 9700 set up and working again but forgot to check output power, which turns out to be zip. 

I went ahead and worked on the icom res-ba1 software and got that working remotely with both radios. I went to do some ft8 and no power out. I know it’s something in the settings somewhere, but I keep missing it. Everything works fine and I. An control both rigs but can’t transmit any power on either radio. Both have their own codec installed and assigned.

When I switch to 144.174 the software switches radios and then to the hf radio for hf freq’s.

Anyone have an idea?














Mike Cummings
 

I'm stumped and can't find anything about this issue after a lot of googling.

I'm on Windows 10 on an ASUS laptop and my rig is an IC-7300.

Suddenly, when I attempt to transmit (FT8) with my IC-7300, I get transmission, but at the end of the cycle, it just keeps transmitting. The only way to stop it is with the TRANSMIT button on the front panel. But after that, PTT control seems to be locked. Then the Test PTT button in Settings is grayed out. If I try exiting WSJT-X and relaunch, I get a message that another instance is running and it asks me if I want to remove the stale lock file. No answer works, and I can't kill it in Task Manager. All I can do is reboot, but then after launching WSJT-X, I just have the same problem.

I've been running FT8 every day for a week without problem. The only thing that's different is that I installed Gridtracker. The problem occurs whether Gridtracker is running or not.

My station isn't permanent. I live in a small rental house with no room for a shack, so I set up outside. I don't have a proper ground, because I can't here. I'm not allowed to drive a ground rod. I'm using an end-fed with my internal tuner. I know it's a compromise antenna. It's what I have for now. It's hard to get my ideal antenna due to rental restrictions and the fact that I'm disabled. I'm just using a USB cable without an intervening interface.

What gets me is that I've made 150 or so QSOs the past few days without problems and I haven't changed anything. I've reinstalled the USB driver, rearranged my USB cable, which had ferrite beads on both ends, and I don't know what else to do. Any ideas would be welcome.

Thanks.

Mike NX7E


locked Re: Using radios for wajtx and remote #Cat_RigControl

Joel
 

Gerry

Do you now have power out on transmit - it appeared that was the original problem that you were concerned about?

Joel
AC8WS

On Apr 19, 2021, at 8:19 PM, Gerald Klotz <KB9PKI@...> wrote:

Yes the settings are separate. I have the radios working locally with wsjtx and through rsbs1 locally. The radios now work remotely but I am trying to get FLdigi and flrig set up. 
I have flrig and Fldigi working locally on the 7300 but not on the 9700. I haven’t gotten Fldigi or flrig working remotely yet.

Gerry Klotz
Kb9pki

On Apr 19, 2021, at 6:25 PM, Dave Garber <ve3wej@...> wrote:


are you settings things separate under the configurations tab??

Dave Garber
VE3WEJ / VE3IE


On Tue, Apr 13, 2021 at 4:02 PM Gerald Klotz <KB9PKI@...> wrote:

Good afternoon. I got my income 7300 and 9700 set up and working again but forgot to check output power, which turns out to be zip. 

I went ahead and worked on the icom res-ba1 software and got that working remotely with both radios. I went to do some ft8 and no power out. I know it’s something in the settings somewhere, but I keep missing it. Everything works fine and I. An control both rigs but can’t transmit any power on either radio. Both have their own codec installed and assigned.

When I switch to 144.174 the software switches radios and then to the hf radio for hf freq’s.

Anyone have an idea?











locked Re: #bugreport ALL.TXT #IssueReport

Sam Birnbaum
 

Hi Bill,

Yes, it is a bug. I would suggest you test the RC release of ver 2.4 and see if it is in there as well.

I had to make special provisions in my Alltext.exe program to accommodate that bug.  

73,
 
Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: main@wsjtx.groups.io
Sent: Mon, Apr 19, 2021 8:11 pm
Subject: Re: [WSJTX] #bugreport ALL.TXT

So if adding the date to the beginning of a log file takes more than a handful of microseconds, I would be surprised. The bulk of time would be actually taking the underlying unix time (in seconds) and converting it to a string. This is already done for the display of the signal on the left panel.

Secondly, the date is not changing on either the 1.840 lines, nor on the 18.100 or the 10.136 FT8 lines, but the time is put on those lines.  Clearly the time changes, however.

Further, for the MSK144 lines, they occupy the clock time between 210419_140330 and 240419_070515, which is on the order of 7 hours. At what time does the line Z4VUR/R RH0BDY/R R DH26 occur? There is no way to tell from ALL.TXT.

Finally, why would it behave differently on FT8 as opposed to MSK144?

With respect to the release notes, for RC3 it says:

 - Repair regression with missing time-stamps in the ALL.TXT journal.

It would appear from my RC3 use and now RC4, that there are situations still exhibiting the behavior.

I am thinking this is a bug.

On Mon, Apr 19, 2021 at 6:18 PM Dave Garber <ve3wej@...> wrote:
this has been this way for quite a while, I would have to look at release notes.  but sounds normal.  if the date does not change why append with it and slow the process..

Dave Garber
VE3WEJ / VE3IE


On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer <w8lvn.9@...> wrote:
This issue still exists for Rc4, but apparently only for MSK144.


Looks fine for FT8, but not MSK144

210419_070415     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070445     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070515     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144  -6  7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -6  9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -1  2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144  -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144   0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144  -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144   1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144  -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144   8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144  11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144  12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144  15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144  13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144  14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144   3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144   4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144   6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144   7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144  13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144   5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144   6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144   7 29.3 1460 VE4CY W9DR RRR
210419_140330    18.100 Rx FT8     -6  0.2  780 N5HHS N3GX R+05
210419_140330    18.100 Rx FT8    -11  0.2 1591 KB2M KI4KDR EM45
210419_140330    18.100 Rx FT8    -12  0.1 1261 CQ N3NVA FN20
210419_140400    10.136 Rx FT8     14  0.1 1328 CQ VA3MJR FN03
210419_140400    10.136 Rx FT8      1  0.1  607 KG0TR VE3RXO R-13


Thanks,
w8lvn


On Mon, Apr 19, 2021 at 10:59 AM Bill Lederer via groups.io <w8lvn.9=gmail.com@groups.io> wrote:
Well, my issue was in the RC3 release.  I'm now running with RC4, and will see if it iis still there.

w8lvn

On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io <w2jdb=aol.com@groups.io> wrote:
Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--








--
--w8lvn--





--
--w8lvn--








--
--w8lvn--




locked Re: Using radios for wajtx and remote #Cat_RigControl

Gerald Klotz
 

Yes the settings are separate. I have the radios working locally with wsjtx and through rsbs1 locally. The radios now work remotely but I am trying to get FLdigi and flrig set up. 
I have flrig and Fldigi working locally on the 7300 but not on the 9700. I haven’t gotten Fldigi or flrig working remotely yet.

Gerry Klotz
Kb9pki

On Apr 19, 2021, at 6:25 PM, Dave Garber <ve3wej@...> wrote:


are you settings things separate under the configurations tab??

Dave Garber
VE3WEJ / VE3IE


On Tue, Apr 13, 2021 at 4:02 PM Gerald Klotz <KB9PKI@...> wrote:

Good afternoon. I got my income 7300 and 9700 set up and working again but forgot to check output power, which turns out to be zip. 

I went ahead and worked on the icom res-ba1 software and got that working remotely with both radios. I went to do some ft8 and no power out. I know it’s something in the settings somewhere, but I keep missing it. Everything works fine and I. An control both rigs but can’t transmit any power on either radio. Both have their own codec installed and assigned.

When I switch to 144.174 the software switches radios and then to the hf radio for hf freq’s.

Anyone have an idea?








locked Re: #bugreport ALL.TXT #IssueReport

Bill Lederer
 

So if adding the date to the beginning of a log file takes more than a handful of microseconds, I would be surprised. The bulk of time would be actually taking the underlying unix time (in seconds) and converting it to a string. This is already done for the display of the signal on the left panel.

Secondly, the date is not changing on either the 1.840 lines, nor on the 18.100 or the 10.136 FT8 lines, but the time is put on those lines.  Clearly the time changes, however.

Further, for the MSK144 lines, they occupy the clock time between 210419_140330 and 240419_070515, which is on the order of 7 hours. At what time does the line Z4VUR/R RH0BDY/R R DH26 occur? There is no way to tell from ALL.TXT.

Finally, why would it behave differently on FT8 as opposed to MSK144?

With respect to the release notes, for RC3 it says:

 - Repair regression with missing time-stamps in the ALL.TXT journal.

It would appear from my RC3 use and now RC4, that there are situations still exhibiting the behavior.

I am thinking this is a bug.

On Mon, Apr 19, 2021 at 6:18 PM Dave Garber <ve3wej@...> wrote:
this has been this way for quite a while, I would have to look at release notes.  but sounds normal.  if the date does not change why append with it and slow the process..

Dave Garber
VE3WEJ / VE3IE


On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer <w8lvn.9@...> wrote:
This issue still exists for Rc4, but apparently only for MSK144.


Looks fine for FT8, but not MSK144

210419_070415     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070445     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070515     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144  -6  7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -6  9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -1  2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144  -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144   0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144  -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144   1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144  -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144   8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144  11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144  12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144  15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144  13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144  14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144   3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144   4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144   6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144   7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144  13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144   5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144   6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144   7 29.3 1460 VE4CY W9DR RRR
210419_140330    18.100 Rx FT8     -6  0.2  780 N5HHS N3GX R+05
210419_140330    18.100 Rx FT8    -11  0.2 1591 KB2M KI4KDR EM45
210419_140330    18.100 Rx FT8    -12  0.1 1261 CQ N3NVA FN20
210419_140400    10.136 Rx FT8     14  0.1 1328 CQ VA3MJR FN03
210419_140400    10.136 Rx FT8      1  0.1  607 KG0TR VE3RXO R-13


Thanks,
w8lvn


On Mon, Apr 19, 2021 at 10:59 AM Bill Lederer via groups.io <w8lvn.9=gmail.com@groups.io> wrote:
Well, my issue was in the RC3 release.  I'm now running with RC4, and will see if it iis still there.

w8lvn

On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io <w2jdb=aol.com@groups.io> wrote:
Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--








--
--w8lvn--





--
--w8lvn--








--
--w8lvn--


locked Re: Using radios for wajtx and remote #Cat_RigControl

Dave Garber
 

are you settings things separate under the configurations tab??

Dave Garber
VE3WEJ / VE3IE


On Tue, Apr 13, 2021 at 4:02 PM Gerald Klotz <KB9PKI@...> wrote:

Good afternoon. I got my income 7300 and 9700 set up and working again but forgot to check output power, which turns out to be zip. 

I went ahead and worked on the icom res-ba1 software and got that working remotely with both radios. I went to do some ft8 and no power out. I know it’s something in the settings somewhere, but I keep missing it. Everything works fine and I. An control both rigs but can’t transmit any power on either radio. Both have their own codec installed and assigned.

When I switch to 144.174 the software switches radios and then to the hf radio for hf freq’s.

Anyone have an idea?





locked Re: #bugreport ALL.TXT #IssueReport

Sam Birnbaum
 

I has not been this way for a long time. It was a bug that was corrected but seems to be still in the version that bill is using.
I was running the Windows version and it was corrected in a later RC release. 
If appending the date and time slows the process on your PC, then you have a problem with your hardware.

73, 

Sam W2JDB



-----Original Message-----
From: Dave Garber <ve3wej@...>
To: WSJT-x group <main@wsjtx.groups.io>
Sent: Mon, Apr 19, 2021 7:17 pm
Subject: Re: [WSJTX] #bugreport ALL.TXT

this has been this way for quite a while, I would have to look at release notes.  but sounds normal.  if the date does not change why append with it and slow the process..

Dave Garber
VE3WEJ / VE3IE


On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer <w8lvn.9@...> wrote:
This issue still exists for Rc4, but apparently only for MSK144.


Looks fine for FT8, but not MSK144

210419_070415     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070445     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070515     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144  -6  7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -6  9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -1  2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144  -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144   0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144  -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144   1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144  -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144   8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144  11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144  12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144  15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144  13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144  14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144   3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144   4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144   6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144   7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144  13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144   5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144   6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144   7 29.3 1460 VE4CY W9DR RRR
210419_140330    18.100 Rx FT8     -6  0.2  780 N5HHS N3GX R+05
210419_140330    18.100 Rx FT8    -11  0.2 1591 KB2M KI4KDR EM45
210419_140330    18.100 Rx FT8    -12  0.1 1261 CQ N3NVA FN20
210419_140400    10.136 Rx FT8     14  0.1 1328 CQ VA3MJR FN03
210419_140400    10.136 Rx FT8      1  0.1  607 KG0TR VE3RXO R-13

Thanks,
w8lvn


On Mon, Apr 19, 2021 at 10:59 AM Bill Lederer via groups.io <w8lvn.9=gmail.com@groups.io> wrote:
Well, my issue was in the RC3 release.  I'm now running with RC4, and will see if it iis still there.

w8lvn

On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io <w2jdb=aol.com@groups.io> wrote:
Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--








--
--w8lvn--





--
--w8lvn--







locked Re: #bugreport ALL.TXT #IssueReport

Dave Garber
 

this has been this way for quite a while, I would have to look at release notes.  but sounds normal.  if the date does not change why append with it and slow the process..

Dave Garber
VE3WEJ / VE3IE


On Mon, Apr 19, 2021 at 5:47 PM Bill Lederer <w8lvn.9@...> wrote:
This issue still exists for Rc4, but apparently only for MSK144.


Looks fine for FT8, but not MSK144

210419_070415     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070445     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070515     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144  -6  7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -6  9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -1  2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144  -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144   0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144  -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144   1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144  -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144   8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144  11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144  12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144  15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144  13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144  14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144   3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144   4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144   6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144   7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144  13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144   5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144   6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144   7 29.3 1460 VE4CY W9DR RRR
210419_140330    18.100 Rx FT8     -6  0.2  780 N5HHS N3GX R+05
210419_140330    18.100 Rx FT8    -11  0.2 1591 KB2M KI4KDR EM45
210419_140330    18.100 Rx FT8    -12  0.1 1261 CQ N3NVA FN20
210419_140400    10.136 Rx FT8     14  0.1 1328 CQ VA3MJR FN03
210419_140400    10.136 Rx FT8      1  0.1  607 KG0TR VE3RXO R-13


Thanks,
w8lvn


On Mon, Apr 19, 2021 at 10:59 AM Bill Lederer via groups.io <w8lvn.9=gmail.com@groups.io> wrote:
Well, my issue was in the RC3 release.  I'm now running with RC4, and will see if it iis still there.

w8lvn

On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io <w2jdb=aol.com@groups.io> wrote:
Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--








--
--w8lvn--





--
--w8lvn--




locked Re: #bugreport ALL.TXT #IssueReport

Bill Lederer
 

This issue still exists for Rc4, but apparently only for MSK144.


Looks fine for FT8, but not MSK144

210419_070415     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070445     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
210419_070515     1.840 Tx FT8      0  0.0 1612 CQ W8LVN EN62
50.260 Rx MSK144  -6  7.0 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 11.3 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -6  9.8 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -5 13.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  1.1 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -1  2.5 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -2  0.7 1440 VE9GJ K2DRH EN41
50.260 Rx MSK144  -7 13.3 1440 VE9GJ K2DRH RRR
50.260 Rx MSK144  -1 26.4 1475 N0AN K1RZ +02
50.260 Rx MSK144   0 23.0 1472 N0AN N1KWF FN32
50.260 Rx MSK144  -1 22.6 1460 N0AN N1KWF FN32
50.260 Rx MSK144   1 28.9 1464 N0AN N1KWF FN32
50.260 Rx MSK144  -8 28.6 1443 Z4VUR/R RH0BDY/R R DH26
50.260 Rx MSK144   8 22.6 1462 VE4CY W9DR EM78
50.260 Rx MSK144  11 22.9 1462 VE4CY W9DR EM78
50.260 Rx MSK144  12 27.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144  15 27.3 1460 VE4CY W9DR EM78
50.260 Rx MSK144  13 15.5 1460 VE4CY W9DR EM78
50.260 Rx MSK144  14 26.1 1462 VE4CY W9DR EM78
50.260 Rx MSK144   3 16.0 1462 VE4CY W9DR EM78
50.260 Rx MSK144   4 16.0 1463 VE4CY W9DR EM78
50.260 Rx MSK144   6 16.6 1461 VE4CY W9DR EM78
50.260 Rx MSK144   7 16.7 1461 VE4CY W9DR EM78
50.260 Rx MSK144  13 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  14 18.4 1463 VE4CY W9DR EM78
50.260 Rx MSK144  -3 15.5 1463 VE4CY W9DR EM78
50.260 Rx MSK144   5 20.8 1462 VE4CY W9DR RRR
50.260 Rx MSK144   6 29.2 1462 VE4CY W9DR RRR
50.260 Rx MSK144   7 29.3 1460 VE4CY W9DR RRR
210419_140330    18.100 Rx FT8     -6  0.2  780 N5HHS N3GX R+05
210419_140330    18.100 Rx FT8    -11  0.2 1591 KB2M KI4KDR EM45
210419_140330    18.100 Rx FT8    -12  0.1 1261 CQ N3NVA FN20
210419_140400    10.136 Rx FT8     14  0.1 1328 CQ VA3MJR FN03
210419_140400    10.136 Rx FT8      1  0.1  607 KG0TR VE3RXO R-13


Thanks,
w8lvn


On Mon, Apr 19, 2021 at 10:59 AM Bill Lederer via groups.io <w8lvn.9=gmail.com@groups.io> wrote:
Well, my issue was in the RC3 release.  I'm now running with RC4, and will see if it iis still there.

w8lvn

On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io <w2jdb=aol.com@groups.io> wrote:
Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--








--
--w8lvn--





--
--w8lvn--


locked Re: #bugreport ALL.TXT #IssueReport

Bill Lederer
 

Well, my issue was in the RC3 release.  I'm now running with RC4, and will see if it iis still there.

w8lvn

On Mon, Apr 19, 2021 at 6:41 AM Sam Birnbaum via groups.io <w2jdb=aol.com@groups.io> wrote:
Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--








--
--w8lvn--


locked Re: Q65 in less favourable condx? #Q65

Joe
 

Hi Jim and all,
Scatter signals are so highly variable that the only way to make
statistically reliable quantitative comparisons of different sumodes is
to transmit and receive them simultaneously.
Very interesting. Given the highly variable nature of propagation and
the different modes of which we try to take advantage, it would be
interesting to see this sort of work repeated on multiple days and at
different times of day.
Probably it will not surprise you that we've done some of this, especially with respect to time of day.  It's very easy to show that ionoscatter conditions are best around mid-day and worst around 7 or 8 PM local time. 

But we decided not to spend time on more extensive tests with respect to time of year, but rather to spend some time in a good research library.  Steve and I have access to excellent ones at the University of Illinois and Princeton University, respectively.

D-Region ionospheric scattering at VHF was studied exhaustively in the late 1950s.  An excellent summary of such studies carried out by the Central Radio Propagation Laboratory of the US National Bureau of Standards was published in 1961, and I've posted a copy here:
https://physics.princeton.edu/pulsar/k1jt/NBS_D-region_scatter.pdf

For a summary of diurnal, seasonal, and frequency dependence of signal strengths see their Figure 6.

  -- 73, Joe, K1JT


locked #FST4 Coding On a PIC #FST4

Andy Talbot
 

A brief update on progress.
PIC code for the later generation enhanced device, the 16F1827, now exists that will
turn 13 characters of Plain text, or  17.75 Hex characters  into a set of symbols ready to go for transmission.
So the encoding stage is complete.  I have no interest in compressing any other types of message, just plain text and Telemetry (raw data).  At the moment the Plain Text is retrieved from the EEProm memory space. or Telemetry format data entered as a hex string into the assembly file.

The whole encoding routine takes up a bit less than 2K words of  programme memory.  Of that 1112  (14 bit) words are for the parity matrix, and 768 words of executable code

Now that is done and tested, I want to take a break for a bit before combining it with the beacon source - not least as there are still things to learn about the 16F1827 PIC device.  I used this FST4 encoding exercise as a way to break into using that more advanced chip.

The code won't be made public just yet, but if anyone does want a copy of what is written so far, please contact me off-Group.
 
Note that this is for FST4, not FST4W.   The latter wouldn't need too many changes; source encoding, parity matrix and various pointer and constant values. 


locked Re: WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Phil Moore
 

Hi Mark
I also have a 6400 and have had similar - mine changes to LSB on 40m downwards - I think due to the turf file on the 6400 assuming that those bands are normally LSB. All other bands work fine. I get around it by using FR Stacks most recently used memories to change to the affected bands which remembers that I want USB. It also has some other natty features such as when I select 60m, it changes the profile being used, changes to ANT2 and alters the TX upper filter appropriately.
Hope that helps. It's a useful add on for Flex users.
73
Phil M0TZZ


locked Re: WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Bill Somerville
 

On 19/04/2021 02:22, Mark Gottlieb wrote:
Good Evening All,

I have been operating WSJT-x for years and have not had this problem before.   My FLEX 6400 just started defaulting to LSB on TX on all bands.  I am not having the same problem with FLDIGI.  I have been using FLEX equipment for the last 5 years.  Can't figure out the cause.  Any suggestions?

73

Mark
KK2L
Hi Mark,

this is due to a regression in the TS-200 driver in hamlib, which I assume you are using. It is fixed for the next release, you can either change to "Settings->Radio->None" in WSJT-X and set the mode manually, or use the Flex 6xxx network driver in WSJT-X to communicate directly with SmartSDR, which does not have this fault.

73
Bill
G4WJS.


locked Re: #bugreport ALL.TXT #IssueReport

Sam Birnbaum
 

Hi Bill,

I ran into this problem when I tested some function in my Alltext.exe program that I sued for the same function.
I found that when I used WSJT-X  2.3 rc1 (or rc2).  The Date and time was only included in the TX record that
was written to the All.txt file.

I believe the problem was fixed when 2.3 rc3 was released.

73,  

Sam W2JDB



-----Original Message-----
From: Bill Lederer <w8lvn.9@...>
To: WSJTX@groups.io
Sent: Sun, Apr 18, 2021 9:54 pm
Subject: [WSJTX] #bugreport ALL.TXT

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--




locked Re: WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Dave Garber
 

on the radio settings tab, see if mode is set to data/pkt,  your radio may be trying to use bandplan as its setting, this should override it, i think

Dave Garber
VE3WEJ / VE3IE


On Sun, Apr 18, 2021 at 10:03 PM Mark Gottlieb <kk2l@...> wrote:
Good Evening All,

I have been operating WSJT-x for years and have not had this problem before.   My FLEX 6400 just started defaulting to LSB on TX on all bands.  I am not having the same problem with FLDIGI.  I have been using FLEX equipment for the last 5 years.  Can't figure out the cause.  Any suggestions?

73

Mark
KK2L



locked #bugreport ALL.TXT #IssueReport

Bill Lederer
 

Team:

I am noticing that under some conditions, the date field is omitted from ALL.TXT for monitored calls, but not for transmissions I make.

What is a little more odd, this did happen when switching from 160 meter FT8 to 6 meter MSK144.

Is this a known issue?

I have just downloaded and installed the rc4 version in case the issue is resolved.

(I use the ALL.TXT file to recreate QSOs that don't get properly logged due to an xquartz crash. Usually I run WSJTX on Intel NUCs running Ubuntu after doing "ssh -Y <linux-host>" and xterm. Works most of the time, but xquartz on mac has proven to be unexpectedly crash-worthy.)

--w8lvn--

--
--w8lvn--


locked WSJT-X DEFAULTS TO LSB ON TX #FT8 #transmit

Mark Gottlieb
 

Good Evening All,

I have been operating WSJT-x for years and have not had this problem before.   My FLEX 6400 just started defaulting to LSB on TX on all bands.  I am not having the same problem with FLDIGI.  I have been using FLEX equipment for the last 5 years.  Can't figure out the cause.  Any suggestions?

73

Mark
KK2L


locked Re: Q65 in less favourable condx? #Q65

Joe Dz
 

Thank you Joe for the data and Jim also makes a very good comment. When I
was looking at how weather storm systems affect transatlantic 6m
communications, and also during the winter months when we have the second Es
season, Es formed over storm systems and fast moving jet stream fronts.
However, a geomagnetic storm (G1 or K5 or better) would negate the effect.
It would be very interesting to see as people collect data, that they also
record what the geomagnetic field was doing at the time. The question
being: does an unsettled or stormy geomagnetic field also negate the
ionosphere scatter like it negates the weather effects that would normally
cause Es over storm systems or fronts?

If folks also record the K value as well on multiple day tests, that data
would be very interesting.

Joe, K1YOW

-----Original Message-----
From: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] On Behalf Of Jim
Brown
Sent: Sunday, April 18, 2021 3:24 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] Q65 in less favourable condx? #Q65

On 4/18/2021 9:08 AM, Joe wrote:
Scatter signals are so highly variable that the only way to make
statistically reliable quantitative comparisons of different sumodes is
to transmit and receive them simultaneously.
Very interesting. Given the highly variable nature of propagation and
the different modes of which we try to take advantage, it would be
interesting to see this sort of work repeated on multiple days and at
different times of day.

73, Jim K9YC

12861 - 12880 of 37058