Date   

locked Re: macOS NTP problems in Big Sur #Timesync #macOS

Ken Cox
 

I have an Imac and Macbook pro running big sur with no time issues. Time.is reports exact time +0.0003 seconds


locked Re: RC4 Q65 bugs ? #Q65

Bill Somerville
 

On 29/03/2021 14:38, ny2ny wrote:
Hi - observed 2 issues with RC4 Q65 and not sure if its just "cockpit error" hihi...
* RR73 turns off ENABLE XMIT even if AUTO SEQUENCE is unchecked
* SH tones in Q65 transmit OK but do not decode
Anyhow - love Q65...always gets thru when FT8 fails...
 Tnx Joe and team...73
--
jay ny2ny
Hi Jay,

we are aware of the sequencing issue you mention, it should be fixed in a later release.

The short code tones used in Q65 are like the ones used in JT4 mode and are only ment for a visual indication on the waterfall. They are not like the dual tone JT65 ones. We are confident that decodable short codes would add no value to Q65 as the decoder will decode full messages down to the sensitivity level where they may be considered. These type of single short code tones may be of some value for microwave operations, particularly EME, otherwise I would recommend sticking to full messages and the extra information they convey.

73
Bill
G4WJS.


locked Re: rc-4 Q65 weirdness? #IssueReport

K0GU
 

Thanks. I had Auto Clear Avg turned on but Enable averaging was not on.
--
73,  Jay  K0GU  DN70mq


locked Re: Tried to upgrade WSJT-X to 2.4, now stuck trying to downgrade to previously working ver. 2.2.2 #AudioIssues #raspberryPi #txaudio

marksheffield@...
 

Hi Joel, thanks for the reply, but yes,  I've gone back and forth with an older hamlib (using -m 204) and new hamlib (using -m 2004) and using the hamlib linked with wsjtx (wsjtx-rigctl and wsjtx-rigctld, which uses -m 2004) for all combinations of daemon and rigctl, none of these fixes the "no tone" issue.  


locked Re: macOS NTP problems in Big Sur #Timesync #macOS

Steve Golson
 

On 3/29/21 9:11 AM, Steve Golson wrote:
Hi all,
If you are running Big Sur on Mac, check your time. Try https://time.is
There seems to be a defect in Apple's "timed" daemon, which is responsible for maintaining accurate time in Big Sur. I saw an offset of 2s, but others have reported tens of seconds.
I just realized I'm running a non-standard version of sntp. So this command:

7. Now open Terminal and type
  sudo sntp -sS time.apple.com
may not work for you.

I'm continuing to investigate, and I'll report back what I find.

73,
Steve
W1SEG


locked RC4 Q65 bugs ? #Q65

ny2ny
 

Hi - observed 2 issues with RC4 Q65 and not sure if its just "cockpit error" hihi...
* RR73 turns off ENABLE XMIT even if AUTO SEQUENCE is unchecked
* SH tones in Q65 transmit OK but do not decode
Anyhow - love Q65...always gets thru when FT8 fails...
 Tnx Joe and team...73
--
jay ny2ny


locked Re: version 2.3.1 forces lsb mode #FT8

Lyle Fisher N0LWF
 

I had the same problem on my Flex 5000. I found uninstalling all previous versions of WSJT and deleting the .ini file solved the problem.

Lyle N0LWF


locked macOS NTP problems in Big Sur #Timesync #macOS

Steve Golson
 

Hi all,

If you are running Big Sur on Mac, check your time. Try https://time.is

There seems to be a defect in Apple's "timed" daemon, which is responsible for maintaining accurate time in Big Sur. I saw an offset of 2s, but others have reported tens of seconds.

See these discussions:

https://apple.stackexchange.com/questions/414088/macos-timed-wont-keep-accurate-time

https://forums.macrumors.com/threads/time-synchronization-command-line-in-macos-big-sur.2279396/

According to those links, Apple is aware of this bug. So hopefully they will have a fix in a future update.

It appears that something confuses the state of "timed" and as a result it successfully tracks UTC, but with an offset.

If your time is accurate, then don't do anything. But if your time is messed up, here is a workaround.

I don't know which of these steps are really necessary, but it's worked for me... I'm running macOS 11.2.3 on both Intel and M1.

1. Open System Preferences / Date & Time / Date & Time

2. "Set date and time automatically" should be checked, which indicates you've been relying on the flawed "timed" daemon.

3. Click the lock to make changes

