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.wav180912_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.

Sync for DSLWP-B JT4G at 04:20 UTC
Sync for DSLWP-B JT4G at 04:40 UTC

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.

2 Replies to “DSLWP-B clock running late”

  1. Thanks Dani, I think some of us will be using your decoder to determine how much time to shave off of the WSJTx wav files before trying to decode them again.

    Always good stuff.

    73 es TKS

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.