When transmitting a FST4W message on f and a WSPR message also on f the decodes are consistently 2 Hz apart

I tried this with a Hermes Lite v2 + SparkSDR
Also with a RFZero with its own 2 sketches in beacon mode

I looked at the disciplined reference receivers like G3ZIL, G4ZFQ, OE9GHV and at my own local receivers (HL2 + SparkSDR and QDX + WSJTx)

Always FST4W is 2 Hz lower than the WSPR signal even though the same dial frequency is set at the transmitting system.

Has anybody seen that as well, do we have an explanation for this observation ? 
I expected both to be on exact the same frequency.

Erwin

Is this not simply the definitional change between WSPR and FST4W 'frequency' showing up?  I've lost track of when/where these apply but going forward I think the definition is the frequency of the lowest tone.  That was not originally the case for WSPR but I've lost track of when and if this definition has been applied v code versions.

It should be possible to manually observe the spectrum and see whether there is actually a 2 Hz shift present.

I did some tests in the last days with a RFzero directly linked to a Kiwisdr (with external Bodnar GPSDO) via coax. The RFzero and the Kiwsdr are in separate rooms. I can reduce the signal of the RFzero below the noise floor of the Kiwisdr. Latest WSPRdaemon 3.0.6 was used for decoding.
The RFzero was set to go from 0Hz to 14Hz in 1 Hz steps using FST4W-120. I did this with different SNR levels from -30dB up to +24dB. I could not identify an influence of the signal level on the spectral width or the reported frequency.

I can see a difference of -1.8 Hz with FST4W-120 compared to the frequency set in the Rfzero.
If I use WSPR, the difference is zero.

With
FST4W-300 the difference is -0.75 Hz
FST4W-900 the difference is -0.2 Hz
FST4W-1800 the difference is 0.0 Hz

This was done on 20m and 10m always with a spectral width of below 10mHz.

John

Hello John,

Thanks for that excellent work which appears to show that the RFZero is matching the frequency stability of a GPSDO QDX.  Did you modify the RFZ to increase its thermal stability?

Rob 

Hi Rob,

the RFzero is not modified, just some foam material on the crystal to prevent air flow. Even no housing.
The RFzero, Kiwisdr and Bodnar are all supplied from individual linear power supplies.
Spectral width when using the Bodnar is below 10 mHz.
With the internal clock of the Kiwisdr with or without GPS lock between 40 and 100 mHz.
(This is only valid for this specific Kiwisdr. Other may have different values.)

John

John that is very precise and confirms the 2 Hz (1.8 Hz now) that I found. How did you measure this with such accuracy ? Directly or statistically ?

Glenn's explanation might be a reason. But why is the encoder starting from the left side and the decoder looking at the middle of the signal ? And why do we see a difference for FST4W only even though the definition applies to both WSPR and FST4W ?

Yesterday afternoon I ran the same test again. Different Tx system : Yaesu FT817nd + WSJTx 2.6.1
The Yaesu needs to warm up a bit and I observed some frequency drift of about 2-3 Hz before it settled. Even in between the stability was good enough to get decodes of WSPR and FST4W at the usual locations like Gwyn's. Lowest spectral spread 5 mHz. In the graphs of Gwyn the spread even looks a tiny bit better than my foamed RFZero. The first set in the graph is from the RFZero, the other 2 groups to the right are from FT817

Surprise ? No frequency difference between WSPR and FST4W !

WSPR 10.140.121 FST4W 10.140.121
The spots can be seen from UTC 12:58 Local 13:58 and Power is given as 1 W. Switch from FST4W to WSPR at UTC 14:28-17:34 rest again FST4W. Older version of wsprdaemon before 3.0.6 report mode 2 also for FST4W.

Conclusion (new questions) : some encode-decode software pairs know about the 2 Hz design difference ?? Or : only WSJTx 2.6.1 compensates for this during the encoding ?? What about older versions of WSJTx ??

Better timescale

Erwin,

I use the wsprdaemon funtion wd-query. The frequency is shown in 0.1 Hz resolution.

John

Erwin

 I have a reply waiting to be approved on the wsjtx groups.io

My reply there was before I saw you asked below, "Conclusion (new questions) : some encode-decode software pairs know about the 2 Hz design difference ?? Or : only WSJTx 2.6.1 compensates for this during the encoding ?? What about older versions of WSJTx ??"

The answer is yes only some software pairs know the difference.

I use WSJT-X v2.5.4 with QDX here and there is no difference between WSPR and FST4W frequencies as reported. I cannot remember in which version of WSJT-X the change was made, and there is no note in the change log. But there was a change. Bo, OZ0RF pointed this out and included a quote from Joe Taylor, but I cannot find it.

So I suspect some developers have not made the change. For sure WSJT-X 2.5.4 onward show no difference.

regards

Gwyn G3ZIL

Hi Gwyn

You mean this?

https://sourceforge.net/p/wsjt/mailman/message/34135506/

Perhaps the FST-persons decided to deviate from the arguments for why the nominal WSPR is at tone 1,5 and not tone 0.

Bo
www.rudius.net/oz2m :: www.rfzero.net

You have a very good memory Bo, that message is from 2015, so since then all decoders/encoders should be in the know?

But also, this is way before FST4W got introduced. Do we know if all decoder/encoder developers still know about this ?

And if not, why would a "modern" (=after 2015 decoder) introduce a F difference that the "at the same time introduced" encoder would not ?

We need a matrix of decoders/encoders showing whether or not there is a difference between WSPR and FST4W.

We have various cases where we see FST4W reported 2 (1.8) Hz reported lower than WSPR.
A WSPR signal is 6 Hz wide.
A FST4W signal is 5.9 Hz occupied BW

If one of these is not following the same starting point for generation/decoding the difference should be 3 Hz, not 2 Hz. As the distance from the first tone to the midpoint of the signal is not 2 Hz.

Perhaps someone with good connections could get the WSJT-X developers to update the user guide with the key parameters for all the modes. Then it is "only" a matter of the rest afterwards.

At present everything seems a bit fluid.

Bo
www.rudius.net/oz2m :: www.rfzero.net