4. Change the host to the default "time.apple.com."

5. Uncheck the box

6. Close the System Preferences window

7. Now open Terminal and type

sudo sntp -sS time.apple.com

sudo will prompt you to enter your password.

This command will force your computer's time to the correct value. You should see something like

sntp 4.2.8p15@1.3728-o Thu Jun 25 23:19:02 UTC 2020 (1)
2021-03-28 14:17:41.837540 (+0500) +2.18836 +/- 1.459743 time.apple.com 17.253.4.253 s1 no-leap

What's being reported here:

version info about sntp command: sntp 4.2.8p15@1.3728-o Thu Jun 25 23:19:02 UTC 2020 (1)
current time on your computer: 2021-03-28 14:17:41.837540 (+0500)
estimated error in the time on your computer: +2.18836 +/- 1.459743
info about the time server you have selected: time.apple.com 17.253.4.253 s1 no-leap

You might get warning messages like this:

kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or directory
kq_init: detected broken kqueue; not using.: No such file or directory

That's nothing to worry about.

8. Confirm that your time is now correct, by typing in Terminal

sntp time.apple.com

and you should see something like

sntp 4.2.8p15@1.3728-o Thu Jun 25 23:19:02 UTC 2020 (1)
2021-03-28 14:18:22.880936 (+0500) +0.00023 +/- 0.000977 time.apple.com 17.253.4.253 s1 no-leap

Notice the error is now close to zero. You can run this command whenever you want, to check your clock's accuracy.

9. Restart your computer

10. Let it run for an hour

11. Open System Preferences / Date & Time / Date & Time

12. Click the lock to make changes

13. Check the box for "Set date and time automatically"

14. Close the System Preferences window

Now, "timed" should be running smoothly. Don't make any more changes to the Date & Time preferences! I think that may screw up the daemon.

You can confirm your accuracy by running "sntp time.apple.com" in a Terminal window.


All this time, us Mac guys have felt soooo superior to the poor Windows users trying to keep their clocks in sync! and now we get hosed :-)

73,
Steve
W1SEG


locked Re: Ubuntu 20.04 & wsjtx2.3.0 ALSA audio HW:x,y challenges #AudioIssues #linux

Bill Somerville
 

On 29/03/2021 12:24, mike.j.kasper@... wrote:
I didn't expect BOTH to be valid, but I did expect the "mono" option to work the same on the DSNOOP and HW as it does on PLUGHW. 

Obviously (now that I found the "answer")  HW and DSNOOP refuse to go into a single channel mode even though they claim to allow it.  Maybe wsjtx is asking this hardware in the "wrong way?".  The challenge to figuring out what was wrong is the limited and somewhat misleading feedback in the error dialog:
"Error in Sound Input Requested input audio format is not supported on device". 

This led me to believe it was a format issue (aka sample rate or format issue - NOT a channel count issue). 

In the end, I thought I'd share this "discovery" as I hadn't found it in any google searches.

Thanks for the help - it's always quick and helpful!

-Mike
N8RAW

Hi Mike,

yes format does include channels, all WSJT-X does is check the available formats using the Qt QAudioDeviceInfo::isFormatSupported API, that is an operating system neutral wrapper on the underlying audio sub-system which we do not have direct access to (pulseaudio in this case).

https://doc.qt.io/qt-5/qaudiodeviceinfo.html#isFormatSupported

I was under the impression that a request for a mono stream would at least be satisfied by using the left channel is no specific mono format was available, perhaps that is not so in this case. Surely if the underlying audio stream does not support mono then there should be no problem with you selecting either the left or right channel from a stereo pair of channels.

73
Bill
G4WJS.


locked Re: Ubuntu 20.04 & wsjtx2.3.0 ALSA audio HW:x,y challenges #AudioIssues #linux

mike.j.kasper@...
 

I didn't expect BOTH to be valid, but I did expect the "mono" option to work the same on the DSNOOP and HW as it does on PLUGHW. 

Obviously (now that I found the "answer")  HW and DSNOOP refuse to go into a single channel mode even though they claim to allow it.  Maybe wsjtx is asking this hardware in the "wrong way?".  The challenge to figuring out what was wrong is the limited and somewhat misleading feedback in the error dialog:
"Error in Sound Input Requested input audio format is not supported on device". 

This led me to believe it was a format issue (aka sample rate or format issue - NOT a channel count issue). 

In the end, I thought I'd share this "discovery" as I hadn't found it in any google searches.

