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

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.

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

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.  

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

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

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

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

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.

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

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

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

Team:

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.

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.

Hi Bill.

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

73 Geoff.

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

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

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