This patch fixes the dial reading problem...still needs to have the calibrated
offset removed too.
*** mainwindow.cpp.bak2024-07-31 11:13:19.540311871 -0500
--- mainwindow.cpp2024-07-31 11:53:08.087278122 -0500
***
*** 3403,3408
--- 3403,3409
// lookup band
If the instructions are to use manual entry or frequency drop down then then I
find no such limitation in the user guide. Even if these were the only methods
used to set rig frequency the undocumented amber on red frequency display may
still be present.
The majority of WSJT-X users will not ha
On 7/31/2024 9:32 AM, Andy Durbin via wsjt-devel wrote:
The problem I reported can be fixed either by using dial
frequency or by using dial frequency + tone offset.
You seem unwilling to accept that the "problem" you reported does not
exist if you follow the instructions we gave you. Repeate
"May I conclude that we want to report the actual
(correct) transmit frequency at all wsjt-x modes (by
definition the lowest FSK tone)."
I had intended to leave this discussion but, since you asked a direct question,
I shall answer it.
My preference is for ALL.TXT, PSKReporter, and logging to us
For normal FT8 operation most anybody should be able to figure out that 14.07*
means 14.074that's the 20M pulldown value that is closest.
There's a lot of utility in reporting the actual tone frequency and very little
advantage in the reporting the base band.
The 7Hz offset you note isn't si
Hi Andy,
May I conclude that we want to report the actual
(correct) transmit frequency at all wsjt-x modes (by
definition the lowest FSK tone).
There are situations where the rig frequency display is
not correct for various reasons such as the transverter
frequency is not adjusted exactly, but is k