Thanks for the help - it's always quick and helpful!

-Mike
N8RAW


locked Re: rc-4 Q65 weirdness? #IssueReport

Hasan Schiers N0AN
 

Turn on Autoclear Avg after decode and that will work around the problem for  now. Make sure Enable Average is on.

73, N0AN 



Hasan


On Sun, Mar 28, 2021, 6:15 PM K0GU <k0gu@...> wrote:
I'll attach a screen shot below. K7MAC called me and decoded twice on the same sequence on the same frequency about 4 seconds apart (EME delay is not turned on). You can see in the TX window that apparently it restarted my xmit seq? Other stations also double decoded twice on the same frequency.

Note: These are all across mountain shots and Doppler is not unusual. I would not be surprised to see double decodes on WB7CJO's main frequency plus his Doppler frequency. But on some sequences he decodes twice on the same freq with different signal reports. So check the freqs carefully as Q65 will apparently separate signal that are very close together.



locked Re: #q65 Mode q65 on 6 meters #Q65

Jim Brown
 

On 3/28/2021 4:11 PM, Bill Lederer wrote:
Now i dearly hope that this is not EME, as I will be seriously freaked out. For one, the moon is below the horizon, and secondly, my antenna is an 80 meter dipole  up about 50 feet.
Hi Bill,

Before I had aluminum in the air here in NorCal, I worked a bunch of single-hop and at least a dozen double-hop CW QSOs to the east coast and KH6, switching between the two 80M dipoles at right angles to each other at about 110 ft, fed with RG11. I switched between them to choose the loudest. It's early for Es, but I've been seeing posts on the VHF-Slack group about occasional brief single hop openings. And 700 miles is not a lot for ionoscatter.

73, Jim K9YC


locked Re: #q65 Mode q65 on 6 meters #Q65

Ben Nardi
 

Bill,

I think you heard Joe K1JT on either sporadic E or ionospheric scatter or tropo. He has a good signal and Q65 is a very sensitive mode. Your 80 meter dipole at 50 ft should do it.

73

Ben W3ZUP

On 3/28/2021 7:11 PM, Bill Lederer wrote:
Team:
 
Ok, this is a littel weird.
 
Been trying q65 with a very modest 6 meter station and have a few QSOs from within the area.
 
I was working on something  else, and looked up and saw this on my screen:
 
210328_213230    50.275 Rx Q65 -12  0.1 1043 K9AN K1JT RR73                        q0
 
And earlier
 
210322_145130    50.275 Rx Q65 -17  0.1 1470 K0TPP K1JT FN20                       q0
 
and 
 
210313_185645    50.313 Rx FT8      6  0.1 1231 CQ K1JT FN20
 
Now i dearly hope that this is not EME, as I will be seriously freaked out. For one, the moon is below the horizon, and secondly, my antenna is an 80 meter dipole  up about 50 feet. 
 
