Drift


Vernon Matheson
 

Hi all,


Have been working on getting zero drift and frequency stability on one of my U3S units.


So far...


- Added a small heat sink on top of the 27 mhz xtal

- Packed the area around the xtal between the SI card and the bottom of the LPF board with cotton wool to keep the air currents on the 27mhz xtal. Unit is in QRP labs case as well.

- Set the park mode to 2 with a frequency of 150,000,000

- orientated the LPF board and TX schedule from highest to lowest frequency

- calibration set to 10 020

- added to the end of the frame a slow hell tx so to transmit and leave 30 seconds for calibration.

The results are that every band except 20 meters shows 0 drift.  It can run all night and it doesn't change.

Can anyone give some in-site on this..could there be something off with the LPF for 20M..

Thanks in advance..


Vernon - VE1VDM / VA1VM




2017-11-14 21:24   VA1VM   7.040168   -17   0   FN85ij   0.2   VE3LC   FN25   916   275 
 2017-11-14 21:24   VA1VM   7.040158   -21   0   FN85ij   0.2   K2DUV   FM17tq   1383   236 
 2017-11-14 21:24   VA1VM   7.040150   -16   0   FN85ij   0.2   KK1D   FN31   899   244 
 2017-11-14 21:24   VA1VM   7.040167   -19   0   FN85ij   0.2   N0UR   EN33   2358   275 
 2017-11-14 21:24   VA1VM   7.040150   -14   0   FN85ij   0.2   WA2ZKD   FN13ed   1167   263 
 2017-11-14 21:24   VA1VM   7.040162   -23   0   FN85ij   0.2   N4TVC   FM18is   1367   242 
 2017-11-14 21:24   VA1VM   7.040150   -20   0   FN85ij   0.2   K9AN   EN50wc   2102   263 
 2017-11-14 21:24   VA1VM   7.040151   -13   0   FN85ij   0.2   N2HQII   FN13rp   1067   264 
 2017-11-14 21:24   VA1VM   7.040155   -23   0   FN85ij   0.2   KB9AMG   EN52tx   2010   271 
 2017-11-14 21:24   VA1VM   7.040149   -14   0   FN85ij   0.2   WB3DZC   FM07ux   1490   242 
 2017-11-14 21:24   VA1VM   7.040140   -23   0   FN85ij   0.2   VE3GTC   FN25ig   937   273 
 2017-11-14 21:24   VA1VM   7.040138   -18   0   FN85ij   0.2   K3EA   FN20of   1098   243 
 2017-11-14 21:24   VA1VM   7.040150   -21   0   FN85ij   0.2   K2GQT   FN20wb   1064   240 
 2017-11-14 21:24   VA1VM   7.040151   -23   0   FN85ij   0.2   K2RWF   FN20   1100   244 
 2017-11-14 21:24   VA1VM   7.040162   -27   0   FN85ij   0.2   VE3GHM   FN25ig   937   273 
 2017-11-14 21:24   VA1VM   7.040150   -17   0   FN85ij   0.2   K8HSQ   EN90fu   1561   258 
 2017-11-14 21:24   VA1VM   7.040100   -4   0   FN85ij   0.2   N8VIM   FN42fq   724   248 
 2017-11-14 21:22   VA1VM   10.140151   -2   0   FN85ij   0.2   SWLNXZ   FN13co   1165   265 
 2017-11-14 21:22   VA1VM   10.140154   -25   0   FN85ij   0.2   VE3RPH   FN03hq   1287   267 
 2017-11-14 21:22   VA1VM   10.140148   -22   0   FN85ij   0.2   WQ5O   EN53uk   1989   273 
 2017-11-14 21:22   VA1VM   10.140150   -27   0   FN85ij   0.2   WE4X   EM65ut   2204   249 
 2017-11-14 21:22   VA1VM   10.140161   -28   0   FN85ij   0.2   WD8CIV   FN13if   1138   263 
 2017-11-14 21:22   VA1VM   10.140148   -10   0   FN85ij   0.2   K9AN   EN50wc   2102   263 
 2017-11-14 21:22   VA1VM   10.140155   -22   0   FN85ij   0.2   W3HH   EL89vb   2458   229 
 2017-11-14 21:22   VA1VM   10.140149   -14   0   FN85ij   0.2   W3CSW   FM19kd   1331   243 
 2017-11-14 21:22   VA1VM   10.140149   -23   0   FN85ij   0.2   W4ENN   EM64ru   2286   247 
 2017-11-14 21:20   VA1VM   14.097114   -29   -2   FN85ij   0.2   KD6RF   EM22   3071   253 
 2017-11-14 21:20   VA1VM   14.097148   -18   -2   FN85ij   0.2   KB8SPI   EN82hm   1634   266 
 2017-11-14 21:20   VA1VM   14.097149   -18   -2   FN85ij   0.2   K9AN   EN50wc   2102   263 
 2017-11-14 21:20   VA1VM   14.097154   -22   -2   FN85ij   0.2   KU4QI   EM87bx   1890   251 
 2017-11-14 21:20   VA1VM   14.097146   -16   -1   FN85ij   0.2   KB9AMG   EN52tx   2010   271 
 2017-11-14 21:20   VA1VM   14.097153   -25   -2   FN85ij   0.2   KA4PKB   EN41kf   2287   268 
 2017-11-14 21:14   VA1VM   7.040139   -12   0   FN85ij   0.2   K3EA   FN20of   1098   243 
 2017-11-14 21:14   VA1VM   7.040101   +2   0   FN85ij   0.2   N8VIM   FN42fq   724   248 
 2017-11-14 21:14   VA1VM   7.040150   -20   0   FN85ij   0.2   K8HSQ   EN90fu   1561   258 
 2017-11-14 21:14   VA1VM   7.040170   -26   0   FN85ij   0.2   F5OIH   JN06ci   4780   65 
 2017-11-14 21:14   VA1VM   7.040150   -15   0   FN85ij   0.2   WB3DZC   FM07ux   1490   242 
 2017-11-14 21:14   VA1VM   7.040159   -25   0   FN85ij   0.2   K2DUV   FM17tq   1383   236 
 2017-11-14 21:14   VA1VM   7.040168   -14   0   FN85ij   0.2   VE3LC   FN25   916   275 


Hans Summers
 

Hi Vernon

The LPF would not cause drift. Drift is related only to the 27MHz Si5351A reference oscillator. 20m is the first transmission after your calibration pause. Things I would try myself: 

1) Take a look at http://www.qrp-labs.com/synth/freqstab.html just to be sure you did everything it mentions there. I don't think you put a heatsink on the 27MHz crystal. That can be useful sometimes. An old nut glued on is good enough. Here, I find any suitable small piece of metal around the workbench and glue it on with epoxy. 

