A priori: click on images to enlarge in new tabs.

Introduction
A while ago I seemed to be one of the few, if not the only, Europeans able
to receive 30m WSPR traces of high altitude balloons (HABs) launched in Australia
while floating in/on the southern hemisphere.

One of the avid balloon hunters was -and still is- Bob ZL1RS. At the end of last year
Bob created his own project: the 30m ocean floater. <– please read this.

Bob’s ocean floater was released around May 15th into the Pacific ocean.
Estimated lifetime of this buoy is around 6 – 9 months. The first two weeks ZL1SIX
transmitted its information every hour with accurate timing.

WSPR traces were sent at XX:46:00, followed by two JT9 transmission at XX:48:00 and XX:49:00.
The first JT9 frame contains call (ZL1SIX) and the current six digit Maidenhead locator,
the second JT9 frame contains telemetry: battery voltage and (water) temperature.

However . . . despite extensive testing ashore, as of May 29th it seems that Bob’s PICAXE power saving
software inside the buoy contains a timing bug. ZL1SIX (now) transmits its packets around 10 seconds too early!

The result is ‘normal’ WSPR setups are not able to decode its WSPR & JT9 traces, leaving Bob ZL1RS
and Joe VK5EI the only ones able to receive the floater because they fiddled with their computer timings.

Challenge
To help Bob receiving his buoy (if succesfull) I built up my WSPR & JT9
30m receiving station with Beverage in the quiet nearby woods. The buoy has ca. 100 mW output and
floats in warm salt water, a perfect take off! I reckon it must be possible to receive it in Europe.

However . . . the issue is (read: was) the timing!
As WSPR time client I use rsNTP from Wolf DL4YHF, well known from his Spectrum Lab software.
His NTP client has a feature to deliberately add or substract a timing offset.

This afternoon I mailed Wolf with an unusual rsNTP software request because I also want to compete
in the WSPR Challenge. My request was: rsNTP adds 10 seconds to ‘time’ in the 45th minute of
the hour and eliminates this addition at the end of the 49th minute, to be able to get the ‘normal’ 50th
WSPR time frame properly.

Wolf responded quickly to my mail and was willing to add my weird feature.
Within a few hours Wolf mailed me to download his modified client.

Wolf rewarded my request with an ‘Options’ button and the latest version of his
rsNTP client can be downloaded here.

Before (re)installing this version of rsNTP, please read this first! (please do)

I was the first to download his amended client and it seems to work, see below.

My suggested time offset values are already entered in the defaults.

After the last (current) ZL1SIX JT9 cycle rsNTP corrects ‘time’, as can be seen below in the
time stamps in the WSPR waterfall.

Result
Everybody with a (Windows) WSPR setup now may be able
to receive ZL1SIX properly as far as timing is concerned.

Note: between XX:45:00 and XX:49:55 (-10 sec ; -) you won’t be able to
decode ‘normal’ WSPR / JT9 traces.

But what the heck, it’s for a good cause!

A big thank you to Wolf DL4YHF, true HAM spirit!

And for now . . . fingers crossed if more people are able to decode ZL1SIX . . .

Update (see below):
Bob ZL1RS managed to decode his floater with the modified rsNTP @2246 UTC : -)