VS: [WSJTX] Feature Request #WSPR

Reino Talarmo

On Apr 30, 2021, at 2:58 PM, Pete Ritter via groups.io <cpritter@...> wrote:


When I'm working FT8 on crowded bands, my modestly-spec'ed computer often doesn't complete decoding a receive cycle before the next transmit cycle begins. This can result in missed responses from my QSO partner.


As I understand it, this is not correct at all.  If he is your QSO partner, he is under the GREEN receive “goalpost”.  That is the first signal processed by the program.  It has the highest priority.


If this happens enough during a QSO, the QSO is not completed. Typically, neither CPU nor RAM is maxed when this happens, so.i conclude that the CPUs are just too slow. I use AP and deep decoding to work weak DX stations.


Almost everyone is getting decodes after the next cycle begins now with the newer versions.  There are THREE decode cycles. The last one begins at the end of the receive cycle and is digging hard to get them all.

There seems to be a simple solution: I'd like to be able to tell WSJT-X to limit it's processing of received signals to the area around the frequency of my QSO partner.


Already done, as above.


I’m sure that if this is incorrect, Bill will chime in and correct me.


73, Gary - AG0N



Only minor clarification on the green goal post decoding. It is first tried but, if not succeeded in the first go, then it will be decoded only after having all decoded signals substractions are done. So it may slip to Tx period, but WSJT-X should start to send the correct message from that spot onwards.

There is a possibility to limit range where decoding is done. It is the width of the waterfall. BUT then stations outside that range will be totally lost. There is also another less important side-effect the S/N values are too optimistic!

73, Reino OH3mA