2) You mentioned that your frame contains only 30 seconds of non-transmit time. Of that, you have your calibration set to run for 10 seconds. Calibration is done at a much lower frequency, where the microcontroller is able to measure it. That means that the synth will only operate at the Park Mode 2 frequency of 150MHz for 20 seconds. Probably it is not enough to heat the Si5351A up enough. I suggest increasing your "Frame" parameter, add 2 minutes to it. Then The Si5351A will have 2 extra minutes at 150MHz "Park" to stabilise itself. 

3) Try Park at 150MHz, and try it at a much lower frequency e.g. try it at 14MHz (same as transmit frequency). What is the drift, in each case? If you find that drift is positive in one case, and negative in the other, then this means that in your particular situation, 150MHz is too high. It is OVER-compensating, heating up the Si5351A too much, so that when you come to the 20m transmission, it is cooling down and drifting. The solution is to try lower frequencies than 150MHz. 

I recommend trying these things one by one, not all at the same time. One by one means you will be able to find out which one (hopefully) reduces the 2Hz drift to 0Hz. 

73 Hans G0UPL

On Wed, Nov 15, 2017 at 12:36 AM, Vernon Matheson <vmath@...> wrote:

Hi all,


Have been working on getting zero drift and frequency stability on one of my U3S units.


So far...


- Added a small heat sink on top of the 27 mhz xtal

- Packed the area around the xtal between the SI card and the bottom of the LPF board with cotton wool to keep the air currents on the 27mhz xtal. Unit is in QRP labs case as well.

- Set the park mode to 2 with a frequency of 150,000,000

- orientated the LPF board and TX schedule from highest to lowest frequency

- calibration set to 10 020

- added to the end of the frame a slow hell tx so to transmit and leave 30 seconds for calibration.

The results are that every band except 20 meters shows 0 drift.  It can run all night and it doesn't change.

Can anyone give some in-site on this..could there be something off with the LPF for 20M..

Thanks in advance..


Vernon - VE1VDM / VA1VM




2017-11-14 21:24   VA1VM   7.040168   -17   0   FN85ij   0.2   VE3LC   FN25   916   275 
 2017-11-14 21:24   VA1VM   7.040158   -21   0   FN85ij   0.2   K2DUV   FM17tq   1383   236 
 2017-11-14 21:24   VA1VM   7.040150   -16   0   FN85ij   0.2   KK1D   FN31   899   244 
 2017-11-14 21:24   VA1VM   7.040167   -19   0   FN85ij   0.2   N0UR   EN33   2358   275 
 2017-11-14 21:24   VA1VM   7.040150   -14   0   FN85ij   0.2   WA2ZKD   FN13ed   1167   263 
 2017-11-14 21:24   VA1VM   7.040162   -23   0   FN85ij   0.2   N4TVC   FM18is   1367   242 
 2017-11-14 21:24   VA1VM   7.040150   -20   0   FN85ij   0.2   K9AN   EN50wc   2102   263 
 2017-11-14 21:24   VA1VM   7.040151   -13   0   FN85ij   0.2   N2HQII   FN13rp   1067   264 
 2017-11-14 21:24   VA1VM   7.040155   -23   0   FN85ij   0.2   KB9AMG   EN52tx   2010   271 
 2017-11-14 21:24   VA1VM   7.040149   -14   0   FN85ij   0.2   WB3DZC   FM07ux   1490   242 
 2017-11-14 21:24   VA1VM   7.040140   -23   0   FN85ij   0.2   VE3GTC   FN25ig   937   273 
 2017-11-14 21:24   VA1VM   7.040138   -18   0   FN85ij   0.2   K3EA   FN20of   1098   243 
 2017-11-14 21:24   VA1VM   7.040150   -21   0   FN85ij   0.2   K2GQT   FN20wb   1064   240 
 2017-11-14 21:24   VA1VM   7.040151   -23   0   FN85ij   0.2   K2RWF   FN20   1100   244 
 2017-11-14 21:24   VA1VM   7.040162   -27   0   FN85ij   0.2   VE3GHM   FN25ig   937   273 
 2017-11-14 21:24   VA1VM   7.040150   -17   0   FN85ij   0.2   K8HSQ   EN90fu   1561   258 
 2017-11-14 21:24   VA1VM   7.040100   -4   0   FN85ij   0.2   N8VIM   FN42fq   724   248 
 2017-11-14 21:22   VA1VM   10.140151   -2   0   FN85ij   0.2   SWLNXZ   FN13co   1165   265 
 2017-11-14 21:22   VA1VM   10.140154   -25   0   FN85ij   0.2   VE3RPH   FN03hq   1287   267 
 2017-11-14 21:22   VA1VM   10.140148   -22   0   FN85ij   0.2   WQ5O   EN53uk   1989   273 
 2017-11-14 21:22   VA1VM   10.140150   -27   0   FN85ij   0.2   WE4X   EM65ut   2204   249 
 2017-11-14 21:22   VA1VM   10.140161   -28   0   FN85ij   0.2   WD8CIV   FN13if   1138   263 
 2017-11-14 21:22   VA1VM   10.140148   -10   0   FN85ij   0.2   K9AN   EN50wc   2102   263 
 2017-11-14 21:22   VA1VM   10.140155   -22   0   FN85ij   0.2   W3HH   EL89vb   2458   229 
 2017-11-14 21:22   VA1VM   10.140149   -14   0   FN85ij   0.2   W3CSW   FM19kd   1331   243 
 2017-11-14 21:22   VA1VM   10.140149   -23   0   FN85ij   0.2   W4ENN   EM64ru   2286   247 
 2017-11-14 21:20   VA1VM   14.097114   -29   -2   FN85ij   0.2   KD6RF   EM22   3071   253 
 2017-11-14 21:20   VA1VM   14.097148   -18   -2   FN85ij   0.2   KB8SPI   EN82hm   1634   266 
 2017-11-14 21:20   VA1VM   14.097149   -18   -2   FN85ij   0.2   K9AN   EN50wc   2102   263 
 2017-11-14 21:20   VA1VM   14.097154   -22   -2   FN85ij   0.2   KU4QI   EM87bx   1890   251 
 2017-11-14 21:20   VA1VM   14.097146   -16   -1   FN85ij   0.2   KB9AMG   EN52tx   2010   271 
 2017-11-14 21:20   VA1VM   14.097153   -25   -2   FN85ij   0.2   KA4PKB   EN41kf   2287   268 
 2017-11-14 21:14   VA1VM   7.040139   -12   0   FN85ij   0.2   K3EA   FN20of   1098   243 
 2017-11-14 21:14   VA1VM   7.040101   +2   0   FN85ij   0.2   N8VIM   FN42fq   724   248 
 2017-11-14 21:14   VA1VM   7.040150   -20   0   FN85ij   0.2   K8HSQ   EN90fu   1561   258 
 2017-11-14 21:14   VA1VM   7.040170   -26   0   FN85ij   0.2   F5OIH   JN06ci   4780   65 
 2017-11-14 21:14   VA1VM   7.040150   -15   0   FN85ij   0.2   WB3DZC   FM07ux   1490   242 
 2017-11-14 21:14   VA1VM   7.040159   -25   0   FN85ij   0.2   K2DUV   FM17tq   1383   236 
 2017-11-14 21:14   VA1VM   7.040168   -14   0   FN85ij   0.2   VE3LC   FN25   916   275 



