Here's apparently a bug in both WSJT-X 2.7.0-rc7 and WSJT-X v2.7.1-devel 241005-RC7 (aka yesterday's wsjt-x_improved). The essence is that a SuperFox transmitting station can sometimes accidentally be misconfigured with their radio's dial frequency different on transmit and receive (e.g., transmit 28.090 and receive 28.091). Although different transmit-vs-receive dial frequencies are normal for most uses of FT8 and some other WSJT-X modes, they are not supposed to be different for a SuperFox. When they are, the SuperFox User Guide advice of "you're not forced to transmit above 1000 Hz" can be less effective, and often you won't be able to work the SuperFox unless you transmit above 1200 Hz.
The behavior can be consistently reproduced even on the most popular operating system (Windows 10). Here are steps to reproduce and a theory about a possible code mistake: When started, WSJT-X is configured to transmit on 28.091 FT8 with Settings of "Split Operation: Fake It" and "Special operating activity" NOT checked, and set to "Tx Even/1st" and Tx 750 Hz. The transmitting station sends one or more CQs. As intended, the transmit dial frequency is 1000 Hz below the receive dial frequency because of "(n/500)*500 - 1500" in the source code. A receiving station at dial frequency 28.091, with "Special operating activity" not checked, can decode this, and the signal is of course mostly around 750 Hz. The transmitting station then clicks Halt Tx and checks "Special operating activity" and selects Fox and SuperFox mode, and saves this with the "OK" button. Nothing else is changed. The transmitting station clicks Enable Tx and sends one or more CQs. The receiving station is aware of the change to SuperFox, and correctly enables SuperHound. At the SuperFox end, the transmit dial frequency, unfortunately, is still 1000 Hz below the receive dial frequency. The SuperHound station cannot decode this with the 28.091 dial frequency. They can decode this at the 28.090 dial frequency, and see the most prominent part of the SuperFox signal at 750 Hz. However, to complete a QSO, they must choose an audio frequency significantly above 1000 Hz (e.g., 1200 or better 1300) because the SuperFox receive dial frequency is 28.091. The outcome is frustration for SuperHounds below 1000 Hz, and probably a lower QSO rate (the SuperFox completely misses even loud callers at low audio frequencies). There are other ways to reproduce, such as: 1 - Never transmit normal FT8, but make two changes to "Special operating activity" before transmitting (i.e., start up checked, uncheck and click OK, check and click OK). 2 - Never transmit normal FT8 but make one change to "Special operating activity" before transmitting (reproduces only with wsjt-x_improved). (end of steps to reproduce) Code theory (not tested): In earlier WSJT-X versions such as 2.7.0-rc4, MainWindow::setXIT did not depend on m_specOp. However, to support SuperFox, code was added to make m_XIT zero for the "SpecOp::FOX==m_specOp && m_config.superFox()" case. MainWindow::on_actionSettings_triggered did not account for this change, and still has the line "setXIT (ui->TxFreqSpinBox->value ())" located before the m_specOp=m_config.special_op_id() line. This apparently means that the setXIT adjusts m_XIT on the basis of m_specOp's previous value (before the most recent settings change). For example, if the previous settings had normal FT8 and Tx had been 750 Hz, then "if (!(m_bSimplex || (SpecOp::FOX==m_specOp && m_config.superFox())))" is true, and m_XIT is set to -1000, explaining why the DXpedition transmitted on 28.090 instead of 28.091. By contrast, if the previous settings had normal FT8 and Tx had been 2600 Hz, then m_XIT is set to 1000, and the SuperFox transmit frequency ends up 1000 Hz above its receive frequency. Here, you might be able to get through the pileup most quickly if you decode on dial frequency 28.092 (audio 750 to 2262) and you call on dial frequency 28.091 (audio below 1000), where nobody else would normally call. MainWindow::guiUpdate may also be relevant. It calls "ui->TxFreqSpinBox->setValue(750)" before the "setXIT (ui->TxFreqSpinBox->value ())" call. If the current spinbox value is not 750, then that setValue causes MainWindow::on_TxFreqSpinBox_valueChanged to execute with the old value of m_XIT, such as -1000. If the current spinbox value is 750, then the code in the on_TxFreqSpinBox_valueChanged function does not execute. Thus, even when m_XIT becomes correct later, on_TxFreqSpinBox_valueChanged does not change the transmit frequency. Matt, KA1R _______________________________________________ wsjt-devel mailing list wsjt-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wsjt-devel