(I didn't notice the other ones, only the first one today.)
 
What an awesome mode.
 
-- 
--w8lvn-- EN62cl





locked #q65 Mode q65 on 6 meters #Q65

Bill Lederer
 

Team:
 
Ok, this is a littel weird.
 
Been trying q65 with a very modest 6 meter station and have a few QSOs from within the area.
 
I was working on something  else, and looked up and saw this on my screen:
 
210328_213230    50.275 Rx Q65 -12  0.1 1043 K9AN K1JT RR73                        q0
 
And earlier
 
210322_145130    50.275 Rx Q65 -17  0.1 1470 K0TPP K1JT FN20                       q0
 
and 
 
210313_185645    50.313 Rx FT8      6  0.1 1231 CQ K1JT FN20
 
Now i dearly hope that this is not EME, as I will be seriously freaked out. For one, the moon is below the horizon, and secondly, my antenna is an 80 meter dipole  up about 50 feet. 
 
(I didn't notice the other ones, only the first one today.)
 
What an awesome mode.
 
-- 
--w8lvn-- EN62cl


locked rc-4 Q65 weirdness? #IssueReport

K0GU
 

I'll attach a screen shot below. K7MAC called me and decoded twice on the same sequence on the same frequency about 4 seconds apart (EME delay is not turned on). You can see in the TX window that apparently it restarted my xmit seq? Other stations also double decoded twice on the same frequency.

Note: These are all across mountain shots and Doppler is not unusual. I would not be surprised to see double decodes on WB7CJO's main frequency plus his Doppler frequency. But on some sequences he decodes twice on the same freq with different signal reports. So check the freqs carefully as Q65 will apparently separate signal that are very close together.


locked Re: Tried to upgrade WSJT-X to 2.4, now stuck trying to downgrade to previously working ver. 2.2.2 #AudioIssues #raspberryPi #txaudio

Bill Somerville
 

On 28/03/2021 20:50, marksheffield@... wrote:
tl;dr:  Can't get a transmit tone out any more

I've gotten my setup into a state that I can't get working. I'm running a R-pi to a TS-570D and using the rigctl daemon to key the rig (rigctld -m 2004 -r /dev/ttyUSB0 -s 57600 -P GPION -p 17 &).  I've had good success with wsjtx-2.2.2 with FT8 and have been trying to get rigctl commands to run reliably during wspr band hopping tuneup. I jumped to the recent release and had no better success with band hopping so have tried to drop back, but since then I haven't been able to get 2.2.2 to run.  Or 2.3.  Or 2.4 rc builds.
I've built 2.2.2 from sources, have done that before more than once, np.  Now when I'm running (any version),

(Problem 1 -->) I can't get a tone through the back accessory connector  (<-- Problem 1)

for some reason.  I know that the path is there because a few minutes ago I mistakenly sent youtube audio out through my radio speaker when I had youtube running in the background on my pi (I had plugged in my earphones) and then a few minutes later I had the rig connected again, fired up wsjtx and touched "TUNE" - no tone, but I heard the youtube audio out my radio speaker.  That was a little gaff, but it showed me that the audio path from my pi to the rig was all intact.
Another odd behavior that has appeared (on all versions) since the problems started a few days ago is that

(Problem 2 -->)  the waterfall freezes when I start and end a tune cycle (or try to transmit anything at all)  (<-- Problem 2)

.  this freeze is indicative of wsjtx receive not working at all and after this happens wsjtx doesn't exit cleanly either, it leaves something running in memory that I have to pkill. This is what that piece looks like:
 ps -al
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY   TIME CMD
4 S  1000   737   645  0  80   0 -  2123 poll_s tty1  00:00:00 bash
0 S  1000  1162  1141  0  80   0 -  5176 poll_s pts/0 00:00:00 rigctld
0 S  1000  1163  1141 51  80   0 - 228625 futex_ pts/0  00:01:12 wsjtx
0 R  1000  1188  1141  0  80   0 -  2414 -      pts/0 00:00:00 ps
I want to start from ground 0 with a clean install, I'd like to get rid of any wsjtx remnants and artifacts and reinstall.  I've used synaptic to remove wsjtx and associated files that have been installed, I've deleted most of the files in the /.local/share/WSJTX directory but when I reinstall wsjtx somehow the settings have remained - the settings page has not changed at all - I obviously haven't removed all the remnants.  I've done this many times without really cleaning it all out.
What should I do to really erase anything that defines the state of wsjtx so I can really do a "new" install?  The next step will be to rebuild the pi, but I have that so tuned up for running my radio that I really hate to do that.  Thanks for any thoughts - Mark/K4LFL
Mark,

the settings file location is documented in the WSJT-X User Guide:

https://physics.princeton.edu/pulsar/K1JT/wsjtx-doc/wsjtx-main-2.3.1.html#_file_locations

73
Bill
G4WJS.


locked Re: version 2.3.1 forces lsb mode #FT8

geoff wiggins
 

Hi Bill.

Sorry, slight error on my part, I should have said forces DIGL not LSB. DIGU is normal.

73 Geoff.

On 28/03/2021 19:04, Bill Somerville wrote:
Hi Amos,

which WSJT-X "Settings->Radio->Mode" button do you have checked?

73
Bill
G4WJS.

On 28/03/2021 18:59, Amos Sobel 4X4MF wrote:

I am using Flex 6600, TS-2000 and v2.3.1 an have no such problem. Always DIGU.

 

Amos 4X4MF

 

From: main@WSJTX.groups.io <main@WSJTX.groups.io> On Behalf Of Fletch
Sent: Sunday, March 28, 2021 7:18 PM
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] version 2.3.1 forces lsb mode #FT8

 

I had this same problem on the Flex 6300 using the TS-2000 control. I changed to Flex 6XXX and used 127.0.0.1:5002 and everything ended up working properly.  I did beat my head for about 6 hours trying everything else before cleaning out all installs and redoing everything. When it still didn't work, I tried the above. I suspect the control library is corrupted as this happened on 2.4.0 RC3 and 4 as well. The change fixed them all.

73 Fletch K3JYD

On 3/28/2021 10:22 AM, geoff wiggins via groups.io wrote:

I have just upgraded to v2.3.1 and found that wsjt forces the rig into lsb every time on every band. Using Flex 5000A. Reverted to 2.3.0 all normal.
Any ideas why?
73 Geoff. G4XMJ






locked Re: Q65 & LOTW #Q65

K0GU
 
Edited

He is my simple solution. A DATA QSO is a DATA QSO.and will match any other DATA mode QSO.


locked Re: Q65 & LOTW #Q65

Jim Brown
 

On 3/28/2021 1:21 PM, neil_zampella wrote:
LoTW will not accept the submode until its been approved.    They did the same with FT4 even though it was also a submode of MFSK.    TQSL will need to have a configuration update in order to upload the contact as Q65, you can add a 'conversion' so any contacts you have logged as Q65 will be uploaded as DATA. Otherwise they will be rejected with an error, as did those FT4 QSOs that were uploaded before the ADIF committee approved them and LoTW updated for the submode.
The obvious solution is to delay uploading your log with Q65 QSOs until that happens. The only downside is that ALL of your QSO partners will have to wait for that to happen. No biggie -- MANY hams only upload a few times a year.

73, Jim K9YC


locked Re: Tried to upgrade WSJT-X to 2.4, now stuck trying to downgrade to previously working ver. 2.2.2 #AudioIssues #raspberryPi #txaudio

Joel
 

Mark

Have you rescanned Hamlib to see if WSJTX installed a new version? At times the radio designation number is changed and your rig to daemon will need to be updated.

Joel

On Mar 28, 2021, at 4:10 PM, marksheffield@... wrote:


tl;dr: Can't get a transmit tone out any more

I've gotten my setup into a state that I can't get working. I'm running a R-pi to a TS-570D and using the rigctl daemon to key the rig (rigctld -m 2004 -r /dev/ttyUSB0 -s 57600 -P GPION -p 17 &). I've had good success with wsjtx-2.2.2 with FT8 and have been trying to get rigctl commands to run reliably during wspr band hopping tuneup. I jumped to the recent release and had no better success with band hopping so have tried to drop back, but since then I haven't been able to get 2.2.2 to run. Or 2.3. Or 2.4 rc builds.

I've built 2.2.2 from sources, have done that before more than once, np. Now when I'm running (any version),

(Problem 1 -->) I can't get a tone through the back accessory connector (<-- Problem 1)

for some reason. I know that the path is there because a few minutes ago I mistakenly sent youtube audio out through my radio speaker when I had youtube running in the background on my pi (I had plugged in my earphones) and then a few minutes later I had the rig connected again, fired up wsjtx and touched "TUNE" - no tone, but I heard the youtube audio out my radio speaker. That was a little gaff, but it showed me that the audio path from my pi to the rig was all intact.

Another odd behavior that has appeared (on all versions) since the problems started a few days ago is that

(Problem 2 -->) the waterfall freezes when I start and end a tune cycle (or try to transmit anything at all) (<-- Problem 2)

. this freeze is indicative of wsjtx receive not working at all and after this happens wsjtx doesn't exit cleanly either, it leaves something running in memory that I have to pkill. This is what that piece looks like:

ps -al
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
4 S 1000 737 645 0 80 0 - 2123 poll_s tty1 00:00:00 bash
0 S 1000 1162 1141 0 80 0 - 5176 poll_s pts/0 00:00:00 rigctld
0 S 1000 1163 1141 51 80 0 - 228625 futex_ pts/0 00:01:12 wsjtx
0 R 1000 1188 1141 0 80 0 - 2414 - pts/0 00:00:00 ps


I want to start from ground 0 with a clean install, I'd like to get rid of any wsjtx remnants and artifacts and reinstall. I've used synaptic to remove wsjtx and associated files that have been installed, I've deleted most of the files in the /.local/share/WSJTX directory but when I reinstall wsjtx somehow the settings have remained - the settings page has not changed at all - I obviously haven't removed all the remnants. I've done this many times without really cleaning it all out.
What should I do to really erase anything that defines the state of wsjtx so I can really do a "new" install? The next step will be to rebuild the pi, but I have that so tuned up for running my radio that I really hate to do that. Thanks for any thoughts - Mark/K4LFL


13181 - 13200 of 36836