Vernon Matheson
 

Hi Hans,


Left a blank frame at the end of 5 bands with Park Mode set at #2 and frequency at 150.000.000 and so far all zeros on all bands.

Will see how it plays out overnight and tomorrow.

Many thanks for advice.


Vernon


Hans Summers
 

Hi Vernon

I think that's it then. The 30 seconds you left just wasn't long enough - 10 seconds calibration, 20 seconds 150MHz Park 2; the 20 seconds isn't enough to "warm up" the Si5351A chip. When you left the extra frame, there was enough time! 

73 Hans G0UPL
http://qrp-labs.com

On Thu, Nov 16, 2017 at 1:50 AM, Vernon Matheson <vmath@...> wrote:
Hi Hans,


Left a blank frame at the end of 5 bands with Park Mode set at #2 and frequency at 150.000.000 and so far all zeros on all bands.

Will see how it plays out overnight and tomorrow.

Many thanks for advice.


Vernon








Vernon Matheson
 

Hi Hans and all,
 
Well after I sent off the note I put the 28mhz band on line along with all the others...so I had 28mhz first and then the rest in order to the lowest band...6 wspr tx on a 14 minute frame.
 
I didn't change any settings, just added 28 MHz to the TX menu.
 
Once I started looking at the results on wspr net the 18 MHz showed up to -4 drift and the 14 MHz showed -2 drift. The remaining bands showed Zero drift. 
 
I took the 28mhz out of the TX string and everything went back to normal and ran perfectly all night.
 
So do I start to reduce the park mode frequency?
 
Vernon
 


Hans Summers
 

Hi Vernon

If it shows - drift with 150MHz, try reducing Park Freq to 30MHz (say), and measure again. Now if you see + drift... then you'll know that 150MHz is too high for your configuration, and 30MHz is too low. So then you can experiment with frequencies in between until you find the sweet spot. 

73 Hans G0UPL

On Thu, Nov 16, 2017 at 3:40 PM, Vernon Matheson <vmath@...> wrote:
Hi Hans and all,
 
Well after I sent off the note I put the 28mhz band on line along with all the others...so I had 28mhz first and then the rest in order to the lowest band...6 wspr tx on a 14 minute frame.
 
I didn't change any settings, just added 28 MHz to the TX menu.
 
Once I started looking at the results on wspr net the 18 MHz showed up to -4 drift and the 14 MHz showed -2 drift. The remaining bands showed Zero drift. 
 
I took the 28mhz out of the TX string and everything went back to normal and ran perfectly all night.
 
So do I start to reduce the park mode frequency?
 
Vernon
 



M. de Jong
 

I’ve been noticing the drift on my U3S during WSPRing, usually about 0 to -1 on 40m and 0 to -2 on 20m. I know the things that can be done to reduce the drift, but I never really minded the slight drift. But now I wonder, will 0 drift make it easier for the decoding software to decode a very weak WSPR signal, as opposed to a signal with -1 or -2 drift?

 

73,

 

Michael PA7MDJ

 

Van: QRPLabs@groups.io [mailto:QRPLabs@groups.io] Namens Hans Summers
Verzonden: woensdag 15 november 2017 10:10
Aan: QRPLabs@groups.io
Onderwerp: Re: [QRPLabs] Drift

 

Hi Vernon

 

The LPF would not cause drift. Drift is related only to the 27MHz Si5351A reference oscillator. 20m is the first transmission after your calibration pause. Things I would try myself: 

 

1) Take a look at http://www.qrp-labs.com/synth/freqstab.html just to be sure you did everything it mentions there. I don't think you put a heatsink on the 27MHz crystal. That can be useful sometimes. An old nut glued on is good enough. Here, I find any suitable small piece of metal around the workbench and glue it on with epoxy. 

 

2) You mentioned that your frame contains only 30 seconds of non-transmit time. Of that, you have your calibration set to run for 10 seconds. Calibration is done at a much lower frequency, where the microcontroller is able to measure it. That means that the synth will only operate at the Park Mode 2 frequency of 150MHz for 20 seconds. Probably it is not enough to heat the Si5351A up enough. I suggest increasing your "Frame" parameter, add 2 minutes to it. Then The Si5351A will have 2 extra minutes at 150MHz "Park" to stabilise itself. 

 

3) Try Park at 150MHz, and try it at a much lower frequency e.g. try it at 14MHz (same as transmit frequency). What is the drift, in each case? If you find that drift is positive in one case, and negative in the other, then this means that in your particular situation, 150MHz is too high. It is OVER-compensating, heating up the Si5351A too much, so that when you come to the 20m transmission, it is cooling down and drifting. The solution is to try lower frequencies than 150MHz. 

 

I recommend trying these things one by one, not all at the same time. One by one means you will be able to find out which one (hopefully) reduces the 2Hz drift to 0Hz. 

 

73 Hans G0UPL

 

On Wed, Nov 15, 2017 at 12:36 AM, Vernon Matheson <vmath@...> wrote:

Hi all,

 

Have been working on getting zero drift and frequency stability on one of my U3S units.

 

So far...

 

- Added a small heat sink on top of the 27 mhz xtal

- Packed the area around the xtal between the SI card and the bottom of the LPF board with cotton wool to keep the air currents on the 27mhz xtal. Unit is in QRP labs case as well.

- Set the park mode to 2 with a frequency of 150,000,000

- orientated the LPF board and TX schedule from highest to lowest frequency

- calibration set to 10 020

- added to the end of the frame a slow hell tx so to transmit and leave 30 seconds for calibration.

The results are that every band except 20 meters shows 0 drift.  It can run all night and it doesn't change.

Can anyone give some in-site on this..could there be something off with the LPF for 20M..

Thanks in advance..

 

Vernon - VE1VDM / VA1VM

 

 

 

