I tried SuperFox today for about an hour, and I am not sure I figured
out how to use it successfully. And I am not sure the callers figured it
out either. But I did notice that all the callers were low in
frequency. I was receiving on my AirSpy R2 on 50.296 but I had to TX on
50.295 because I was using an offset of 750 Hz. Maybe that is no longer
a requirement. Anyway, for some unkown reason all the callers were low
too, as if they were TX on 50.295 instead of 50.296. After seeing this
email, I made sure to quit WSJT-X after running FT8 and start it up
again before running Superfox.
I am having internet access problems down here in ZD9 but will try to
study up on Superfox and basic F/H tonight. I don't have a good way to
practice it except to run it on the air like I did today. There was no
automatic logging of stations that I was sending RR73 to, and I imagine
this is supposed to happen with a program that is supposed to achieve
such high contact rates. I had to click on a station's callsign so it
was in the DX CAll box and then I could manually log it without getting
a logging error message. I was assuming that contacts made with SuperFox
just are added to my usual WSJT-X ADI log, along with all my other FT8
and Q65 contacts, but I don't seem to be finding all the SuperFox
contacts there. I hope I can figure out how to properly use it because I
was having dozens of callers at once today, and I expect the same to be
the case all week now that 6m cndx are improving... MNI TNX and VY 73,
Lance
On 6 Oct 2024 05:40, Matt Power via wsjt-devel wrote:
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
--
Lance Collister, W7GJ(ex WA3GPL, WA1JXN, WA1JXN/C6A, ZF2OC/ZF8, E51SIX, 3D2LR,
5W0GJ, E6M, TX5K, KH8/W7GJ, V6M, T8GJ, VK9CGJ, VK9XGJ, C21GJ, CP1GJ, S79GJ,
TX7MB, TO7GJ, 3B9GJ, ZD9GJ)
P.O. Box 73
Frenchtown, MT 59834-0073
USA
TEL: (406) 626-5728
QTH: DN27ub
URL: http://www.bigskyspaces.com/w7gj
Skype: lanceW7GJ
2m DXCC #11 - 6m DXCC #815 - FFMA #7
Interested in 6m EME? Ask me about subscribing to the new Magic Band EME
email group, or just fill in the request box at the bottom of my web
page (above)!
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
