Hearing a WSPR station with an erroneous clock
- I was thinking about how to detect WSPR stations with > 2 sec clock error (DT)? Here are two possible ways.
Record 4 minutes of audio, then
1. Widen sync signal search
Search for a best fit DT and DF across the entire recording. The current sync162 imposes a narrow search. Perhaps that is not essential. (Is there any reason candidate MEPT_JT sync signals cannot be extracted from a long record?) After collecting the candidates, decode based on each candidate and look for valid records.
2. Sliding window
Use a 2-minute sliding window in 2-second steps. Apply the standard code to each window, then look for valid records. Doing this quickly would require a multicore implementation. There would be 120 2-second steps. If each decode takes about 5 seconds, the complete search would take 10 minutes on a single processor. With an 8 core CPU, 2 processes per core, decode would take about 38 seconds. (Real-time would require porting to something like a Nvidia Tesla GPU.)
Method #2 could be tested using the existing code. A recorded audio could be chopped up and then fed to the wspr command line. (I would use Matlab, although there may be more audio-specific programs that could do this as well.) It will be interesting to see how many stations are transmitting out of time spec. Using the calculations from above, 4 hours of recordings can be processed in about 10 hours on a regular PC. You could also use the same dataset to track stations that start out within +/- 1 sec UTC, but drift with time.