2017-11-14 21:24 

 VA1VM 

 7.040168 

 -17 

 0 

 FN85ij 

 0.2 

 VE3LC 

 FN25 

 916 

 275 

 2017-11-14 21:24 

 VA1VM 

 7.040158 

 -21 

 0 

 FN85ij 

 0.2 

 K2DUV 

 FM17tq 

 1383 

 236 

 2017-11-14 21:24 

 VA1VM 

 7.040150 

 -16 

 0 

 FN85ij 

 0.2 

 KK1D 

 FN31 

 899 

 244 

 2017-11-14 21:24 

 VA1VM 

 7.040167 

 -19 

 0 

 FN85ij 

 0.2 

 N0UR 

 EN33 

 2358 

 275 

 2017-11-14 21:24 

 VA1VM 

 7.040150 

 -14 

 0 

 FN85ij 

 0.2 

 WA2ZKD 

 FN13ed 

 1167 

 263 

 2017-11-14 21:24 

 VA1VM 

 7.040162 

 -23 

 0 

 FN85ij 

 0.2 

 N4TVC 

 FM18is 

 1367 

 242 

 2017-11-14 21:24 

 VA1VM 

 7.040150 

 -20 

 0 

 FN85ij 

 0.2 

 K9AN 

 EN50wc 

 2102 

 263 

 2017-11-14 21:24 

 VA1VM 

 7.040151 

 -13 

 0 

 FN85ij 

 0.2 

 N2HQII 

 FN13rp 

 1067 

 264 

 2017-11-14 21:24 

 VA1VM 

 7.040155 

 -23 

 0 

 FN85ij 

 0.2 

 KB9AMG 

 EN52tx 

 2010 

 271 

 2017-11-14 21:24 

 VA1VM 

 7.040149 

 -14 

 0 

 FN85ij 

 0.2 

 WB3DZC 

 FM07ux 

 1490 

 242 

 2017-11-14 21:24 

 VA1VM 

 7.040140 

 -23 

 0 

 FN85ij 

 0.2 

 VE3GTC 

 FN25ig 

 937 

 273 

 2017-11-14 21:24 

 VA1VM 

 7.040138 

 -18 

 0 

 FN85ij 

 0.2 

 K3EA 

 FN20of 

 1098 

 243 

 2017-11-14 21:24 

 VA1VM 

 7.040150 

 -21 

 0 

 FN85ij 

 0.2 

 K2GQT 

 FN20wb 

 1064 

 240 

 2017-11-14 21:24 

 VA1VM 

 7.040151 

 -23 

 0 

 FN85ij 

 0.2 

 K2RWF 

 FN20 

 1100 

 244 

 2017-11-14 21:24 

 VA1VM 

 7.040162 

 -27 

 0 

 FN85ij 

 0.2 

 VE3GHM 

 FN25ig 

 937 

 273 

 2017-11-14 21:24 

 VA1VM 

 7.040150 

 -17 

 0 

 FN85ij 

 0.2 

 K8HSQ 

 EN90fu 

 1561 

 258 

 2017-11-14 21:24 

 VA1VM 

 7.040100 

 -4 

 0 

 FN85ij 

 0.2 

 N8VIM 

 FN42fq 

 724 

 248 

 2017-11-14 21:22 

 VA1VM 

 10.140151 

 -2 

 0 

 FN85ij 

 0.2 

 SWLNXZ 

 FN13co 

 1165 

 265 

 2017-11-14 21:22 

 VA1VM 

 10.140154 

 -25 

 0 

 FN85ij 

 0.2 

 VE3RPH 

 FN03hq 

 1287 

 267 

 2017-11-14 21:22 

 VA1VM 

 10.140148 

 -22 

 0 

 FN85ij 

 0.2 

 WQ5O 

 EN53uk 

 1989 

 273 

 2017-11-14 21:22 

 VA1VM 

 10.140150 

 -27 

 0 

 FN85ij 

 0.2 

 WE4X 

 EM65ut 

 2204 

 249 

 2017-11-14 21:22 

 VA1VM 

 10.140161 

 -28 

 0 

 FN85ij 

 0.2 

 WD8CIV 

 FN13if 

 1138 

 263 

 2017-11-14 21:22 

 VA1VM 

 10.140148 

 -10 

 0 

 FN85ij 

 0.2 

 K9AN 

 EN50wc 

 2102 

 263 

 2017-11-14 21:22 

 VA1VM 

 10.140155 

 -22 

 0 

 FN85ij 

 0.2 

 W3HH 

 EL89vb 

 2458 

 229 

 2017-11-14 21:22 

 VA1VM 

 10.140149 

 -14 

 0 

 FN85ij 

 0.2 

 W3CSW 

 FM19kd 

 1331 

 243 

 2017-11-14 21:22 

 VA1VM 

 10.140149 

 -23 

 0 

 FN85ij 

 0.2 

 W4ENN 

 EM64ru 

 2286 

 247 

 2017-11-14 21:20 

 VA1VM 

 14.097114 

 -29 

 -2 

 FN85ij 

 0.2 

 KD6RF 

 EM22 

 3071 

 253 

 2017-11-14 21:20 

 VA1VM 

 14.097148 

 -18 

 -2 

 FN85ij 

 0.2 

 KB8SPI 

 EN82hm 

 1634 

 266 

 2017-11-14 21:20 

 VA1VM 

 14.097149 

 -18 

 -2 

 FN85ij 

 0.2 

 K9AN 

 EN50wc 

 2102 

 263 

 2017-11-14 21:20 

 VA1VM 

 14.097154 

 -22 

 -2 

 FN85ij 

 0.2 

 KU4QI 

 EM87bx 

 1890 

 251 

 2017-11-14 21:20 

 VA1VM 

 14.097146 

 -16 

 -1 

 FN85ij 

 0.2 

 KB9AMG 

 EN52tx 

 2010 

 271 

 2017-11-14 21:20 

 VA1VM 

 14.097153 

 -25 

 -2 

 FN85ij 

 0.2 

 KA4PKB 

 EN41kf 

 2287 

 268 

 2017-11-14 21:14 

 VA1VM 

 7.040139 

 -12 

 0 

 FN85ij 

 0.2 

 K3EA 

 FN20of 

 1098 

 243 

 2017-11-14 21:14 

 VA1VM 

 7.040101 

 +2 

 0 

 FN85ij 

 0.2 

 N8VIM 

 FN42fq 

 724 

 248 

 2017-11-14 21:14 

 VA1VM 

 7.040150 

 -20 

 0 

 FN85ij 

 0.2 

 K8HSQ 

 EN90fu 

 1561 

 258 

 2017-11-14 21:14 

 VA1VM 

 7.040170 

 -26 

 0 

 FN85ij 

 0.2 

 F5OIH 

 JN06ci 

 4780 

 65 

 2017-11-14 21:14 

 VA1VM 

 7.040150 

 -15 

 0 

 FN85ij 

 0.2 

 WB3DZC 

 FM07ux 

 1490 

 242 

 2017-11-14 21:14 

 VA1VM 

 7.040159 

 -25 

 0 

 FN85ij 

 0.2 

 K2DUV 

 FM17tq 

 1383 

 236 

 2017-11-14 21:14 

 VA1VM 

 7.040168 

 -14 

 0 

 FN85ij 

 0.2 

 VE3LC 

 FN25 

 916 

 275 

 


Virusvrij. www.avast.com


Hans Summers
 

Hi Michael
 

I’ve been noticing the drift on my U3S during WSPRing, usually about 0 to -1 on 40m and 0 to -2 on 20m. I know the things that can be done to reduce the drift, but I never really minded the slight drift. But now I wonder, will 0 drift make it easier for the decoding software to decode a very weak WSPR signal, as opposed to a signal with -1 or -2 drift?


