Date   

locked #FT8 FT8 signal reports 2.4.0-rc4 #FT8

Chris Hannagan
 

I was operating 30 metres FT8 this morning and believe that a behavior has changed in sending the signal reports.
When a station didn't copy the TX2 sent report and responded again with TX1, each time you resent the callers signal report in previous releases, the report updated to the latest decoded report.
The report now appears to no longer update to the last decode and continues to send the original report.
I'm not sure if this is a problem but it is a behavior that seems to have changed.
Call 1st is enabled and I noticed this on several stations that were calling.
Chris zl7dx


locked Re: FT8 and 73: #FT8

Lawrence Godek
 

Agreed.  Same thoughts.

Larry W0OGH

On 4/1/2021 6:11 AM, Charlie Hoffman wrote:
I send  RR73.
When I receive a 73 then the QSO is complete.
If I don't receive a 73 then I consider the contact incomplete.
I don't log a QSO until I receive a 73 from the other station.
My log - my rules.

73, Charlie WD4CNO






locked Re: FT8 and 73: #FT8

Tom V. Segalstad
 

The following definition of a QSO is approved by the IARU (International Amateur Radio Union) Region 1, here extracted from the last version of The HF Managers’ Handbook:

 

2.1.1 QSO-DEFINITION

 

A definition for a valid QSO is:

A valid contact is one where both operators during the contact have

1. mutually identified each other

2. received a report, and

3. received a confirmation of the successful identification and the reception of the report.

It is emphasized that the responsibility always lies with the operator for the integrity of the contact.

 

A similar definition is in the IARU Region 1 VHF Managers’ Handbook Chapter 4.1.

 

There is no mention of «73» in this QSO definition – so 73 is just to be considered as «frosting on the cake» … or the QSO.

 

73 from Tom, LA4LN

 

 

Fra: Joe Subich, W4TV
Sendt: torsdag 1. april 2021 kl. 16.59
Til: main@WSJTX.groups.io
Emne: Re: [WSJTX] FT8 and 73: #FT8

 

On 2021-04-01 9:11 AM, Charlie Hoffman wrote:
 >
 > I don't log a QSO until I receive a 73 from the other station.
 > My log - my rules.

That's well and good until you are on the other side ...

Say you are working a rare DX (or rare state for WAS, etc.),
he sends you RR73 and someone else (who also needs him) calls
right on top of your 73.  Now, that rare station can't hear
your 73, does not log the QSO and goes right on working the
new caller.

