WD 3.0 decoding bug when the CPU runs out of time to finish in one cycle

Rob Robinett

Just last night I learned that when the WD server doesn't have enough CPU to finish a WSPR decode in 110 second, it falls behind by one WSPR cycle and never catches up.  Until I find the time to fix that bug, the appearance of such errors suggest you should configure fewer band and/or modes and/or use a more powerful CPU and/or split your decoding between two or more servers. 

wayne roth

After adding the FST4W modes to 20m I have experienced a loop of errors after several hours of operation on one system (atomic pi Ubuntu 20.04) and the latest version 3.03.1? WD (journal, attached).  Decoding typically takes under a minute but I suspect the time is dependent on the number of signals being extracted and possibly longer than the break between cycles if many signals are present.  

When F5 or F15 modes are added, how does the recording method change?  One file with the full 15 minutes is recorded and portions thereof are read for 2 / 5 minute decodes along the way, or are there multiple files created with lengths equal to the model decode length?