The WSPR decoder has some algorithms for compensating for drift in the range -4 to +4Hz during the course of the transmission. The compensation assumes a straight-line drift. The reported number is the average drift in 2 minutes. It doesn't give you information about the shape of the drift. If the drift is a straight line then I think the WSPR decoder won't be impacted by the drift - it should be just as easy to decode as a straight-line signal. This is from my limited study of the WSPR decoder but I am by no means an expert on how it works. If the signal is very weak then I expect the decoder would not so easily be able to measure the amount of drift, which may make it harder to compensate for. 

Additionally, there are other forms of drift other than the transmitter. Specifically, the receiving stations drift, and any drift from ionospheric changes (e.g. Doppler shift when the height of the reflecting layer changes). The WSPR decoder is presented with the summation of these drifts. So potentially if your transmitter has drift then if the other drifts (receiving station, ionosphere) are added on, it could take the total beyond the 4Hz that the WSPR decoder can manage. 

Overall, my guess is that drift does have some impact on the ability of the decoding software to decode very weak WSPR signals, but I guess if the drift is small (1 or 2Hz) then the impact is rather minimal. To avoid taking any chances I think it would be best to try to implement the simple measures to reduce drift, if possible! See http://qrp-labs.com/synth/freqstab.html

73 Hans G0UPL


Vernon Matheson
 

Michael just to add to what Hans said.
 
With hints from Hans I have been spending a lot of time trying to produce all ZEROS for drift on my transmissions. It is a futile task.
 
For example I can look at my 40m tx's on the WSPRNET data base and can see a stretch where I have all zeros except from one or two of the same  receiving stations, can see stretches where I get a lot of -1 from many stations but then returns to all zeros.
 
I really think that no matter what you do there are too many beyond your control things that can cause +/- drift reports.
 
The one thing though that really helped me for my U3S QRSS and FSKCW and WSPR transmissions is the advice Hans gave me on the use of the park mode.
 
When I look at my stacked signal at say the W4HBK grabber it is a nice straight line across the stacked image grab...big improvement as before it would wander up and down a few Hz.
 
As Hans suggested I would try setting park mode to 2 and the park mode frequency to 150,000,000 and have an extra 2 minutes at the end of your TX frame. So if you are transmitting on 4 bands your frame setting would be 10 minutes with perhaps your calibration at 20 seconds or something like that.
 
Give it a try and see what happens.
 
Vernon
 
On 11/23/17 02:44 AM, "Hans Summers" <hans.summers@...> wrote:

Hi Michael
 

I’ve been noticing the drift on my U3S during WSPRing, usually about 0 to -1 on 40m and 0 to -2 on 20m. I know the things that can be done to reduce the drift, but I never really minded the slight drift. But now I wonder, will 0 drift make it easier for the decoding software to decode a very weak WSPR signal, as opposed to a signal with -1 or -2 drift?


The WSPR decoder has some algorithms for compensating for drift in the range -4 to +4Hz during the course of the transmission. The compensation assumes a straight-line drift. The reported number is the average drift in 2 minutes. It doesn't give you information about the shape of the drift. If the drift is a straight line then I think the WSPR decoder won't be impacted by the drift - it should be just as easy to decode as a straight-line signal. This is from my limited study of the WSPR decoder but I am by no means an expert on how it works. If the signal is very weak then I expect the decoder would not so easily be able to measure the amount of drift, which may make it harder to compensate for. 

Additionally, there are other forms of drift other than the transmitter. Specifically, the receiving stations drift, and any drift from ionospheric changes (e.g. Doppler shift when the height of the reflecting layer changes). The WSPR decoder is presented with the summation of these drifts. So potentially if your transmitter has drift then if the other drifts (receiving station, ionosphere) are added on, it could take the total beyond the 4Hz that the WSPR decoder can manage. 

Overall, my guess is that drift does have some impact on the ability of the decoding software to decode very weak WSPR signals, but I guess if the drift is small (1 or 2Hz) then the impact is rather minimal. To avoid taking any chances I think it would be best to try to implement the simple measures to reduce drift, if possible! See http://qrp-labs.com/synth/freqstab.html

73 Hans G0UPL
 


Hans Summers
 

You can never get all zeroes, 100% of the time. There are too many other factors involved, including the ionosphere and the receiving station's drift in some cases. In practice if you get 0's and 1's... and if there are more 0's in there than 1's... then that's about as good as it gets, or needs to get!

73 Hans G0UPL

On Thu, Nov 23, 2017 at 3:14 PM, Vernon Matheson <vmath@...> wrote:
Michael just to add to what Hans said.
 
With hints from Hans I have been spending a lot of time trying to produce all ZEROS for drift on my transmissions. It is a futile task.
 
For example I can look at my 40m tx's on the WSPRNET data base and can see a stretch where I have all zeros except from one or two of the same  receiving stations, can see stretches where I get a lot of -1 from many stations but then returns to all zeros.
 
I really think that no matter what you do there are too many beyond your control things that can cause +/- drift reports.
 
The one thing though that really helped me for my U3S QRSS and FSKCW and WSPR transmissions is the advice Hans gave me on the use of the park mode.
 
When I look at my stacked signal at say the W4HBK grabber it is a nice straight line across the stacked image grab...big improvement as before it would wander up and down a few Hz.
 
As Hans suggested I would try setting park mode to 2 and the park mode frequency to 150,000,000 and have an extra 2 minutes at the end of your TX frame. So if you are transmitting on 4 bands your frame setting would be 10 minutes with perhaps your calibration at 20 seconds or something like that.
 
Give it a try and see what happens.
 
Vernon
 
On 11/23/17 02:44 AM, "Hans Summers" <hans.summers@...> wrote:
Hi Michael
 

I’ve been noticing the drift on my U3S during WSPRing, usually about 0 to -1 on 40m and 0 to -2 on 20m. I know the things that can be done to reduce the drift, but I never really minded the slight drift. But now I wonder, will 0 drift make it easier for the decoding software to decode a very weak WSPR signal, as opposed to a signal with -1 or -2 drift?


The WSPR decoder has some algorithms for compensating for drift in the range -4 to +4Hz during the course of the transmission. The compensation assumes a straight-line drift. The reported number is the average drift in 2 minutes. It doesn't give you information about the shape of the drift. If the drift is a straight line then I think the WSPR decoder won't be impacted by the drift - it should be just as easy to decode as a straight-line signal. This is from my limited study of the WSPR decoder but I am by no means an expert on how it works. If the signal is very weak then I expect the decoder would not so easily be able to measure the amount of drift, which may make it harder to compensate for. 

Additionally, there are other forms of drift other than the transmitter. Specifically, the receiving stations drift, and any drift from ionospheric changes (e.g. Doppler shift when the height of the reflecting layer changes). The WSPR decoder is presented with the summation of these drifts. So potentially if your transmitter has drift then if the other drifts (receiving station, ionosphere) are added on, it could take the total beyond the 4Hz that the WSPR decoder can manage. 

