DSLWP-B clock running late

This Wednesday, a DSLWP-B test was done between 04:00 and 06:00 UTC. During this test, a few stations reported on Twitter that they were able to receive the JT4G signal correctly (they saw the tones on the waterfall) but decoding failed.

It turns out that the cause of the decoding failures is that the DSLWP-B clock is running a few seconds late. Thus, the JT4G transmission starts several seconds after the start of the UTC minute and so the decoding fails, since WSJT-X only searchs for a time offset of a few seconds.

Satou Tetsurou JA0CAW has shared a couple of recordings of the JT4G beacon made by JA5BLZ. The recordings can be downloaded here:  180912_0420.wav,  180912_0440.wav. These have been made with WSJT-X, so they start on the top of the UTC minute according to JA5BLZ’s clock.

I have used my JT4G detection algorithm to find the start of the DSLWP-B JT4G transmissions in JA5BLZ’s recordings. The results are show below. We see that the start of the transmission is received between 8 and 9 seconds after the start of the UTC minute.

Comparing these results with the first JT4G test, where the transmission starts between seconds 2 and 3, we see that the DSLWP-B clock is running approximately 6 seconds behind.

During today’s tests, it seems that the clock problem persists. See for instance this report by Ferruccio IW1DTU. It will be interesting to see how this problem evolves, and whether the DSLWP-B clock can be set remotely.