*THE QSO IS COMPLETE WHEN BOTH STATIONS HAVE SENT "R"* -
either R-##, RRR, or RR73.  "R" acknowledges receipt of the
signal report ("+/-##" or "R+/-##) and exchange of signal
reports is what constitutes a "complete QSO" under *every*
definition of a QSO - not the exchange of reports *and*
acknowledgements.

73,

    ... Joe, W4TV


On 2021-04-01 9:11 AM, Charlie Hoffman wrote:
> I send  RR73.
> When I receive a 73 then the QSO is complete.
> If I don't receive a 73 then I consider the contact incomplete.
> I don't log a QSO until I receive a 73 from the other station.
> My log - my rules.
>
> 73, Charlie WD4CNO
>
>

 


--
Tom (LA4LN)


locked Re: #WSJTX_config - Unable to Decode WSPR Generated by SI5351 Project #WSJTX_config

@kc2svq
 

Hi Roy,

Thanks for responding.

Is this a suggestion in order to "clean up" and reduce the miscellaneious signals? Or some other reason?

Thx,
Jeff

On 4/1/21 12:02 PM, Roy VE7DH wrote:
Just because you can, build yourself a simple 20m low-pass filter for the SI output. You can find the required component values by looking at the assembly manual for the QRP-Labs low-pass filter kits.
You might find that decoding a sine wave is easier than decoding a square wave.
regards, Roy


locked Re: VS: [WSJTX] #WSJTX_config - Unable to Decode WSPR Generated by SI5351 Project #WSJTX_config

@kc2svq
 

HI Alan,

Thanks for responding.

I did some testing with an attenuator in line, but no luck yet. Have to do some more testing with it and some other's suggestions as well.

Thx,
Jeff

On 3/31/21 9:26 AM, Alan G4ZFQ wrote:
Jeff,
WSJT-X needs to decode WSPR at 1400-1600Hz not like your shot.
USB RX at dial 14.096
Also reduce the RX coupling gxrx looks like it is being overloaded and the signal shown is not on the correct frequency 14.096 +1400-1600Hz, around 14.09710
73 Alan G4ZFQ.


locked Split Operation with Rig Mode #IssueReport

Mark Friedman
 

It appears that Split Operation using Rig mode is not functioning correctly in both versions 2.3.1 and 2.4.0-rc4. Running Split | Rig with my Yaesu FT-817 when switching to transmit the FT-817 switches from VFOa to VFOb however the frequency in VFOb does not change from whatever was in it from the last "good" split operation. At the same time on the main WSJT-X window the split mode indicator is on and the frequency display changes on transmit to what you would expect it to be even though the VFOb frequency is something entirely different. Split Operation using Fake It mode functions as expected on these versions,

Reverting back to versions 2.3.0 and 2.4.0-rc3 Split Operation using Rig mode functions as expected. 

73,

Mark WB8BCU


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.
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.
After further investigation, it seems that certain NTP servers cause Apple's "timed" to get confused. However the Apple server time.apple.com works fine.

So if you see a time offset with macOS Big Sur, try this:

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. Close the System Preferences window

Within a few hours, your computer should snap back to the correct time.

Hopefully Apple will have this fixed soon, and we can go back to using any NTP server.

73,
Steve
W1SEG


locked Re: #WSJTX_config - Unable to Decode WSPR Generated by SI5351 Project #WSJTX_config

Roy VE7DH
 

Just because you can, build yourself a simple 20m low-pass filter for the SI output. You can find the required component values by looking at the assembly manual for the QRP-Labs low-pass filter kits.

You might find that decoding a sine wave is easier than decoding a square wave.

regards, Roy


locked Re: FT8 and 73: #FT8

Joe Subich, W4TV
 

On 2021-04-01 9:11 AM, Charlie Hoffman wrote:

I don't log a QSO until I receive a 73 from the other station.
My log - my rules.
That's well and good until you are on the other side ...

Say you are working a rare DX (or rare state for WAS, etc.),
he sends you RR73 and someone else (who also needs him) calls
right on top of your 73. Now, that rare station can't hear
your 73, does not log the QSO and goes right on working the
new caller.

*THE QSO IS COMPLETE WHEN BOTH STATIONS HAVE SENT "R"* -
either R-##, RRR, or RR73. "R" acknowledges receipt of the
signal report ("+/-##" or "R+/-##) and exchange of signal
reports is what constitutes a "complete QSO" under *every*
definition of a QSO - not the exchange of reports *and*
acknowledgements.

73,

... Joe, W4TV


On 2021-04-01 9:11 AM, Charlie Hoffman wrote:
I send  RR73.
When I receive a 73 then the QSO is complete.
If I don't receive a 73 then I consider the contact incomplete.
I don't log a QSO until I receive a 73 from the other station.
My log - my rules.
73, Charlie WD4CNO


locked Re: FT8 and 73: #FT8

Ed Muns, W0YK
 

If you don't receive '73' in response to your 'RR73' message, do you re-send 'RR73 '?  Or, do you just silently not log the QSO?

73,
Ed W0YK


-------- Original message --------
From: Charlie Hoffman <hoffmanc@...>
Date: 4/1/21 06:14 (GMT-08:00)
To: main@WSJTX.groups.io
Subject: Re: [WSJTX] FT8 and 73: #FT8

I send  RR73.
When I receive a 73 then the QSO is complete.
If I don't receive a 73 then I consider the contact incomplete.
I don't log a QSO until I receive a 73 from the other station.
My log - my rules.

73, Charlie WD4CNO



locked VS: [WSJTX] FT8 and 73: #FT8

Reino Talarmo
 

Just for curiosity. If you are the one to receive RR73 do you consider it as a 73?

 

73, Reino OH3mA

 

Lähettäjä: main@WSJTX.groups.io [mailto:main@WSJTX.groups.io] Puolesta Charlie Hoffman
Lähetetty: 01 April 2021 16:12
Vastaanottaja: main@WSJTX.groups.io
Aihe: Re: [WSJTX] FT8 and 73: #FT8

 

I send  RR73.
When I receive a 73 then the QSO is complete.
If I don't receive a 73 then I consider the contact incomplete.
I don't log a QSO until I receive a 73 from the other station.
My log - my rules.

73, Charlie WD4CNO


locked Now that was very odd #AudioIssues

Dave Harris
 

Try using manufacture’s drivers rather than MS provided generic drivers. My tech guy (#1 grandson, IT trained) says problems of this type are often due to MS making changes and breaking things that have worked in the past. I’ve had issues with non ham and ham SW when using MS provided drives. Changing to manufacture latest driver nearly always solves the problem. Hope this helps. 


locked Re: FT8 and 73: #FT8

Charlie Hoffman
 

I send  RR73.
When I receive a 73 then the QSO is complete.
If I don't receive a 73 then I consider the contact incomplete.
I don't log a QSO until I receive a 73 from the other station.
My log - my rules.

73, Charlie WD4CNO



locked Re: FT8 and 73: #FT8

Jon Ermels
 

?? I was taught as a Novice 33 years ago that Roger meant the report was received, 73 meant good wishes. RR73 means  the report was received and best wishes. Pretty simple to me. 

73 de NØIGU Jon


On Thursday, April 1, 2021, 12:31:38 AM CDT, Carl - WC4H via groups.io <wc4h.dx@...> wrote:


If you want to keep transmitting, you just click on enable as soon as it goes off.

The reasoning is as follows:
RRR implies 73 & RR73 explicitly says 73.
Once a 73 response is received to either RRR or RR73, it's a completed QSO.

That some people refuse to accept it as a complete QSO is true, but most do and most log the QSO when they get prompted to.

It's up to you what you log.  I go by the report received.  That is if I get a good signal report  I assume he/she is copying my final 73 so I log.  If I'm receiving a -20 I'll wait to log it.

73.
Carl - WC4H




locked #FST4W FST4W Beacon Source #FST4W

Andy Talbot
 

 A write up of my PIC + DDS  Beacon source for  FST4 / FST4W

Andy    G4JNT


locked Re: FT8 and 73: #FT8

Jim Brown
 

On 3/31/2021 9:55 PM, Carl - WC4H via groups.io wrote:
RRR implies 73 & RR73 explicitly says 73.
Once a 73 response is received to either RRR or RR73, it's a completed QSO.
It's even simpler than that. A QSO is complete if both stations copy R from the other. If the other station sends R-10 again, it means he didn't copy your RRR or RR73. If he calls CQ (or calls another station), it means he did. This corresponds directly to standard practice for DX and contesting for at least 30 years.

The "official" message protocols were developed decades ago for weak signal work on VHF/UHF. HF operation is different. :)

73, Jim K9YC


locked Re: Now that was very odd... #AudioIssues

Steve marsh (M0NMA)
 

I have experienced that too - everything was correct in the settings, but no audio in, and the waterfall had frozen, but the clock was still going. 


I think it may be linked with another problem I have where there is no modulation out from WSJT-X to the rig. Sometimes halting and restarting the TX fixes it, sometimes I need to restart the program. my suspicion is that Win 10 is messing up the audio ports as I once saw the audio out going to one of the other audio channels watching which was receiving audio in Sounds. This was despite all the audio settings being correct in wsjt-x settings and in the sounds properties for apps in win 10. 

--
Steve M0NMA


locked Re: FT8 and 73: #FT8

Carl - WC4H
 

If you want to keep transmitting, you just click on enable as soon as it goes off.

The reasoning is as follows:
RRR implies 73 & RR73 explicitly says 73.
Once a 73 response is received to either RRR or RR73, it's a completed QSO.

That some people refuse to accept it as a complete QSO is true, but most do and most log the QSO when they get prompted to.

It's up to you what you log.  I go by the report received.  That is if I get a good signal report  I assume he/she is copying my final 73 so I log.  If I'm receiving a -20 I'll wait to log it.

73.
Carl - WC4H


locked Re: FT8 and 73: #FT8

neil_zampella
 

Then send RR73 instead.

Neil, KN3ILZ

On 3/31/2021 8:59 PM, Jason B wrote:
Let me know if you get an answer, lol! I've noticed this on 2.3.1 . I think the jist of the thread I just read was that they consider the QSO over after the RRR and then the reply 73, so the courtesy reply of 73 back is redundant? I don't like that, I understand it's done in contesting alot, as in 73 de W5XXX, QRZ, but I prefer to respond to a 73 with a 73. Seems rude to do otherwise. IDK... 



locked Re: FT8 and 73: #FT8

Jason B
 

Let me know if you get an answer, lol! I've noticed this on 2.3.1 . I think the jist of the thread I just read was that they consider the QSO over after the RRR and then the reply 73, so the courtesy reply of 73 back is redundant? I don't like that, I understand it's done in contesting alot, as in 73 de W5XXX, QRZ, but I prefer to respond to a 73 with a 73. Seems rude to do otherwise. IDK... 

11661 - 11680 of 35397