Overall, my guess is that drift does have some impact on the ability of the decoding software to decode very weak WSPR signals, but I guess if the drift is small (1 or 2Hz) then the impact is rather minimal. To avoid taking any chances I think it would be best to try to implement the simple measures to reduce drift, if possible! See http://qrp-labs.com/synth/freqstab.html

73 Hans G0UPL
 



Graham, VE3GTC
 

Something else to consider in all off this is the role in which the
analog to digital conversion (i.e. your computers sound card) plays.

Consider for example that your sound card may be sampling at 24 ksps
(kilo samples per second). Windows messes around with and re-samples to
the 11025k which the WSPR or WSJT-X program uses. Linux no doubt will
have similar behaviour.

Plus the vast majority of users never calibrate their sound card / ADC
interface in any way.

The end result being that around the fringes of these sorts of
measurements like SNR and DRIFT there MAY be some measurement artefact
being seen from time to time rather than a true delta.

Gwyn G3ZIL and Nigel G4HZX have put together some observations with
respect to WSPR SNR observations that is most interesting. Gwyn posted
on wsprnet.org a brief introduction on the subject:

http://wsprnet.org/drupal/node/7416

Some food for thought.

cheers, Graham ve3gtc

On 11/23/2017, "Hans Summers" <hans.summers@...> wrote:

You can never get all zeroes, 100% of the time. There are too many other
factors involved, including the ionosphere and the receiving station's
drift in some cases. In practice if you get 0's and 1's... and if there are
more 0's in there than 1's... then that's about as good as it gets, or
needs to get!

73 Hans G0UPL
http://qrp-labs.com

On Thu, Nov 23, 2017 at 3:14 PM, Vernon Matheson <vmath@...> wrote:

Michael just to add to what Hans said.

With hints from Hans I have been spending a lot of time trying to produce
all ZEROS for drift on my transmissions. It is a futile task.

For example I can look at my 40m tx's on the WSPRNET data base and can
see a stretch where I have all zeros except from one or two of the same
receiving stations, can see stretches where I get a lot of -1 from many
stations but then returns to all zeros.

I really think that no matter what you do there are too many beyond your
control things that can cause +/- drift reports.

The one thing though that really helped me for my U3S QRSS and FSKCW and
WSPR transmissions is the advice Hans gave me on the use of the park mode.

When I look at my stacked signal at say the W4HBK grabber it is a nice
straight line across the stacked image grab...big improvement as before it
would wander up and down a few Hz.

As Hans suggested I would try setting park mode to 2 and the park mode
frequency to 150,000,000 and have an extra 2 minutes at the end of your TX
frame. So if you are transmitting on 4 bands your frame setting would be 10
minutes with perhaps your calibration at 20 seconds or something like that.

Give it a try and see what happens.

Vernon

On 11/23/17 02:44 AM, *"Hans Summers" *<hans.summers@...> wrote:

Hi Michael


I’ve been noticing the drift on my U3S during WSPRing, usually about 0 to
-1 on 40m and 0 to -2 on 20m. I know the things that can be done to reduce
the drift, but I never really minded the slight drift. But now I wonder,
will 0 drift make it easier for the decoding software to decode a very weak
WSPR signal, as opposed to a signal with -1 or -2 drift?
The WSPR decoder has some algorithms for compensating for drift in the
range -4 to +4Hz during the course of the transmission. The compensation
assumes a straight-line drift. The reported number is the average drift in
2 minutes. It doesn't give you information about the shape of the drift. If
the drift is a straight line then I think the WSPR decoder won't be
impacted by the drift - it should be just as easy to decode as a
straight-line signal. This is from my limited study of the WSPR decoder but
I am by no means an expert on how it works. If the signal is very weak then
I expect the decoder would not so easily be able to measure the amount of
drift, which may make it harder to compensate for.

Additionally, there are other forms of drift other than the transmitter.
Specifically, the receiving stations drift, and any drift from ionospheric
changes (e.g. Doppler shift when the height of the reflecting layer
changes). The WSPR decoder is presented with the summation of these drifts.
So potentially if your transmitter has drift then if the other drifts
(receiving station, ionosphere) are added on, it could take the total
beyond the 4Hz that the WSPR decoder can manage.

Overall, my guess is that drift does have some impact on the ability of
the decoding software to decode very weak WSPR signals, but I guess if the
drift is small (1 or 2Hz) then the impact is rather minimal. To avoid
taking any chances I think it would be best to try to implement the simple
measures to reduce drift, if possible! See http://qrp-labs.com/synth/
freqstab.html

73 Hans G0UPL
http://qrp-labs.com





Alan G4ZFQ
 

http://wsprnet.org/drupal/node/7416
Some food for thought.
Graham,

I read that some time ago and marvelled at yet another seemingly pointless analysis of WSPR spots. But then, I do not understand what was being analysed.
Seems to me that on the limits all sorts of things can affect SNR results and they should simply be avoided.
But then I've always wished that signal AND noise figures could be provided for users that want to analyse results and really know what they mean.

Windows messes around with and re-samples to the 11025k which the
WSPR or WSJT-X program uses.

Sample rate? My Delta 44 are locked on 48ksps when used by WSPR, they do have the 11025 setting but it is not selected. If I run SpecLab at 8000ksps then that's what the control panel shows. Where do you get the 11025?
Any sample rate deviations could be averaged by the many passes WSPR makes over a weak signal. But that's me guessing again.

the vast majority of users never calibrate their sound card / ADC
interface in any way.

How do you do that? Very few programs give that option. The only way I know is when using VAC, then differences between soundcard sampling and the actual computing rate can be compensated. I do not know how to do that properly other than by trial and error...

73 Alan G4ZFQ


Graham, VE3GTC
 

Good afternoon Alan,

Thank you challenging some of my comments.

As to my comment regarding 11025 sampling frequency, I checked the WSPR
and WSJT-X documents and found 48,000 mentioned as the sampling rate. I
am sure somewhere at sometime I read something about 11025 being the
sampling rate, perhaps a much earlier version or perhaps I have confused
this with something else.

Not every (in particular older PC's) sound cards will sample at 48,000
so the program must be able to use those as well. However, times change
and perhaps I am just too biased in my notion.

Bottom line is that audio sampling in Windows is a complex thing. Windows
does have it's own "native" rates (i.e. 11025 and 44,100 among
others) and there is some re-sampling going on. I don't fully
understand the ins and outs but am aware it is something to be aware of.
Resampling is not lossless.

There has been much written on using PC sound cards for other than
playing music and various ways to calibrate said sound cards. A quick
search will turn up many. Here a few to get started:

https://www.jeffreykopcak.com/2015/10/19/nbemsfldigi-sound-card-calibration/

If you have ever used FLDIGI to decode WEFAX images you will be aware of
the image slanting one way or the other til you have it calibrated.

http://www.g4jnt.com/RX_Soundcard_cal_v1.pdf

www.wb1gof.org/files/FrequencyCalibration.pptx

http://www.qsl.net/hiarc/Presentations/Frequency_Measurement_with_uHz_accuracy_Rev-C.pdf

