The KiwiSDR 2 online store is open for orders! Please visit kiwisdr.nz

To better support FST4W decoding, could Kiwi GPS clock adjustments synchronized with WSPR cycle?

rrobinetrrobinet
in Configuration and Operation

In Wsprdaemon 3.0 I have added support for simultaneous decoding of WSPR-2 and FST4W-120/-300/-900/-1800. The FST4W modes are proving useful on bands at least through 17M but require greater frequency stability than WSPR-2. It has been a pleasant surprise to find that Kiwis tracking 8+ satellites are able to decode -300 and even -900 packets on 20M and they frequently approach the sensitivity of Kiwis fed a GSPDO clock.

If in the current Kiwi SW the GPS clock updates are occurring at random times, I am wondering if the stock Kiwi's FST4W decode performance might be further improved by synchronizing clock updates with the WSPR-2 cycles.

In any case, there are about 20 Kiwi sites now decoding FST4W modes on HF bands, in particular on 20M. Hopefully their reports will encourage more use of the FST4W modes.

Comments

  • jksjks
    edited August 2022

    Yes, this should be fairly easy to do.

    What worries me more is that this is even a problem. GPS correction of the Beagle date/time (as opposed to the constant tiny correction to the Kiwi ADC clock) is not enabled by default. You must explicitly set it on the admin GPS tab. I checked the public Kiwis and 32% of them[1] have it enabled which was more than I would have expected. I thought it would be less. Given they obviously have Internet connectivity, and ntpd is enabled by default, ntpd should really have no problem keeping the date/time very closely synchronized (hopefully without a lot of large time discontinuities of its own).

    The other thing is that the GPS date/time correction is only done "once" per restart according to the code. This can be at a random time, but it should not result in multiple random time-of-day changes. Do you have any statistics that say this is not the case? Are you seeing multiple messages from the GPS correction in the log per restart or could this just be ntpd jumping around?

    [1] I did a curl -Ls rx.kiwisdr.com | grep 'gps_date=1' | wc to count the number of public Kiwis with GPS date/time correction enabled. The full entry is gps_date=X,Y where X is 1 if correction is enabled and Y is 1 is correction has actually occurred.

  • n6gnn6gn

    I think I might take exception to the ability of a native Kiwi/GPS to do a good job on 20m and above on modes longer than 120 seconds. Particularly for FST4W's -300 and longer modes, short term stability of the Kiwi's clock seems to incur enough spectral spreading during a symbol period to reduce the effective SNR and make the hoped-for advantage of these modes unreachable. A short frequency excursion on the order of a symbol spacing for these narrower modes reduces SNR. The result is that a much smaller percentage of potential spots, or no spots at all, may result.

    Not every Kiwi seems to be identical, no doubt there are differences not only in the short term stability of a particular XO but also of the local environment and temperature stability, but we are finding performance with an external GPSDO clock to be significantly better than the native Kiwi frequency correction on mid-upper HF. On top of this, the spreading due to multihop ionospheric propagation appears to often degrade spots in somewhat the same manner.

    BTW, the same seems to be true of the new QRP Labs QDX transceiver.

    Hopefully there will be more detail forthcoming and perhaps some recommendations but I'd suggest not spending too much effort on time precision until a clearer picture of utility can be presented.

    Glenn n6gn

  • rrobinetrrobinet

    My concern is not with the Linux date/time, but with additional spectral spreading Glen describes which would be introduced if clock corrections are being introduced in the middle of a WSPR (or more importantly FST4W-300/900/1800) packet reception. In a stable temperature environment the internal oscillator's drift over even 30 minutes might not alone seriously degrade the SNR or make a signal un-decodable.

    But I only suggest this be tried if it is easy to do.

  • jksjks
    edited August 2022

    Okay, my fault. I misinterpreted the meaning of "clock updates". Yes, I think I should be able to synchronize the GPS-driven ADC clock corrections to the WSPR-2 two minute (wall clock) boundary. I'll do this as an admin configurable option just in case.

  • rrobinetrrobinet

    Excellent. It would be ideal if the cadence of clock updates were configurable: e.g.

    1) update at every even two minutes if you are decoding only WSPR-2 and FST4W-120

    2) update every 30 minutes if you are also decoding FST4W-300/900/1800

    Thanks

  • jksjks

    Not mentioned in the CHANGE_LOG, but for the WSPR/FST4W settings the ADC clock corrections occur in the 8-10 second window at the end of the cycle (mode dependent). This is enough to get 3-4 corrections which is sufficient. This because Christoph's Kalman filter does a good job of removing GPS solution outliers which might otherwise cause large clock swings for a small number of updates in the 10 second window. The clock code has an MMA filter, but this is also obviously limited by the smaller windows.

    In addition, at server startup an initial clock correction takes place just once (as soon as GPS solutions are available and if corrections are not totally disabled) to remove the effect of any clock offset caused by temperature variation.

  • rrobinetrrobinet

    Thanks John. I am in the process of updating all my Kiwis and have encouraged WD users to experiment with their use and report back results.

Sign In or Register to comment.