Hi Bill, I had a similar problem, I did report the text below but received no reply but I think it is related.:- I found that in FST4W mode, if I select Tx Enable and Tx Next, although the PTT is

Hi Tony, The only problem with your theory is that it (wsjtx) calls on you respond & log as it starts sending out the RR73 (TX4) message. What you are suggesting can only be done manually, and this

Error Loading LoTW User Data Network Error - SSL/TLS support not installed, cannot fetch: ‘https://lotw.arrl.org/lotw-user-activity.csv’ Not an issue when loading 2.2.2. KC4AIF Cliff

I think Reino explanation is correct but not worded so that you understood? The program only sent CQ because you had logged the QSO and cleared the fields. If you had waited and not logged the QSO

Silicon Labs are working on their own drivers for Big Sur.

Ror NA, 160 just starts to open at 2200z. Could you please run later? I thank you in advance. Bruce, W8HW in Florida, USA On 11/20/2020 10:24 AM, Amos Sobel 4X4MF wrote:

Hi Folks! Join me in FST4 160m. This evening 19:00-22:00 UTC I will call CQ and listen: 1. Using WSJT-X v2.3.0 rc2 2. Mode=FST4 Single Decode 3. Frequency=1839.00 KHz 4. Tx=Rx=1500 Hz 5. F Tol=100

Mattia, This is a common error message about the ADIF log file. Locate the ADIF log file and do this, Find the first line where it says: WSJT-X ADIF Export<eh> change it to: WSJT-X ADIF

Right in the example below, he sent RRR and when I sent 73, the logging box popped up and I clicked ok and rearmed enable Tx. My point is that previously the program would resend 73 not CQ.

Hi Mattia, thanks for reporting the issue. It is a known issue with WSJT-X v2.2.2 which writes an invalid ADIF header when it first creates its own ADIF log file. You can fix the header by editing

oops : wsjtx-log.adi should have been wsjtx_log.adi Sam W2JDB

Hi, Check the WSJTX-Log.adi file. the first line should look like this : WSJT-X ADIF Export <eoh> There was a bug that left out the <eoh> in the first line. That should fix it. 73, Sam W2JDB

Sequencing errors are easily induced in v2.2.2 od9b96 as follows: While in a QSO with contact one, double-click in the left window on another contact then immediately double-click on the last received

I am looking for solution for this error. wsjt version x 2.2.2. windows 10 64 bit operating system. error while opening the program: (invalid ADIF header). when i open the program i get this error

Hi all, I'm having an issue with choppy audio on TX using WSJT-X 2.2.2 (build 0d9b96) on macOS Big Sur (11.0.1). The issue is intermittent and typically happens once every half hour or so. Sometimes,

FWIW, the FC-757 manual indicates receive-only tuning is an optional mode that can only be performed manually. https://www.manualslib.com/manual/1001225/Yaesu-Fc-757at.html?page=12#manual

I have seen this as well... Latest version, rc2. 73, and thanks, Dave (NK7Z) https://www.nk7z.net ARRL Volunteer Examiner ARRL Technical Specialist, RFI ARRL Asst. Director, NW Division, Technical

I C similar issues, most often noted....: When I send a RR73 the other station sends 73 as expected then instead of calling CQ I send a '73' .... /Dave K1BZ

Hi Greg, sorry for the delay on this,  it involved quite a lot of testing. Attached is an updated patch file that should allow your build on Debian 9 to complete. 73 Bill G4WJS.

Yes it did! All of my audio devices and drivers were gone except for my desktop speakers and they were disabled. Got all restored but now when there is a transition from receive to transmit or vice