http://ve2azx.net/technical/FMT/SpecLabInfo.pdf


That is all find and dandy if there was a way in WSPR or WSJT-X to
correct the sample rate to match the sound card but there isn't any
that I can find. There is a way to correct for your radio being a bit
off frequency but that is not the same. It seems many have asked the
question about sound card calibration and correction but I haven't
found any definitive answer one way or the other or even if it really
matters. In general use, I don't think it really matters. Only when you
start scratching at the limits might you find some interesting artefacts.

I wonder what if any effect sound card sampling error might play in SNR
or DRIFT measurements? I wonder how I could go about devising an
experiment to try and make that determination?

I think as a start I might try using spectrum lab to sample some WSPR
signals while recording FFT (etc) details just to see what I might be
able to "see".

cheers, Graham ve3gtc

On 11/23/2017, "Alan G4ZFQ" <alan4alan@...> wrote:



http://wsprnet.org/drupal/node/7416

Some food for thought.
Graham,

I read that some time ago and marvelled at yet another seemingly
pointless analysis of WSPR spots. But then, I do not understand what was
being analysed.
Seems to me that on the limits all sorts of things can affect SNR
results and they should simply be avoided.
But then I've always wished that signal AND noise figures could be
provided for users that want to analyse results and really know what
they mean.

Windows messes around with and re-samples to the 11025k which the
WSPR or WSJT-X program uses.

Sample rate? My Delta 44 are locked on 48ksps when used by WSPR, they do
have the 11025 setting but it is not selected. If I run SpecLab at
8000ksps then that's what the control panel shows. Where do you get the
11025?
Any sample rate deviations could be averaged by the many passes WSPR
makes over a weak signal. But that's me guessing again.

the vast majority of users never calibrate their sound card / ADC
interface in any way.

How do you do that? Very few programs give that option. The only way I
know is when using VAC, then differences between soundcard sampling and
the actual computing rate can be compensated. I do not know how to do
that properly other than by trial and error...

73 Alan G4ZFQ


Alan G4ZFQ
 

A quick
search will turn up many. Here a few to get started:
Graham,

OK:-)

But as you say only these specialised programs have compensation. I think this is either for when the card crystal is used as a frequency counter reference or in order to allow for differences between the soundcard and the computer system clocks when this can affect the program output.

WSPR will be looking the 4 tones which might themselves be varying due to propagation and/or TX/RX drift. It is not looking for precise frequencies, just tones separated by approximately the WSPR standard.
SpecLab is a complex program, maybe there is a way to compensate for sample rate and send the corrected audio to WSPR.
Or, how about using VAC? The in/out sample rate can be compensated, would that work?

As I said, I'm amazed at the computer power used for WSPR analysis. In my opinion there is so much variation in propagation and probably in the way WSPR finally decides to present a low SNR that low SNRs will not be reproducible. (I think this is basically what G3ZIL says?)
Certainly it seems propagation affect things, several times I have compared two RX systems, one clearly wins over one day, the other one wins the next day. Or, are these just random variations?
Even two seemingly identical RX systems will have small differences which could affect weak signal decoding.

73 Alan G4ZFQ

https://www.jeffreykopcak.com/2015/10/19/nbemsfldigi-sound-card-calibration/
If you have ever used FLDIGI to decode WEFAX images you will be aware of
the image slanting one way or the other til you have it calibrated.
http://www.g4jnt.com/RX_Soundcard_cal_v1.pdf
www.wb1gof.org/files/FrequencyCalibration.pptx
http://www.qsl.net/hiarc/Presentations/Frequency_Measurement_with_uHz_accuracy_Rev-C.pdf
http://ve2azx.net/technical/FMT/SpecLabInfo.pdf
That is all find and dandy if there was a way in WSPR or WSJT-X to
correct the sample rate t


Daniel Ekman SA2KNG
 

Hi,
This discussion seems to have branched in two different directions. One is drift and the other is absolute frequency. Please tell me if I'm way off on this, speculations follow:
From WRPS perspective the absolute frequency the due to uncalibrated crystals and sample rates should not matter, given it does not take it outside of the allowed frequency window. It should still be a fixed frequency with a slight offset, indistinguishable with intended TX offset, but looking as a basically straight line from the decoders perspective. Perfecting sound card sample rates and oscillator calibration in the transmitter and receiver does not affect this. WEFAX/SSTV decoding is not the same, and the image slanting does not work the same way in WSPR or PSK.
Ignoring atmospheric effects, drift is one or more unstable clock signals in the system, making the received frequency wander around. This does make it more difficult to decode in WSPR as the 4 tones i nthe beginning is not the same as in the end, with other overlapping signals and nonlinear drifts.
To sum it up, frequency stability is more important than absolute frequency calibration in WSPR, JT65, JT9, FT8 etc.


Graham, VE3GTC
 

Good morning Alan (and all),

Agreed with all you said.

This discussion has gotten me wondering just how the WSPR does determine the reported figure for DRIFT and SNR. There are documents with the details, I guess I will just have to do some reading to get a better understanding.

Perhaps we need to stop making this so complicated and just accept that for our simple amateur use that whatever is reported as SNR or DRIFT is OK and is acceptable and has more value as a relative figure of merit  within +/- X of the reported value rather than a absolute and precise value.

VAC's add another layer of uncertainty. Yes, you can adjust sample rates in and out but I don't know enough about how it's done to feel comfortable that any loss in the conversion will have no impact.

I use a couple of Lexicon Alpha USB sound cards. These have a max sample rate of 48k. However, if I just plug and go on a Windows machine I find that when I look at the properties of these devices under recording devices that Windows has defaulted them to a 44,100 sample rate.  Even though the WSPR/WSJT-X programs state that a requirement for the program is a sound card having a 48k sample rate, they work just fine with my Alpha USB sound card.

I have for some time been running an experiment comparing my 40m off center fed dipole (apex just over 7 meters) and my short unterminated beverage on 40m.  One is connected to my Yaesu FT-950 and the other to my FT-817. I spent some time ensuring each radio was set up so as to be as nearly the same as the other. Each radio feeds an Alpha USB sound card, one to a Windows 10 machine and the other to a Raspberry Pi. WSJT-X v1.7.0 is used on both the Windows 10 and Raspberry Pi where the setting for each program are the same.

I don't know if you are familiar with KB9AMG's WSPR statistics web page. This is the link to the one showing 40m

http://mardie4.100webspace.net/wspr/top_wspr_spotters_40m.html

listed are callsigns and counts relative to the placing for that specific band. I am using both of my callsigns ve3gtc and ve3ghm, stats for each here:

http://mardie4.100webspace.net/wspr/sptr.pl/2,281676

http://mardie4.100webspace.net/wspr/sptr.pl/2,281369

Those last two links may not work from day to day. I don't know if they are more or less static based on callsign or dynamically created every day.

