Dear Lee, Graham, LF Group,

I did some experiments at M0LMH's suggestion (see below)... I think this is what he meant. Perhaps the results are also of interest to  people in the Group who have experience of writing DSP software for the PC.

The top trace in the attachment has the same WSPR beacon message as last night with normal windows clock settings.

The middle trace shows the effect of retarding the windows clock by roughly one minute, while transmitting. The current sequence continues until its normal ending, but when the even minute occurs on the re-set clock, a new sequence begins as well, so for a while there are two overlapping frames. After that, frames are generated normally, according to the RTC timing. At the moment you make the clock adjustment, the time display in WSPR stops incrementing until the windows clock has "caught up", when it starts incrementing again normally.

When the clock is advanced by one minute roughly (lower trace), the current frame continues and terminates normally. There is then a gap until the next even minute of about 1 minute, when the next frame is generated according to the RTC time setting.

I suppose this shows that transmission of a frame is initiated by the real time clock reaching an even minute, but once started, the generation and timing of the bits in the frame is independent of the RTC, although it does not tell us how that timing is achieved. Also, the fact that the time display in WSPR stops when you retard the clock, and that a new frame can be started in the middle of an existing frame, would seem to show WSPR is continuously looking at the RTC data.

The really funny thing is that two frames can be occuring at the same time. That would seem to suggest that more than one instance of the tone generation algorithm is in existence at once! Curious, but perhaps not connected to the problem in hand...

Cheers, Jim Moritz
73 de M0BMU

----- Original Message ----- From: "Lee Hudson" <[email protected]>
To: "'James Moritz'" <[email protected]>; "'Graham'" <[email protected]>
Sent: Thursday, January 29, 2009 5:18 PM
Subject: WSPR Timing issue


Hi Jim, Graham,

I've been having more thoughts on Grahams timing issue, and there are a few
possibilities.

Firstly assuming Graham has been receiving reports that he is on his
frequency from trusted sources then we can rule out sample rate error.
The crystal on the sound card would have to be a long way out to cause such
a problem.
I believe Graham tried two different sound cards with no change.

The second possibility is the the RTC on his PC is fast, again looking at
the reports from last night there does seem to be some drift but definately
not enough do be worried over.
And also I'm sure the time of transmission start was the same from the even
minute epoch.

This leaves a third posibility I think from recalling PC architecture and
that there is a Timer chip, this from memory is clocked from a separate
crystal to the RTC and certainly remote from the sound card. Some PCs use
this crystal also for producing the multiplied up CPU clocks etc.

Point being here is that the Timer is what dictates any functions requiring
sub second interval timing, and is used by windows for task switching etc.

It all boils down to how the WSPR software derrives its timing to decide
when the transition of a bit occurs.
I looked carefully at Jim comparision image, to first check if a bit had
actually been dropped somewhere, and I can't see one.

If I had written the software I would have used the RTC time to decide when
to start the transmission.
Then I would have used the sample rate as the main source of timing from
that point on until the end, even if compensating for a sample rate error.

In my opinion I think the RTC is used to start the transmission, and no real
error here.
The frequency of transmission I'm assuming is also correct, and no real
error from the sound card side.

However if the timing mechanism used to decide when a bit is over and shift
frequency is related to the Timer, this is where the issue may really lie.
Especially if this is how the software is written.
Using Windows Timers can yeild incremental timing issues too, and this may
be a manifestation also.

One final thought that crossed my mind, is that Graham my be using a GPS
signal to keep his PC RTC updated or possibly an NTP server.
From reading deep and dark Microsoft helpfiles this does also affect how
windows maintains it's internal time derived from the Timer, this it keeps
separate from the RTC, but occasionally makes an alignment change.

If this is the case and Graham is updating his Clock say every second from a
GPS, then this could be enough to cause the incremental error.
Simple test here would be to disconnect any external time influence and see
if things improove.

My gut feeling here is that it is really a software issue, and not related
to the hardware as such.
Some may be caused by Windows itself not being overly well designed for
timing purposes.
Second the WSPR software not using the most reliable method for timing
things.

It could be worth another test for Jim to see what happens when you locally
generate a signal and then wind the clock forward say 1 minute.
Record one test normally, then anothor test with the time step introduced.
Does the data output as before and complete a full 2 minute cycle
Or does it truncate the data period skipped and finish on scheduled time
according to the clock.
Or does it truncate the data at the end.
This will give some clue as to how the data bits themselves are timed.
Be intresting also to time step backwards too!!

Cheers,
Lee.