In any case, you can see that the counts for 40m for these two calls various from day to day, sometimes a little, sometimes a lot. You too have noted this phenomenon in some of your comparisons.

More interesting is that for the same date-time, one will report stations that the other does not and vice versa, not always but sometimes. And there does not seem to be a preference for one over the other to be providing decodes that the other is not.

Are these differences the result of propagation and antenna characteristics (most likely) or the result of differences in processing (Windows PC vs Linux Raspberry pi) and other hardware (FT-950 vs FT-817) (not as likely unless the software and hardware are grossly and differently configured). Spot checking of wspr spots has shown that when the same TX is received at the same time by both that DRIFT is never different but SNR is sometimes the same, sometimes different where sometimes the dipole has provided the highest SNR and other times not.

I have read through G3ZIL's report but need to spend some more time with it; I am not yet quite sure what is being reported.

Cheers, Graham ve3gtc

On 2017-11-24 10:54, Alan G4ZFQ wrote:

 A quick
search will turn up many. Here a few to get started:
Graham,

OK:-)

But as you say only these specialised programs have compensation. I think this is either for when the card crystal is used as a frequency counter reference or in order to allow for differences between the soundcard and the computer system clocks when this can affect the program output.

WSPR will be looking the 4 tones which might themselves be varying due to propagation and/or TX/RX drift. It is not looking for precise frequencies, just tones separated by approximately the WSPR standard.
SpecLab is a complex program, maybe there is a way to compensate for sample rate and send the corrected audio to WSPR.
Or, how about using VAC? The in/out sample rate can be compensated, would that work?

As I said, I'm amazed at the computer power used for WSPR analysis. In my opinion there is so much variation in propagation and probably in the way WSPR finally decides to present a low SNR that low SNRs will not be reproducible. (I think this is basically what G3ZIL says?)
Certainly it seems propagation affect things, several times I have compared two RX systems, one clearly wins over one day, the other one wins the next day.  Or, are these just random variations?
Even two seemingly identical RX systems will have small differences which could affect weak signal decoding.

73 Alan G4ZFQ


Alan G4ZFQ
 

Graham,

This discussion has gotten me wondering just how the WSPR does determine the reported figure for DRIFT and SNR.
I was going to reply to Daniel saying that this is getting more a series of speculations rather than a discussion. Certainly decoding could be considered imperfect, bad decodes of marginal signals do occur.

I use a couple of Lexicon Alpha USB sound cards. These have a max sample rate of 48k. However, if I just plug and go on a Windows machine I find that when I look at the properties of these devices under recording devices that Windows has defaulted them to a 44,100 sample rate.  Even though the WSPR/WSJT-X programs state that a requirement for the program is a sound card having a 48k sample rate, they work just fine with my Alpha USB sound card.
I always think it is a good idea to reset the Windows preferred sample rate to what you know to be required by a program. (If you do.) That might avoid any unnecessary resampling. Or, does it actually change to the required rate without telling you?

I don't know if you are familiar with KB9AMG's WSPR statistics web page. This is the link to the one showing 40m
No, I di not know that one, thanks. I see the home page http://mardie4.100webspace.net/wspr/ (I wanted to see how I rate with my 20m RX.) A real example of data processing! I gave up trying with the monthly download, I have no idea how to look at it unless I split it into a large number of smaller pieces.

There is also http://wspr.pe1itr.com/index.php a less comprehensive view.

It has been my practice for quite a while just to notice the difference and shrug my shoulders, unless there really is a significant difference after a long-term comparison. As you say some not-too-low SNR signals can be missed by one instance and different ones missed by the other.
But then I'm not sure what using WSPR for propagation research will prove. It's a good yes/no tool but much of the interesting DX areas are not covered.

73 Alan G4ZFQ

http://mardie4.100webspace.net/wspr/top_wspr_spotters_40m.html
listed are callsigns and counts relative to the placing for that specific band. I am using both of my callsigns ve3gtc and ve3ghm, stats for each here:
http://mardie4.100webspace.net/wspr/sptr.pl/2,281676
http://mardie4.100webspace.net/wspr/sptr.pl/2,281369
In any case, you can see that the counts for 40m for these two calls various from day to day,


TrueBlue
 

I have the same problem as the OP and the condition remains mysterious.  At 40m drift is at 0 at least 90% of the time and never shows worse than -1.

On 20m 90% of the drift is -2 to -4.

I applied a clip-on heatsink to the crystal with no apparent effect.  I bundled up the U3S, with the same outcome.

"Park" was programmed to 3 (off) as there was some interference being picked up from it when it was in the default setting.  That cleared it and had no ill effects.

I just now changed "Park" to 2 150,000,000 to see if that made any difference.

I was fortunate that VE6JY was consistently picking up my signals [check Youtube for a remarkable video of his antenna farm and see why].  My drift to VE6JY immediately went from -3 and -4 to 3 and 4.  So, there was an obvious effect, but no improvement.  This is very strange. 

I'm assuming, never having seen a -5 or 5, that beyond a drift of -4/4 the WSPR signal just fails to process.  If I knew that I wasn't losing spots to this problem, I'd just ignore it as there doesn't seem to be any way to correct it.  Is that the case?


Hans Summers
 

 
I just now changed "Park" to 2 150,000,000 to see if that made any difference.

I was fortunate that VE6JY was consistently picking up my signals [check Youtube for a remarkable video of his antenna farm and see why].  My drift to VE6JY immediately went from -3 and -4 to 3 and 4.  So, there was an obvious effect, but no improvement.  This is very strange. 

Not at all. If you went from a drift of -3 or -4, to a drift of +3 or +4, then that just means that 150MHz is too large in your case. It is OVER-compensating the drift. Now you should just try with reduced values, lower it from 150MHz. You should see the + drift will come down. You will be able to find a Park 2 frequency that is optimum.  
 
I'm assuming, never having seen a -5 or 5, that beyond a drift of -4/4 the WSPR signal just fails to process.  If I knew that I wasn't losing spots to this problem, I'd just ignore it as there doesn't seem to be any way to correct it.  Is that the case?

Correct, +/- 4 is the most drift that WSPR is set up to deal with. The software makes multiple passes through the recorded 2 minutes of audio, experimenting with different drifts to find the best one. That takes time. So there's a trade-off between processing time, and how much drift it can manage. They chose +/-4. 

Drift can reduce the probability of decodes, so if you see 3/4 then it is best to try to reduce it. 

73 Hans G0UPL


TrueBlue
 

On Wed, Nov 29, 2017 at 07:34 pm, Hans Summers wrote:
 
150MHz is too large in your case. It is OVER-compensating the drift. Now you should just try with reduced values, lower it from 150MHz. You should see the + drift will come down. You will be able to find a Park 2 frequency that is optimum.  
Do you mean small incremental changes, like the 149,000,000 figure mentioned elsewhere, or a more extreme setting, say halving the frequency?

Will this disrupt the currently-proper drift on 40m?  I'm still unclear on why 40m works properly and 20m doesn't.

Thanks for the explanations!