Menu
▾
▴
wsjt-devel — WSJT software development
You can subscribe to this list here.
| 2007 |
Jan
(30) |
Feb
|
Mar
(10) |
Apr
(60) |
May
(62) |
Jun
|
Jul
(3) |
Aug
(3) |
Sep
(10) |
Oct
(17) |
Nov
(1) |
Dec
(14) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(21) |
Mar
(4) |
Apr
(15) |
May
(37) |
Jun
(98) |
Jul
(120) |
Aug
(1) |
Sep
(14) |
Oct
|
Nov
(31) |
Dec
(8) |
| 2009 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(25) |
May
(88) |
Jun
(5) |
Jul
(31) |
Aug
(25) |
Sep
(4) |
Oct
(19) |
Nov
(119) |
Dec
(11) |
| 2010 |
Jan
(3) |
Feb
(19) |
Mar
(4) |
Apr
|
May
(7) |
Jun
(17) |
Jul
|
Aug
(4) |
Sep
(20) |
Oct
(3) |
Nov
(29) |
Dec
(86) |
| 2011 |
Jan
(6) |
Feb
|
Mar
(6) |
Apr
(8) |
May
(1) |
Jun
(12) |
Jul
(9) |
Aug
(4) |
Sep
(7) |
Oct
(9) |
Nov
|
Dec
(1) |
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
(5) |
Jul
|
Aug
|
Sep
(5) |
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(10) |
Feb
(7) |
Mar
(4) |
Apr
(76) |
May
(66) |
Jun
(101) |
Jul
(210) |
Aug
(255) |
Sep
(83) |
Oct
(18) |
Nov
(3) |
Dec
(3) |
| 2014 |
Jan
(187) |
Feb
(139) |
Mar
(99) |
Apr
(173) |
May
(106) |
Jun
(61) |
Jul
(50) |
Aug
(66) |
Sep
(342) |
Oct
(238) |
Nov
(251) |
Dec
(189) |
| 2015 |
Jan
(96) |
Feb
(295) |
Mar
(260) |
Apr
(271) |
May
(358) |
Jun
(531) |
Jul
(311) |
Aug
(231) |
Sep
(267) |
Oct
(219) |
Nov
(452) |
Dec
(390) |
| 2016 |
Jan
(367) |
Feb
(128) |
Mar
(208) |
Apr
(308) |
May
(237) |
Jun
(272) |
Jul
(90) |
Aug
(289) |
Sep
(153) |
Oct
(214) |
Nov
(167) |
Dec
(282) |
| 2017 |
Jan
(194) |
Feb
(173) |
Mar
(267) |
Apr
(102) |
May
(39) |
Jun
(201) |
Jul
(1064) |
Aug
(363) |
Sep
(383) |
Oct
(289) |
Nov
(237) |
Dec
(185) |
| 2018 |
Jan
(175) |
Feb
(198) |
Mar
(489) |
Apr
(222) |
May
(414) |
Jun
(297) |
Jul
(329) |
Aug
(136) |
Sep
(383) |
Oct
(590) |
Nov
(834) |
Dec
(1114) |
| 2019 |
Jan
(425) |
Feb
(177) |
Mar
(319) |
Apr
(515) |
May
(337) |
Jun
(447) |
Jul
(525) |
Aug
(252) |
Sep
(119) |
Oct
(108) |
Nov
(211) |
Dec
(228) |
| 2020 |
Jan
(158) |
Feb
(141) |
Mar
(94) |
Apr
(99) |
May
(545) |
Jun
(470) |
Jul
(211) |
Aug
(142) |
Sep
(181) |
Oct
(128) |
Nov
(219) |
Dec
(213) |
| 2021 |
Jan
(243) |
Feb
(514) |
Mar
(279) |
Apr
(101) |
May
(97) |
Jun
(259) |
Jul
(164) |
Aug
(205) |
Sep
(149) |
Oct
(301) |
Nov
(139) |
Dec
(159) |
| 2022 |
Jan
(116) |
Feb
(70) |
Mar
(63) |
Apr
(46) |
May
(50) |
Jun
(114) |
Jul
(173) |
Aug
(106) |
Sep
(127) |
Oct
(65) |
Nov
(117) |
Dec
(102) |
| 2023 |
Jan
(139) |
Feb
(99) |
Mar
(52) |
Apr
(132) |
May
(238) |
Jun
(75) |
Jul
(91) |
Aug
(25) |
Sep
(36) |
Oct
(64) |
Nov
(45) |
Dec
(91) |
| 2024 |
Jan
(156) |
Feb
(56) |
Mar
(30) |
Apr
(16) |
May
(40) |
Jun
(53) |
Jul
(327) |
Aug
(171) |
Sep
(67) |
Oct
(53) |
Nov
(43) |
Dec
(78) |
| 2025 |
Jan
(112) |
Feb
(27) |
Mar
(46) |
Apr
(49) |
May
(58) |
Jun
(54) |
Jul
(42) |
Aug
(10) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Hasan N. <hba...@gm...> - 2025-04-27 14:00:51
|
There is no need for your feature request. WSJT-X should not be using the only audio device available to your computer, or put it another way, X should not be using the windows default audio device. Add a simple sound card usb dongle (less than $10 on Amazon). Use that for WSJT-X, use the default Windows audio device for your warnings. Or...if you have a modern radio with USB interface, use the Radio's USB interface for both Audio and CAT control in WSJT-X, and use the computer's default sound card for alerts from WSJT-X. Don't use windows' default audio device (built in audio/sound card in the computer) for WSJT-X TX and RX 73, N0AN Hasan On Sat, Apr 26, 2025 at 11:51 AM F4HTB via wsjt-devel < wsj...@li...> wrote: > Hello everyone, > > I would like to suggest a small but useful improvement for WSJT-X > regarding audio handling. > > Currently, WSJT-X uses the system’s default audio output to play alert > sounds. > In some setups, this can lead to problems: I have noticed, both > personally and among other operators, that when using the same audio > interface for radio transmission and for WSJT-X, the alert sounds may > accidentally be transmitted over the air. > > I have observed this behavior both under Windows and Linux. > > To prevent this issue, I propose adding an option in the Audio tab of > the configuration menu to allow users to select a specific output device > for alert sounds, independently of the device used for radio transmissions. > > For reference, Fldigi has provided this capability for a long time, > which helps avoid this kind of problem. > > Thank you very much for considering this request, and thank you for all > the excellent work on WSJT-X. > > 73, > > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Andy D. <a.d...@ms...> - 2025-04-26 20:37:13
|
"I have been using WSJT-X since before version 1.0 was released. I have never heard WSJT-X produce an alert sound." Never mind, I see it is an option that have not enabled. I use JTAlert. 73 Andy, k3wyc |
|
From: Andy D. <a.d...@ms...> - 2025-04-26 20:05:28
|
" Currently, WSJT-X uses the system’s default audio output to play alert sounds." I have been using WSJT-X since before version 1.0 was released. I have never heard WSJT-X produce an alert sound. What WSJT-X alert sounds are you hearing/transmitting? The usual problem is that the operator configures Windows so the rig audio device is set as the Windows default sound device. It must never be set as default. 73, Andy k3wyc |
|
From: Reino T. <rei...@ko...> - 2025-04-26 17:54:38
|
Hi, there should not be any need to use the default audio device for the WSJT-X signal transmission. If your computer has only a single audio device, then you cannot use that for both purposes, I assume. You need to use an external audio codec in that case. In short, the WSJT-X audio device should not be a Windows audio device. 73, Reino OH3mA > -----Original Message----- > From: F4HTB via wsjt-devel <wsjt- > de...@li...> > Sent: Saturday, April 26, 2025 7:34 PM > To: wsj...@li... > Cc: F4HTB <ol...@f4...> > Subject: [wsjt-devel] Subject: Feature request: Output > audio device selection for alert sounds > > Hello everyone, > > I would like to suggest a small but useful improvement for > WSJT-X regarding audio handling. > > Currently, WSJT-X uses the system’s default audio output to > play alert sounds. > In some setups, this can lead to problems: I have noticed, > both personally and among other operators, that when > using the same audio interface for radio transmission and > for WSJT-X, the alert sounds may accidentally be > transmitted over the air. > > I have observed this behavior both under Windows and > Linux. > > To prevent this issue, I propose adding an option in the > Audio tab of the configuration menu to allow users to select > a specific output device for alert sounds, independently of > the device used for radio transmissions. > > For reference, Fldigi has provided this capability for a long > time, which helps avoid this kind of problem. > > Thank you very much for considering this request, and > thank you for all the excellent work on WSJT-X. > > 73, > > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: F4HTB <ol...@f4...> - 2025-04-26 16:47:44
|
Hello everyone, I would like to suggest a small but useful improvement for WSJT-X regarding audio handling. Currently, WSJT-X uses the system’s default audio output to play alert sounds. In some setups, this can lead to problems: I have noticed, both personally and among other operators, that when using the same audio interface for radio transmission and for WSJT-X, the alert sounds may accidentally be transmitted over the air. I have observed this behavior both under Windows and Linux. To prevent this issue, I propose adding an option in the Audio tab of the configuration menu to allow users to select a specific output device for alert sounds, independently of the device used for radio transmissions. For reference, Fldigi has provided this capability for a long time, which helps avoid this kind of problem. Thank you very much for considering this request, and thank you for all the excellent work on WSJT-X. 73, |
|
From: Andy D. <a.d...@ms...> - 2025-04-25 12:37:42
|
re fix for 2.8.0. improved with Win 8.1 - "WSJT-X rig control will now work until WSJT-X is closed" Rig control fails as soon as TX is made so, although stable for band change and frequency change in band, fix is no use for operating. 73, Andy, k3wyc |
|
From: Andy D. <a.d...@ms...> - 2025-04-23 17:53:44
|
April 16th I reported that I was having issues with ver 2.8.0 - "Changing band on WSJT-X changes the "dial" frequency displayed my WSJT-X but does not change the frequency of my TS-590S. I revert to devel 240721 improved PLUS and rig control works." Uwe, DG2YCB and Roger, W3SZ spent a lot of time, spread over several days, attempting to find what was causing my problem. I appreciate their support very much even though the cause of the issue was not identified. I'll report what was found in case anyone else experiences the problem: 1. The issue is seen with Windows 8.1 and not with Windows 11. 2. There is a 100% repeatable fix for the problem but the fix must be applied each time WSJT-X 2.8.0 is started on the Win 8.1 computer. 3. Run WSJT-X and open Settings/Radio 4. Change the settings of Mode and Split (changing just one of these does not work) 5. Close settings 6. Open settings again and set Mode and Split back to preferred values 7. Close settings 8. WSJT-X rig control will now work until WSJT-X is closed Many people have reported that ver 2.8.0 works fine for them but, to the best of my recollection, those reports did not specify what OS was being used. Does anyone have 2.8.0 working on a Win 8.1 computer? If so, what rig type and what rig interface selection? Most of my testing was done with a Kenwood TS-590S and OmniRig 1.20. Changing to OmniRig 1.18 or Hamlib did not fix the issue. 73, Andy, k3wyc |
|
From: Reino T. <rei...@ko...> - 2025-04-22 10:34:38
|
Welcome Ed, May I add into the list of questions for our help: Which rig? How is it connected to PC? Do you get any error messages? You may easily copy and paste error messages in a text format from the error window by Ctrl-C ja paste it as a text into your mail by Ctrl-V. No need to paint or copy as a picture. Just for your information, you may get also help on WSJT GROUP User Forum, see user guide 21.2. Help with Setup. You'll find the user guide selecting on the Help menu 'Local user guide', if you have not downloaded it otherwise. 73, Reino OH3mA > -----Original Message----- > From: Gene Marsh via wsjt-devel <wsjt- > de...@li...> > Sent: Tuesday, April 22, 2025 2:43 AM > To: software development WSJT <wsjt- > de...@li...> > Cc: Gene Marsh <w8...@me...> > Subject: Re: [wsjt-devel] Troubles > > Ed, > > What flavor of Windows? 10? 11? I have 2 Yoga’s, one > each 10 and 11. No problems. > > Also, have you done any updates on Windows recently? > > And, check you Download folder (by date). > > 73 de W8NET Miles “Gene” Marsh > ARRL A1 Operator > 3905 Century Club Master #47 > 3905 Century Club 8th Area Director > Hurricane Watch Net member > Portage County Amateur Radio Service trustee > > > On Apr 21, 2025, at 6:12 PM, Edward Luers via wsjt-devel > <wsj...@li...> wrote: > > > > > > > > Hi, > > > > I am using a Lenovo Yoga 7i and was running version 2.6.1 > 64 with little issues that really didn't bother me. I decided > to try 2.70. That was a mistake because I deleted the 2.6.1 > file before I downloaded 2.7. Well 2.7 didn't want to run so > I downloaded 2.6.1 again and when I try to run it 2.7 tries > to work and it doesn't. So I tried to uninstall 2.7 and I get a > message that says it can't find 2.7 to uninstall. I'm by no > means a computer guy. I know you don't want to train a > newbe, but any help would be appreciated. > > > > Ed KE6SU > > > _______________________________________________ > > wsjt-devel mailing list > > wsj...@li... > > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Gene M. <w8...@me...> - 2025-04-22 00:22:50
|
Ed, What flavor of Windows? 10? 11? I have 2 Yoga’s, one each 10 and 11. No problems. Also, have you done any updates on Windows recently? And, check you Download folder (by date). 73 de W8NET Miles “Gene” Marsh ARRL A1 Operator 3905 Century Club Master #47 3905 Century Club 8th Area Director Hurricane Watch Net member Portage County Amateur Radio Service trustee > On Apr 21, 2025, at 6:12 PM, Edward Luers via wsjt-devel <wsj...@li...> wrote: > > > > Hi, > > I am using a Lenovo Yoga 7i and was running version 2.6.1 64 with little issues that really didn't bother me. I decided to try 2.70. That was a mistake because I deleted the 2.6.1 file before I downloaded 2.7. Well 2.7 didn't want to run so I downloaded 2.6.1 again and when I try to run it 2.7 tries to work and it doesn't. So I tried to uninstall 2.7 and I get a message that says it can't find 2.7 to uninstall. I'm by no means a computer guy. I know you don't want to train a newbe, but any help would be appreciated. > > Ed KE6SU > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Edward L. <el...@gm...> - 2025-04-21 22:06:15
|
Hi, I am using a Lenovo Yoga 7i and was running version 2.6.1 64 with little issues that really didn't bother me. I decided to try 2.70. That was a mistake because I deleted the 2.6.1 file before I downloaded 2.7. Well 2.7 didn't want to run so I downloaded 2.6.1 again and when I try to run it 2.7 tries to work and it doesn't. So I tried to uninstall 2.7 and I get a message that says it can't find 2.7 to uninstall. I'm by no means a computer guy. I know you don't want to train a newbe, but any help would be appreciated. Ed KE6SU |
|
From: Uwe, D. <dg...@gm...> - 2025-04-20 19:33:56
|
Hi all, Is there anyone else out there besides K3WYC who has a TS-590S and has OmniRig installed? If so, please contact me by private email. 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB |
|
From: Uwe, D. <dg...@gm...> - 2025-04-20 10:25:16
|
Hi Andy, I have just systematically tested it again. My FT-991 runs with v2.8.0 perfectly with OmniRig. Both with Mode=None and with Mode=USB as well as with Mode=Data/Pkt. And all these variants with both Split Operation Rig and Fake it. Not a single issue! Just like with the previous 2.7.1-devel versions. This means that your OmniRig issue must be related specifically to your rig or to your setup in general. But you know that you can easily edit any OmniRig driver yourself, don't you? I would advise you to do this next. The drivers are at C:\Program Files (x86)\Afreet\OmniRig\Rigs. See what commands are in there and adjust them if necessary so that you get what your rig needs. With my very slow Malachite SDR receiver, I also got it to work with OmniRig that way. I had used it until Mike W9MDB wrote a Hamlib driver for the Malachite SDR RX and we both optimized it together so that it worked even better than with OmniRig in the end. 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm... Info: www.qrz.com/db/DG2YCB Am 19.04.2025 um 18:20 schrieb Andy Durbin via wsjt-devel: > "2.8.0 improved, when used with OnmiRig, does not control rig > frequency when Mode = None. It does control rig frequency when Mode = > USB." > > A bit more experimenting with 2.8.0. showed MODE=USB was a necessary > but not sufficient condition. Rig control only seemed to work if > Split operation was changed too. > > E.g. > > Start with Mode None, Split Rig - frequency control inop > Set Mode USB - frequency control inop > Set Split Fake it - Rig RX VFO responds. TX VFO unchanged > Set Split Rig - Frequency control ok > Set Mode none - Frequency control inop > Set Mode USB - Frequency control inop > Set Split none - Rig RX VFO responds. TX VFO unchanged > Set Split Rig - frequency control ok > > This is only part of the problem. The fact that the WSJT-X dial > frequency does change means the WSJT-X frequency display is not always > rig dial frequency but is sometimes the commanded dial frequency. > > Shouldn't WSJT-X dial frequency always be the frequency reported by > the rig and have some alert if rig frequency is not equal to commanded > frequency? > > 73, > Andy, k3wyc > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Mike L. <k7...@ho...> - 2025-04-20 02:25:09
|
I found the hamlib source code today and took a look. AC log uses the Dummy rig and aclog.c translates the AC Log commands to hamlib commands for this virtual rig interface.
In aclog_get_freq() function, the frequency is read from the http string.
FREQ>1,296.171100</FREQ></
There is a comma for all frequencies 1GHz and higher. The function does not account for that comma and ends up with just the GHz digit * 1e6 to get 1.000MHz that I am seeing. Same goes for 2304 getting 2MHz and 5760 getting 5Mhz. Stripping the comma and other whitespace before multiplying should resolve the problem.
I will need to set up a build environment for hamlib and likely wsjt-x to try it myself, will take some time.
Relevant code excerpt: See the sscanf line.
char *p = strstr(value, "<FREQ>");
*freq = 0;
if (p) { sscanf(p, "<FREQ>%lf", freq); }
*freq *= 1e6; // convert from MHz to Hz
if (*freq == 0)
{
rig_debug(RIG_DEBUG_ERR, "%s: freq==0??\nvalue=%s\n", __func__,
value);
RETURNFUNC(-RIG_EPROTO);
}
else
{
rig_debug(RIG_DEBUG_TRACE, "%s: freq=%.0f\n", __func__, *freq);
}
if (vfo == RIG_VFO_A)
{
priv->curr_freqA = *freq;
}
else // future support in ACLOG maybe?
{
priv->curr_freqB = *freq;
}
-----Original Message-----
From: Mike Lewis via wsjt-devel <wsj...@li...>
Sent: Thursday, April 17, 2025 10:23 AM
To: wsj...@li...
Cc: Mike Lewis <k7...@ho...>
Subject: [wsjt-devel] AC Log Hamlib error on frequencies 1GHz and higher
I am using N3FJP AC Log which has rig control. I set up various versions (2.7.0 and 2.8.0_improved) of WSJT-X to use the N3FJP AC Log rig definition. Radios tested are IC-905, IC-705 (with a transverter aware band decoder) and Elecraft K3. The later 2 have transverters on 903 and 1296 and they report the transverter's frequency over CAT.
Focusing on just the K3 or IC-905, when any band below 1GHz is selected, all works as it should, with or without WSJT-X running.
Change bands by any means (radio or WSJTX) to any band higher than 903, WSJT-X reads the frequency as only the 1GHz digit times 1,000,000. For example.
1296 results in 1.000,000Hz.
2304.100.000 results in 2.000MHz
5760.1 results in 5.000MHz
After WSJTZX now think the frequency is 1.000Mhz (for 1296) it thinks a band change occurredon the WSJT-X side and sends 1.0MHz to AC Log where it is updated and AC Log in turn changes the radio to 1.000Mhz.
I turned on WSJT_X Rig Control logging and got a narrowed log that I think shows the problem is in the WSJT-X hamlib code. I tried WSJT-X V2.8.0_improved today, same issue with frequencies above >999Mhz.
In this attached log, I have the K3 set to 1296.171.100. AC Log is controlling the rig. All is good so far.
I then start up WSJT-X. It queries AC Log for freq and gets 1296. Has correct band (23) and mode (SSB).
string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD>
The next thing is it extracts the frequency from the message wrong
[2025-04-17 16:32:23.578614][00:00:02.941014][RIGCTRL:trace] aclog_get_freq: freq=1000000
Now WSJTX thinks it is 1.000MHz. It polls AC Log a bit more, it still gets 1296 as proper.
Then it decided the frequency has changed and sends 1.000MHz to AC Log. Now AC log says 1.000055MHz.
[2025-04-17 16:32:23.585489][00:00:02.951073][RIGCTRL:trace] aclog_set_freq: vfo=VFOA freq=1000055
[2025-04-17 16:32:23.585489][00:00:02.951193][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 43 48 41 4e 47 45 46 52 45 51 <CMD><CHANGEFREQ
[2025-04-17 16:32:23.585489][00:00:02.951197][RIGCTRL:trace] 0010 3e 3c 56 41 4c 55 45 3e 31 2e 30 30 30 30 35 35 ><VALUE>1.000055
On the K3 I see 1.000.055 on the dial, then it immediately changes to 1.000.000. No idea why, step size is 10Hz on the radio.
A log excerpt is pasted below, a full log attached if not stripped.
Shutdown WSJT-X and AC Log frequency stays at 1.000.000.
73,
Mike Lewis, K7MDL
CN87xs
__________________________
[2025-04-17 16:32:23.578614][00:00:02.940480][RIGCTRL:debug] network_flush called
[2025-04-17 16:32:23.578614][00:00:02.940574][RIGCTRL:trace] write_block(): TX 22 bytes
[2025-04-17 16:32:23.578614][00:00:02.940579][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 3e 3c 2f <CMD><READBMF></
[2025-04-17 16:32:23.578614][00:00:02.940583][RIGCTRL:trace] 0010 43 4d 44 3e 0d 0a CMD>..
[2025-04-17 16:32:23.578614][00:00:02.940588][RIGCTRL:debug] *****5:aclog.c(247):write_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.940592][RIGCTRL:debug] *****5:aclog.c(141):read_transaction entered
[2025-04-17 16:32:23.578614][00:00:02.940923][RIGCTRL:trace] read_string_generic(): RX 109 characters, direct=1
[2025-04-17 16:32:23.578614][00:00:02.940948][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 52 45 53 <CMD><READBMFRES
[2025-04-17 16:32:23.578614][00:00:02.940953][RIGCTRL:trace] 0010 50 4f 4e 53 45 3e 3c 42 41 4e 44 3e 32 33 3c 2f PONSE><BAND>23</
[2025-04-17 16:32:23.578614][00:00:02.940957][RIGCTRL:trace] 0020 42 41 4e 44 3e 3c 4d 4f 44 45 3e 53 53 42 3c 2f BAND><MODE>SSB</
[2025-04-17 16:32:23.578614][00:00:02.940960][RIGCTRL:trace] 0030 4d 4f 44 45 3e 3c 4d 4f 44 45 54 45 53 54 3e 50 MODE><MODETEST>P
[2025-04-17 16:32:23.578614][00:00:02.940963][RIGCTRL:trace] 0040 48 3c 2f 4d 4f 44 45 54 45 53 54 3e 3c 46 52 45 H</MODETEST><FRE
[2025-04-17 16:32:23.578614][00:00:02.940967][RIGCTRL:trace] 0050 51 3e 31 2c 32 39 36 2e 31 37 31 31 30 30 3c 2f Q>1,296.171100</
[2025-04-17 16:32:23.578614][00:00:02.940970][RIGCTRL:trace] 0060 46 52 45 51 3e 3c 2f 43 4d 44 3e 0d 0a FREQ></CMD>..
[2025-04-17 16:32:23.578614][00:00:02.940975][RIGCTRL:trace] read_transaction: string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD>
'
[2025-04-17 16:32:23.578614][00:00:02.940983][RIGCTRL:trace] read_transaction: got </CMD>
[2025-04-17 16:32:23.578614][00:00:02.940989][RIGCTRL:debug] *****5:aclog.c(208):read_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.940995][RIGCTRL:debug] ****4:aclog_transaction: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.941001][RIGCTRL:debug] ****4:aclog.c(311):aclog_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941014][RIGCTRL:trace] aclog_get_freq: freq=1000000
[2025-04-17 16:32:23.578614][00:00:02.941022][RIGCTRL:debug] ***3:aclog.c(488):aclog_get_freq returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941028][RIGCTRL:trace] aclog_open: currvfo=VFOA value=<CMD><RIGRESPONSE><RIG>Elecraft</RIG><RIGINDEX>0</RIGINDEX></CMD>
[2025-04-17 16:32:23.578614][00:00:02.941034][RIGCTRL:debug] **2:aclog.c(627):aclog_open returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941047][RIGCTRL:debug] **2:rig.c(3449):rig_get_vfo entered
[2025-04-17 16:32:23.578614][00:00:02.941051][RIGCTRL:trace] rig_get_vfo: cache miss age=1000000ms
[2025-04-17 16:32:23.578614][00:00:02.941055][RIGCTRL:trace] **rig.c(3485) trace
[2025-04-17 16:32:23.578614][00:00:02.941060][RIGCTRL:debug] ***3:aclog.c(850):aclog_get_vfo entered
[2025-04-17 16:32:23.578614][00:00:02.941065][RIGCTRL:debug] ***3:aclog.c(854):aclog_get_vfo returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941069][RIGCTRL:debug] **2:rig_get_vfo: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.941074][RIGCTRL:debug] **2:rig.c(3519):rig_get_vfo returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941087][RIGCTRL:debug] **2:rig.c(2433):rig_get_freq entered
[2025-04-17 16:32:23.578614][00:00:02.941092][RIGCTRL:debug] rig_get_freq called vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941097][RIGCTRL:debug] rig_get_freq(2451) called vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941109][RIGCTRL:trace] vfo_fixup:(from rig_get_freq:2458) vfo=VFOA, vfo_curr=VFOA, split=0
[2025-04-17 16:32:23.578614][00:00:02.941112][RIGCTRL:trace] vfo_fixup: final vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941115][RIGCTRL:debug] rig.c(2460) vfo=VFOA, curr_vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941128][RIGCTRL:trace] rig_get_freq: cache miss age=1000000ms, cached_vfo=VFOA, asked_vfo=VFOA, use_cached_freq=0
[2025-04-17 16:32:23.578614][00:00:02.941133][RIGCTRL:debug] rig_get_freq(2574): vfo_opt=0, model=8
[2025-04-17 16:32:23.578614][00:00:02.941137][RIGCTRL:debug] ***3:aclog.c(430):aclog_get_freq entered
[2025-04-17 16:32:23.578614][00:00:02.941140][RIGCTRL:trace] aclog_get_freq: vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941145][RIGCTRL:debug] ****4:aclog.c(256):aclog_transaction entered
[2025-04-17 16:32:23.578614][00:00:02.941148][RIGCTRL:debug] *****5:aclog.c(223):write_transaction entered
[2025-04-17 16:32:23.578614][00:00:02.941151][RIGCTRL:debug] network_flush called
[2025-04-17 16:32:23.578614][00:00:02.941190][RIGCTRL:trace] write_block(): TX 22 bytes
[2025-04-17 16:32:23.578614][00:00:02.941195][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 3e 3c 2f <CMD><READBMF></
[2025-04-17 16:32:23.578614][00:00:02.941198][RIGCTRL:trace] 0010 43 4d 44 3e 0d 0a CMD>..
[2025-04-17 16:32:23.578614][00:00:02.941203][RIGCTRL:debug] *****5:aclog.c(247):write_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941206][RIGCTRL:debug] *****5:aclog.c(141):read_transaction entered
[2025-04-17 16:32:23.578614][00:00:02.941618][RIGCTRL:trace] read_string_generic(): RX 109 characters, direct=1
[2025-04-17 16:32:23.578614][00:00:02.941633][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 52 45 53 <CMD><READBMFRES
[2025-04-17 16:32:23.578614][00:00:02.941637][RIGCTRL:trace] 0010 50 4f 4e 53 45 3e 3c 42 41 4e 44 3e 32 33 3c 2f PONSE><BAND>23</
[2025-04-17 16:32:23.578614][00:00:02.941640][RIGCTRL:trace] 0020 42 41 4e 44 3e 3c 4d 4f 44 45 3e 53 53 42 3c 2f BAND><MODE>SSB</
[2025-04-17 16:32:23.578614][00:00:02.941643][RIGCTRL:trace] 0030 4d 4f 44 45 3e 3c 4d 4f 44 45 54 45 53 54 3e 50 MODE><MODETEST>P
[2025-04-17 16:32:23.578614][00:00:02.941646][RIGCTRL:trace] 0040 48 3c 2f 4d 4f 44 45 54 45 53 54 3e 3c 46 52 45 H</MODETEST><FRE
[2025-04-17 16:32:23.578614][00:00:02.941649][RIGCTRL:trace] 0050 51 3e 31 2c 32 39 36 2e 31 37 31 31 30 30 3c 2f Q>1,296.171100</
[2025-04-17 16:32:23.578614][00:00:02.941662][RIGCTRL:trace] 0060 46 52 45 51 3e 3c 2f 43 4d 44 3e 0d 0a FREQ></CMD>..
[2025-04-17 16:32:23.578614][00:00:02.941668][RIGCTRL:trace] read_transaction: string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD>
'
[2025-04-17 16:32:23.578614][00:00:02.941673][RIGCTRL:trace] read_transaction: got </CMD>
[2025-04-17 16:32:23.578614][00:00:02.941679][RIGCTRL:debug] *****5:aclog.c(208):read_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941685][RIGCTRL:debug] ****4:aclog_transaction: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.941689][RIGCTRL:debug] ****4:aclog.c(311):aclog_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941698][RIGCTRL:trace] aclog_get_freq: freq=1000000
[2025-04-17 16:32:23.578614][00:00:02.941703][RIGCTRL:debug] ***3:aclog.c(488):aclog_get_freq returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941720][RIGCTRL:debug] rig_get_band called
[2025-04-17 16:32:23.578614][00:00:02.941730][RIGCTRL:debug] rig_get_freq: band changing to BANDGEN
[2025-04-17 16:32:23.578614][00:00:02.941737][RIGCTRL:debug] **2:rig_get_freq: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.941742][RIGCTRL:debug] **2:rig.c(2711):rig_get_freq returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941746][RIGCTRL:debug] **2:rig.c(2433):rig_get_freq entered
[2025-04-17 16:32:23.578614][00:00:02.941750][RIGCTRL:debug] rig_get_freq called vfo=VFOB
[2025-04-17 16:32:23.578614][00:00:02.941754][RIGCTRL:debug] rig_get_freq(2451) called vfo=VFOB
[2025-04-17 16:32:23.578614][00:00:02.941761][RIGCTRL:trace] vfo_fixup:(from rig_get_freq:2458) vfo=VFOB, vfo_curr=VFOA, split=0
[2025-04-17 16:32:23.578614][00:00:02.941764][RIGCTRL:trace] vfo_fixup: final vfo=VFOB
[2025-04-17 16:32:23.578614][00:00:02.941768][RIGCTRL:debug] rig.c(2460) vfo=VFOB, curr_vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941780][RIGCTRL:trace] rig_get_freq: cache miss age=1000000ms, cached_vfo=VFOB, asked_vfo=VFOB, use_cached_freq=0
[2025-04-17 16:32:23.578614][00:00:02.941788][RIGCTRL:debug] rig_get_freq(2574): vfo_opt=0, model=8
[2025-04-17 16:32:23.578614][00:00:02.941792][RIGCTRL:debug] **2:rig_get_freq: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.941796][RIGCTRL:debug] **2:rig.c(2618):rig_get_freq returning(-11) Feature not available
[2025-04-17 16:32:23.578614][00:00:02.941801][RIGCTRL:debug] **2:rig.c(5929):rig_get_split_vfo entered
[2025-04-17 16:32:23.578614][00:00:02.941806][RIGCTRL:trace] rig_get_split_vfo: ?get_split_vfo=0 use_cache=0
[2025-04-17 16:32:23.578614][00:00:02.941809][RIGCTRL:debug] **2:rig_get_split_vfo: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.941812][RIGCTRL:debug] **2:rig.c(5956):rig_get_split_vfo returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941815][RIGCTRL:debug] rig_open(1564): Current split=0, tx_vfo=None
[2025-04-17 16:32:23.578614][00:00:02.941820][RIGCTRL:debug] **2:rig.c(2976):rig_get_mode entered
[2025-04-17 16:32:23.578614][00:00:02.941824][RIGCTRL:trace] vfo_fixup:(from rig_get_mode:2995) vfo=VFOA, vfo_curr=VFOA, split=0
[2025-04-17 16:32:23.578614][00:00:02.941827][RIGCTRL:trace] vfo_fixup: final vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941838][RIGCTRL:trace] rig_get_mode: VFOA cache check age=0ms
[2025-04-17 16:32:23.578614][00:00:02.941844][RIGCTRL:trace] rig_get_mode: cache miss age mode=0ms, width=0ms
[2025-04-17 16:32:23.578614][00:00:02.941848][RIGCTRL:trace] **rig.c(3045) trace
[2025-04-17 16:32:23.578614][00:00:02.941853][RIGCTRL:debug] ***3:aclog.c(502):aclog_get_mode entered
[2025-04-17 16:32:23.578614][00:00:02.941856][RIGCTRL:trace] aclog_get_mode: vfo=VFOA
[2025-04-17 16:32:23.578614][00:00:02.941860][RIGCTRL:debug] ****4:aclog.c(256):aclog_transaction entered
[2025-04-17 16:32:23.578614][00:00:02.941864][RIGCTRL:debug] *****5:aclog.c(223):write_transaction entered
[2025-04-17 16:32:23.578614][00:00:02.941867][RIGCTRL:debug] network_flush called
[2025-04-17 16:32:23.578614][00:00:02.941917][RIGCTRL:trace] write_block(): TX 22 bytes
[2025-04-17 16:32:23.578614][00:00:02.941924][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 3e 3c 2f <CMD><READBMF></
[2025-04-17 16:32:23.578614][00:00:02.941927][RIGCTRL:trace] 0010 43 4d 44 3e 0d 0a CMD>..
[2025-04-17 16:32:23.578614][00:00:02.941931][RIGCTRL:debug] *****5:aclog.c(247):write_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.941934][RIGCTRL:debug] *****5:aclog.c(141):read_transaction entered
[2025-04-17 16:32:23.578614][00:00:02.942350][RIGCTRL:trace] read_string_generic(): RX 109 characters, direct=1
[2025-04-17 16:32:23.578614][00:00:02.942365][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 52 45 53 <CMD><READBMFRES
[2025-04-17 16:32:23.578614][00:00:02.942369][RIGCTRL:trace] 0010 50 4f 4e 53 45 3e 3c 42 41 4e 44 3e 32 33 3c 2f PONSE><BAND>23</
[2025-04-17 16:32:23.578614][00:00:02.942372][RIGCTRL:trace] 0020 42 41 4e 44 3e 3c 4d 4f 44 45 3e 53 53 42 3c 2f BAND><MODE>SSB</
[2025-04-17 16:32:23.578614][00:00:02.942375][RIGCTRL:trace] 0030 4d 4f 44 45 3e 3c 4d 4f 44 45 54 45 53 54 3e 50 MODE><MODETEST>P
[2025-04-17 16:32:23.578614][00:00:02.942378][RIGCTRL:trace] 0040 48 3c 2f 4d 4f 44 45 54 45 53 54 3e 3c 46 52 45 H</MODETEST><FRE
[2025-04-17 16:32:23.578614][00:00:02.942383][RIGCTRL:trace] 0050 51 3e 31 2c 32 39 36 2e 31 37 31 31 30 30 3c 2f Q>1,296.171100</
[2025-04-17 16:32:23.578614][00:00:02.942390][RIGCTRL:trace] 0060 46 52 45 51 3e 3c 2f 43 4d 44 3e 0d 0a FREQ></CMD>..
[2025-04-17 16:32:23.578614][00:00:02.942396][RIGCTRL:trace] read_transaction: string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD>
'
[2025-04-17 16:32:23.578614][00:00:02.942401][RIGCTRL:trace] read_transaction: got </CMD>
[2025-04-17 16:32:23.578614][00:00:02.942406][RIGCTRL:debug] *****5:aclog.c(208):read_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.942412][RIGCTRL:debug] ****4:aclog_transaction: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.942416][RIGCTRL:debug] ****4:aclog.c(311):aclog_transaction returning(0)
[2025-04-17 16:32:23.578614][00:00:02.942427][RIGCTRL:trace] modeMapGetHamlib: find '|SSB|' in '|USB|'
[2025-04-17 16:32:23.578614][00:00:02.942431][RIGCTRL:trace] modeMapGetHamlib: find '|SSB|' in '|SSB|'
[2025-04-17 16:32:23.578614][00:00:02.942434][RIGCTRL:trace] aclog_get_mode: mode='USB'
[2025-04-17 16:32:23.578614][00:00:02.942438][RIGCTRL:debug] ***3:aclog.c(556):aclog_get_mode returning(0)
[2025-04-17 16:32:23.578614][00:00:02.942443][RIGCTRL:trace] rig_get_mode: retcode after get_mode=0
[2025-04-17 16:32:23.578614][00:00:02.942449][RIGCTRL:trace] rig_get_mode(3091): debug
[2025-04-17 16:32:23.578614][00:00:02.942454][RIGCTRL:debug] ***3:cache.c(40):rig_set_cache_mode entered
[2025-04-17 16:32:23.578614][00:00:02.942464][RIGCTRL:debug] ***3:cache.c(156):rig_set_cache_mode returning(0)
[2025-04-17 16:32:23.578614][00:00:02.942470][RIGCTRL:debug] **2:rig_get_mode: elapsed=0ms
[2025-04-17 16:32:23.578614][00:00:02.942475][RIGCTRL:debug] **2:rig.c(3108):rig_get_mode returning(0)
[2025-04-17 16:32:23.578614][00:00:02.942479][RIGCTRL:debug] network_flush called
[2025-04-17 16:32:23.578614][00:00:02.942486][RIGCTRL:debug] **2:network.c(1589):network_multicast_publisher_start entered
[2025-04-17 16:32:23.578614][00:00:02.942490][RIGCTRL:debug] network.c(1598): multicast publisher address=0.0.0.0, port=4532
[2025-04-17 16:32:23.585489][00:00:02.950811][RIGCTRL:debug] is_networked: network IfType = 6, name=Ethernet
[2025-04-17 16:32:23.585489][00:00:02.950836][RIGCTRL:debug] 192.168.2.65: Address: 192.168.2.65
[2025-04-17 16:32:23.585489][00:00:02.950843][RIGCTRL:trace] network.c(1616): not starting multicast publisher
[2025-04-17 16:32:23.585489][00:00:02.950850][RIGCTRL:debug] **2:network.c(1618):network_multicast_publisher_start returning(0)
[2025-04-17 16:32:23.585489][00:00:02.950861][RIGCTRL:debug] **2:network.c(1800):network_multicast_receiver_start entered
[2025-04-17 16:32:23.585489][00:00:02.950865][RIGCTRL:debug] network.c(1810): multicast receiver address=0.0.0.0, port=4532
[2025-04-17 16:32:23.585489][00:00:02.950869][RIGCTRL:trace] network.c(1817): not starting multicast receiver
[2025-04-17 16:32:23.585489][00:00:02.950878][RIGCTRL:debug] **2:network.c(1819):network_multicast_receiver_start returning(0)
[2025-04-17 16:32:23.585489][00:00:02.950882][RIGCTRL:debug] **2:event.c(272):rig_poll_routine_start entered
[2025-04-17 16:32:23.585489][00:00:02.950948][RIGCTRL:debug] **2:event.c(312):rig_poll_routine_start returning(0)
[2025-04-17 16:32:23.585489][00:00:02.950955][RIGCTRL:debug] rig.c(288):add_opened_rig entered
[2025-04-17 16:32:23.585489][00:00:02.950960][RIGCTRL:debug] rig.c(300):add_opened_rig returning2(0)
[2025-04-17 16:32:23.585489][00:00:02.950964][RIGCTRL:debug] rig.c(1641):rig_open returning2(0)
[2025-04-17 16:32:23.585489][00:00:02.950970][RIGCTRL:debug] **2:rig.c(3449):rig_get_vfo entered
[2025-04-17 16:32:23.585489][00:00:02.950974][RIGCTRL:trace] rig_get_vfo: cache hit age=6ms, vfo=VFOA
[2025-04-17 16:32:23.585489][00:00:02.950981][RIGCTRL:debug] **2:rig_get_vfo: elapsed=0ms
[2025-04-17 16:32:23.585489][00:00:02.950985][RIGCTRL:debug] **2:rig.c(3478):rig_get_vfo returning(0)
[2025-04-17 16:32:23.585489][00:00:02.950991][RIGCTRL:debug] **2:rig.c(2433):rig_get_freq entered
[2025-04-17 16:32:23.585489][00:00:02.950995][RIGCTRL:debug] rig_get_freq called vfo=currVFO
[2025-04-17 16:32:23.585489][00:00:02.950999][RIGCTRL:debug] rig_get_freq(2451) called vfo=currVFO
[2025-04-17 16:32:23.585489][00:00:02.951008][RIGCTRL:trace] vfo_fixup:(from rig_get_freq:2458) vfo=currVFO, vfo_curr=VFOA, split=0
[2025-04-17 16:32:23.585489][00:00:02.951011][RIGCTRL:trace] vfo_fixup: Leaving currVFO alone
[2025-04-17 16:32:23.585489][00:00:02.951014][RIGCTRL:debug] rig.c(2460) vfo=currVFO, curr_vfo=VFOA
[2025-04-17 16:32:23.585489][00:00:02.951027][RIGCTRL:trace] rig_get_freq: VFOA cache hit age=6ms, freq=1000000, use_cached_freq=0
[2025-04-17 16:32:23.585489][00:00:02.951031][RIGCTRL:debug] **2:rig_get_freq: elapsed=0ms
[2025-04-17 16:32:23.585489][00:00:02.951034][RIGCTRL:debug] **2:rig.c(2554):rig_get_freq returning(0)
[2025-04-17 16:32:23.585489][00:00:02.951044][RIGCTRL:debug] rig_get_band called
[2025-04-17 16:32:23.585489][00:00:02.951048][RIGCTRL:debug] **2:rig.c(2102):rig_set_freq entered
[2025-04-17 16:32:23.585489][00:00:02.951052][RIGCTRL:debug] rig_set_freq called vfo=currVFO, freq=1000055
[2025-04-17 16:32:23.585489][00:00:02.951057][RIGCTRL:trace] vfo_fixup:(from rig_set_freq:2179) vfo=currVFO, vfo_curr=VFOA, split=0
[2025-04-17 16:32:23.585489][00:00:02.951060][RIGCTRL:trace] vfo_fixup: Leaving currVFO alone
[2025-04-17 16:32:23.585489][00:00:02.951063][RIGCTRL:debug] skip_freq: not skipping set_freq on vfo VFOA
[2025-04-17 16:32:23.585489][00:00:02.951066][RIGCTRL:trace] rig_set_freq: TARGETABLE_FREQ vfo=VFOA
[2025-04-17 16:32:23.585489][00:00:02.951069][RIGCTRL:trace] aclog_set_freq
[2025-04-17 16:32:23.585489][00:00:02.951073][RIGCTRL:trace] aclog_set_freq: vfo=VFOA freq=1000055
[2025-04-17 16:32:23.585489][00:00:02.951079][RIGCTRL:debug] ***3:aclog.c(256):aclog_transaction entered
[2025-04-17 16:32:23.585489][00:00:02.951084][RIGCTRL:debug] ****4:aclog.c(223):write_transaction entered
[2025-04-17 16:32:23.585489][00:00:02.951087][RIGCTRL:debug] network_flush called
[2025-04-17 16:32:23.585489][00:00:02.951142][RIGCTRL:debug] event.c(85): Starting rig poll routine thread
[2025-04-17 16:32:23.585489][00:00:02.951182][RIGCTRL:trace] write_block(): TX 95 bytes
[2025-04-17 16:32:23.585489][00:00:02.951193][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 43 48 41 4e 47 45 46 52 45 51 <CMD><CHANGEFREQ
[2025-04-17 16:32:23.585489][00:00:02.951197][RIGCTRL:trace] 0010 3e 3c 56 41 4c 55 45 3e 31 2e 30 30 30 30 35 35 ><VALUE>1.000055
[2025-04-17 16:32:23.585489][00:00:02.951212][RIGCTRL:trace] rig_set_cache_timeout_ms: called selection=0, ms=1000
[2025-04-17 16:32:23.585489][00:00:02.951230][RIGCTRL:trace] 0020 3c 2f 56 41 4c 55 45 3e 3c 53 55 50 50 52 45 53 </VALUE><SUPPRES
[2025-04-17 16:32:23.585489][00:00:02.951238][RIGCTRL:trace] 0030 53 4d 4f 44 45 44 45 46 41 55 4c 54 3e 54 52 55 SMODEDEFAULT>TRU
[2025-04-17 16:32:23.585489][00:00:02.951242][RIGCTRL:trace] 0040 45 3c 2f 53 55 50 50 52 45 53 53 4d 4f 44 45 44 E</SUPPRESSMODED
[2025-04-17 16:32:23.585489][00:00:02.951246][RIGCTRL:trace] 0050 45 46 41 55 4c 54 3e 3c 2f 43 4d 44 3e 0d 0a EFAULT></CMD>..
[2025-04-17 16:32:23.585489][00:00:02.951252][RIGCTRL:debug] ****4:aclog.c(247):write_transaction returning(0)
[2025-04-17 16:32:23.585489][00:00:02.951256][RIGCTRL:debug] ****4:aclog.c(141):read_transaction entered
[2025-04-17 16:32:23.585489][00:00:02.951652][RIGCTRL:trace] read_string_generic(): RX 56 characters, direct=1
[2025-04-17 16:32:23.585489][00:00:02.951668][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 43 48 41 4e 47 45 46 52 45 51 <CMD><CHANGEFREQ
[2025-04-17 16:32:23.585489][00:00:02.951673][RIGCTRL:trace] 0010 52 45 53 50 4f 4e 53 45 3e 3c 56 41 4c 55 45 3e RESPONSE><VALUE>
[2025-04-17 16:32:23.585489][00:00:02.951677][RIGCTRL:trace] 0020 31 2e 30 30 30 30 35 35 3c 2f 56 41 4c 55 45 3e 1.000055</VALUE>
[2025-04-17 16:32:23.585489][00:00:02.951681][RIGCTRL:trace] 0030 3c 2f 43 4d 44 3e 0d 0a </CMD>..
[2025-04-17 16:32:23.585489][00:00:02.951686][RIGCTRL:trace] read_transaction: string='<CMD><CHANGEFREQRESPONSE><VALUE>1.000055</VALUE></CMD>
'
|
|
From: Andy D. <a.d...@ms...> - 2025-04-19 16:53:07
|
"2.8.0 improved, when used with OnmiRig, does not control rig frequency when Mode = None. It does control rig frequency when Mode = USB." A bit more experimenting with 2.8.0. showed MODE=USB was a necessary but not sufficient condition. Rig control only seemed to work if Split operation was changed too. E.g. Start with Mode None, Split Rig - frequency control inop Set Mode USB - frequency control inop Set Split Fake it - Rig RX VFO responds. TX VFO unchanged Set Split Rig - Frequency control ok Set Mode none - Frequency control inop Set Mode USB - Frequency control inop Set Split none - Rig RX VFO responds. TX VFO unchanged Set Split Rig - frequency control ok This is only part of the problem. The fact that the WSJT-X dial frequency does change means the WSJT-X frequency display is not always rig dial frequency but is sometimes the commanded dial frequency. Shouldn't WSJT-X dial frequency always be the frequency reported by the rig and have some alert if rig frequency is not equal to commanded frequency? 73, Andy, k3wyc |
|
From: David O. <djm...@gm...> - 2025-04-19 09:31:18
|
Hi I had a very similar problem with my R8600. I did try to find the cause but gave up trying a debugging version of Hamlib. Versions of Hamlib before July 2024 work OK and I don't think there are any features lost as far as the R8600 is concerned. Regards David Owen GM1OXB On Thu, Apr 17, 2025 at 6:59 PM Christopher Smith via wsjt-devel <wsj...@li...> wrote: > > When upgrading to version 2.7.0 I can no longer control my Icom R8600. It was working with earlier versions (2.6.1). > > I am running Windows 10 Pro. > > The program starts and shows the current radio frequency. (This seems to be the case whether I start the program with the radio in the VFO mode or memory mode - it has never mattered before.) > > When I use the frequency drop down box the frequency does not change. When I try again I get a Rig Control Error box with details: > > > Hamlib error: > > icom.c(9652):set_vfo_curr returning2(-9) Command rejected by the rig > > > > icom.c(1595):icom_set_freq returning2(-9) Command rejected by the rig > > > > rig_set_cache_freq(171): vfo=VFOA, current_vfo=currVFO > > rig_set_freq: vfo=VFOA, save=currVFO > > *rig.c(2410) trace > > **2:rig.c(3333):rig_set_vfo entered > > rig_set_vfo called vfo=currVFO > > vfo_fixup:(from rig_set_vfo:3347) vfo=currVFO, vfo_curr=currVFO, split=0 > > vfo_fixup: Leaving currVFO alone > > **2:rig_set_vfo: elapsed=0ms > > **2:rig.c(3352):rig_set_vfo returning(0) > > *1:rig_set_freq: elapsed=31ms > > rig_lock: client lock disengaged > > *1:rig.c(2416):rig_set_freq returning(-9) Command rejected by the rig > > > > Command rejected by the rig > > Command rejected by the rig > > while setting frequency > > > > Timestamp: 2025-04-15T16:31:36.050Z > > When reverting to the previous hamlib version, but still running WSJT-X version 2.7.0 I have the same problem. > > I might note the current FLDIGI embedded hamlib version works, to a point. I can always set the frequency from the radio, but when I vary the frequency from the radio, FLDIGI only follows it for a few changes, then the display (on the program, not the radio) locks up. > > 73, > > Chris NX0E > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Mike L. <k7...@ho...> - 2025-04-17 17:57:21
|
I am using N3FJP AC Log which has rig control. I set up various versions (2.7.0 and 2.8.0_improved) of WSJT-X to use the N3FJP AC Log rig definition. Radios tested are IC-905, IC-705 (with a transverter aware band decoder) and Elecraft K3. The later 2 have transverters on 903 and 1296 and they report the transverter's frequency over CAT. Focusing on just the K3 or IC-905, when any band below 1GHz is selected, all works as it should, with or without WSJT-X running. Change bands by any means (radio or WSJTX) to any band higher than 903, WSJT-X reads the frequency as only the 1GHz digit times 1,000,000. For example. 1296 results in 1.000,000Hz. 2304.100.000 results in 2.000MHz 5760.1 results in 5.000MHz After WSJTZX now think the frequency is 1.000Mhz (for 1296) it thinks a band change occurredon the WSJT-X side and sends 1.0MHz to AC Log where it is updated and AC Log in turn changes the radio to 1.000Mhz. I turned on WSJT_X Rig Control logging and got a narrowed log that I think shows the problem is in the WSJT-X hamlib code. I tried WSJT-X V2.8.0_improved today, same issue with frequencies above >999Mhz. In this attached log, I have the K3 set to 1296.171.100. AC Log is controlling the rig. All is good so far. I then start up WSJT-X. It queries AC Log for freq and gets 1296. Has correct band (23) and mode (SSB). string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD> The next thing is it extracts the frequency from the message wrong [2025-04-17 16:32:23.578614][00:00:02.941014][RIGCTRL:trace] aclog_get_freq: freq=1000000 Now WSJTX thinks it is 1.000MHz. It polls AC Log a bit more, it still gets 1296 as proper. Then it decided the frequency has changed and sends 1.000MHz to AC Log. Now AC log says 1.000055MHz. [2025-04-17 16:32:23.585489][00:00:02.951073][RIGCTRL:trace] aclog_set_freq: vfo=VFOA freq=1000055 [2025-04-17 16:32:23.585489][00:00:02.951193][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 43 48 41 4e 47 45 46 52 45 51 <CMD><CHANGEFREQ [2025-04-17 16:32:23.585489][00:00:02.951197][RIGCTRL:trace] 0010 3e 3c 56 41 4c 55 45 3e 31 2e 30 30 30 30 35 35 ><VALUE>1.000055 On the K3 I see 1.000.055 on the dial, then it immediately changes to 1.000.000. No idea why, step size is 10Hz on the radio. A log excerpt is pasted below, a full log attached if not stripped. Shutdown WSJT-X and AC Log frequency stays at 1.000.000. 73, Mike Lewis, K7MDL CN87xs __________________________ [2025-04-17 16:32:23.578614][00:00:02.940480][RIGCTRL:debug] network_flush called [2025-04-17 16:32:23.578614][00:00:02.940574][RIGCTRL:trace] write_block(): TX 22 bytes [2025-04-17 16:32:23.578614][00:00:02.940579][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 3e 3c 2f <CMD><READBMF></ [2025-04-17 16:32:23.578614][00:00:02.940583][RIGCTRL:trace] 0010 43 4d 44 3e 0d 0a CMD>.. [2025-04-17 16:32:23.578614][00:00:02.940588][RIGCTRL:debug] *****5:aclog.c(247):write_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.940592][RIGCTRL:debug] *****5:aclog.c(141):read_transaction entered [2025-04-17 16:32:23.578614][00:00:02.940923][RIGCTRL:trace] read_string_generic(): RX 109 characters, direct=1 [2025-04-17 16:32:23.578614][00:00:02.940948][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 52 45 53 <CMD><READBMFRES [2025-04-17 16:32:23.578614][00:00:02.940953][RIGCTRL:trace] 0010 50 4f 4e 53 45 3e 3c 42 41 4e 44 3e 32 33 3c 2f PONSE><BAND>23</ [2025-04-17 16:32:23.578614][00:00:02.940957][RIGCTRL:trace] 0020 42 41 4e 44 3e 3c 4d 4f 44 45 3e 53 53 42 3c 2f BAND><MODE>SSB</ [2025-04-17 16:32:23.578614][00:00:02.940960][RIGCTRL:trace] 0030 4d 4f 44 45 3e 3c 4d 4f 44 45 54 45 53 54 3e 50 MODE><MODETEST>P [2025-04-17 16:32:23.578614][00:00:02.940963][RIGCTRL:trace] 0040 48 3c 2f 4d 4f 44 45 54 45 53 54 3e 3c 46 52 45 H</MODETEST><FRE [2025-04-17 16:32:23.578614][00:00:02.940967][RIGCTRL:trace] 0050 51 3e 31 2c 32 39 36 2e 31 37 31 31 30 30 3c 2f Q>1,296.171100</ [2025-04-17 16:32:23.578614][00:00:02.940970][RIGCTRL:trace] 0060 46 52 45 51 3e 3c 2f 43 4d 44 3e 0d 0a FREQ></CMD>.. [2025-04-17 16:32:23.578614][00:00:02.940975][RIGCTRL:trace] read_transaction: string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD> ' [2025-04-17 16:32:23.578614][00:00:02.940983][RIGCTRL:trace] read_transaction: got </CMD> [2025-04-17 16:32:23.578614][00:00:02.940989][RIGCTRL:debug] *****5:aclog.c(208):read_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.940995][RIGCTRL:debug] ****4:aclog_transaction: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.941001][RIGCTRL:debug] ****4:aclog.c(311):aclog_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.941014][RIGCTRL:trace] aclog_get_freq: freq=1000000 [2025-04-17 16:32:23.578614][00:00:02.941022][RIGCTRL:debug] ***3:aclog.c(488):aclog_get_freq returning(0) [2025-04-17 16:32:23.578614][00:00:02.941028][RIGCTRL:trace] aclog_open: currvfo=VFOA value=<CMD><RIGRESPONSE><RIG>Elecraft</RIG><RIGINDEX>0</RIGINDEX></CMD> [2025-04-17 16:32:23.578614][00:00:02.941034][RIGCTRL:debug] **2:aclog.c(627):aclog_open returning(0) [2025-04-17 16:32:23.578614][00:00:02.941047][RIGCTRL:debug] **2:rig.c(3449):rig_get_vfo entered [2025-04-17 16:32:23.578614][00:00:02.941051][RIGCTRL:trace] rig_get_vfo: cache miss age=1000000ms [2025-04-17 16:32:23.578614][00:00:02.941055][RIGCTRL:trace] **rig.c(3485) trace [2025-04-17 16:32:23.578614][00:00:02.941060][RIGCTRL:debug] ***3:aclog.c(850):aclog_get_vfo entered [2025-04-17 16:32:23.578614][00:00:02.941065][RIGCTRL:debug] ***3:aclog.c(854):aclog_get_vfo returning(0) [2025-04-17 16:32:23.578614][00:00:02.941069][RIGCTRL:debug] **2:rig_get_vfo: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.941074][RIGCTRL:debug] **2:rig.c(3519):rig_get_vfo returning(0) [2025-04-17 16:32:23.578614][00:00:02.941087][RIGCTRL:debug] **2:rig.c(2433):rig_get_freq entered [2025-04-17 16:32:23.578614][00:00:02.941092][RIGCTRL:debug] rig_get_freq called vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941097][RIGCTRL:debug] rig_get_freq(2451) called vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941109][RIGCTRL:trace] vfo_fixup:(from rig_get_freq:2458) vfo=VFOA, vfo_curr=VFOA, split=0 [2025-04-17 16:32:23.578614][00:00:02.941112][RIGCTRL:trace] vfo_fixup: final vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941115][RIGCTRL:debug] rig.c(2460) vfo=VFOA, curr_vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941128][RIGCTRL:trace] rig_get_freq: cache miss age=1000000ms, cached_vfo=VFOA, asked_vfo=VFOA, use_cached_freq=0 [2025-04-17 16:32:23.578614][00:00:02.941133][RIGCTRL:debug] rig_get_freq(2574): vfo_opt=0, model=8 [2025-04-17 16:32:23.578614][00:00:02.941137][RIGCTRL:debug] ***3:aclog.c(430):aclog_get_freq entered [2025-04-17 16:32:23.578614][00:00:02.941140][RIGCTRL:trace] aclog_get_freq: vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941145][RIGCTRL:debug] ****4:aclog.c(256):aclog_transaction entered [2025-04-17 16:32:23.578614][00:00:02.941148][RIGCTRL:debug] *****5:aclog.c(223):write_transaction entered [2025-04-17 16:32:23.578614][00:00:02.941151][RIGCTRL:debug] network_flush called [2025-04-17 16:32:23.578614][00:00:02.941190][RIGCTRL:trace] write_block(): TX 22 bytes [2025-04-17 16:32:23.578614][00:00:02.941195][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 3e 3c 2f <CMD><READBMF></ [2025-04-17 16:32:23.578614][00:00:02.941198][RIGCTRL:trace] 0010 43 4d 44 3e 0d 0a CMD>.. [2025-04-17 16:32:23.578614][00:00:02.941203][RIGCTRL:debug] *****5:aclog.c(247):write_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.941206][RIGCTRL:debug] *****5:aclog.c(141):read_transaction entered [2025-04-17 16:32:23.578614][00:00:02.941618][RIGCTRL:trace] read_string_generic(): RX 109 characters, direct=1 [2025-04-17 16:32:23.578614][00:00:02.941633][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 52 45 53 <CMD><READBMFRES [2025-04-17 16:32:23.578614][00:00:02.941637][RIGCTRL:trace] 0010 50 4f 4e 53 45 3e 3c 42 41 4e 44 3e 32 33 3c 2f PONSE><BAND>23</ [2025-04-17 16:32:23.578614][00:00:02.941640][RIGCTRL:trace] 0020 42 41 4e 44 3e 3c 4d 4f 44 45 3e 53 53 42 3c 2f BAND><MODE>SSB</ [2025-04-17 16:32:23.578614][00:00:02.941643][RIGCTRL:trace] 0030 4d 4f 44 45 3e 3c 4d 4f 44 45 54 45 53 54 3e 50 MODE><MODETEST>P [2025-04-17 16:32:23.578614][00:00:02.941646][RIGCTRL:trace] 0040 48 3c 2f 4d 4f 44 45 54 45 53 54 3e 3c 46 52 45 H</MODETEST><FRE [2025-04-17 16:32:23.578614][00:00:02.941649][RIGCTRL:trace] 0050 51 3e 31 2c 32 39 36 2e 31 37 31 31 30 30 3c 2f Q>1,296.171100</ [2025-04-17 16:32:23.578614][00:00:02.941662][RIGCTRL:trace] 0060 46 52 45 51 3e 3c 2f 43 4d 44 3e 0d 0a FREQ></CMD>.. [2025-04-17 16:32:23.578614][00:00:02.941668][RIGCTRL:trace] read_transaction: string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD> ' [2025-04-17 16:32:23.578614][00:00:02.941673][RIGCTRL:trace] read_transaction: got </CMD> [2025-04-17 16:32:23.578614][00:00:02.941679][RIGCTRL:debug] *****5:aclog.c(208):read_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.941685][RIGCTRL:debug] ****4:aclog_transaction: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.941689][RIGCTRL:debug] ****4:aclog.c(311):aclog_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.941698][RIGCTRL:trace] aclog_get_freq: freq=1000000 [2025-04-17 16:32:23.578614][00:00:02.941703][RIGCTRL:debug] ***3:aclog.c(488):aclog_get_freq returning(0) [2025-04-17 16:32:23.578614][00:00:02.941720][RIGCTRL:debug] rig_get_band called [2025-04-17 16:32:23.578614][00:00:02.941730][RIGCTRL:debug] rig_get_freq: band changing to BANDGEN [2025-04-17 16:32:23.578614][00:00:02.941737][RIGCTRL:debug] **2:rig_get_freq: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.941742][RIGCTRL:debug] **2:rig.c(2711):rig_get_freq returning(0) [2025-04-17 16:32:23.578614][00:00:02.941746][RIGCTRL:debug] **2:rig.c(2433):rig_get_freq entered [2025-04-17 16:32:23.578614][00:00:02.941750][RIGCTRL:debug] rig_get_freq called vfo=VFOB [2025-04-17 16:32:23.578614][00:00:02.941754][RIGCTRL:debug] rig_get_freq(2451) called vfo=VFOB [2025-04-17 16:32:23.578614][00:00:02.941761][RIGCTRL:trace] vfo_fixup:(from rig_get_freq:2458) vfo=VFOB, vfo_curr=VFOA, split=0 [2025-04-17 16:32:23.578614][00:00:02.941764][RIGCTRL:trace] vfo_fixup: final vfo=VFOB [2025-04-17 16:32:23.578614][00:00:02.941768][RIGCTRL:debug] rig.c(2460) vfo=VFOB, curr_vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941780][RIGCTRL:trace] rig_get_freq: cache miss age=1000000ms, cached_vfo=VFOB, asked_vfo=VFOB, use_cached_freq=0 [2025-04-17 16:32:23.578614][00:00:02.941788][RIGCTRL:debug] rig_get_freq(2574): vfo_opt=0, model=8 [2025-04-17 16:32:23.578614][00:00:02.941792][RIGCTRL:debug] **2:rig_get_freq: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.941796][RIGCTRL:debug] **2:rig.c(2618):rig_get_freq returning(-11) Feature not available [2025-04-17 16:32:23.578614][00:00:02.941801][RIGCTRL:debug] **2:rig.c(5929):rig_get_split_vfo entered [2025-04-17 16:32:23.578614][00:00:02.941806][RIGCTRL:trace] rig_get_split_vfo: ?get_split_vfo=0 use_cache=0 [2025-04-17 16:32:23.578614][00:00:02.941809][RIGCTRL:debug] **2:rig_get_split_vfo: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.941812][RIGCTRL:debug] **2:rig.c(5956):rig_get_split_vfo returning(0) [2025-04-17 16:32:23.578614][00:00:02.941815][RIGCTRL:debug] rig_open(1564): Current split=0, tx_vfo=None [2025-04-17 16:32:23.578614][00:00:02.941820][RIGCTRL:debug] **2:rig.c(2976):rig_get_mode entered [2025-04-17 16:32:23.578614][00:00:02.941824][RIGCTRL:trace] vfo_fixup:(from rig_get_mode:2995) vfo=VFOA, vfo_curr=VFOA, split=0 [2025-04-17 16:32:23.578614][00:00:02.941827][RIGCTRL:trace] vfo_fixup: final vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941838][RIGCTRL:trace] rig_get_mode: VFOA cache check age=0ms [2025-04-17 16:32:23.578614][00:00:02.941844][RIGCTRL:trace] rig_get_mode: cache miss age mode=0ms, width=0ms [2025-04-17 16:32:23.578614][00:00:02.941848][RIGCTRL:trace] **rig.c(3045) trace [2025-04-17 16:32:23.578614][00:00:02.941853][RIGCTRL:debug] ***3:aclog.c(502):aclog_get_mode entered [2025-04-17 16:32:23.578614][00:00:02.941856][RIGCTRL:trace] aclog_get_mode: vfo=VFOA [2025-04-17 16:32:23.578614][00:00:02.941860][RIGCTRL:debug] ****4:aclog.c(256):aclog_transaction entered [2025-04-17 16:32:23.578614][00:00:02.941864][RIGCTRL:debug] *****5:aclog.c(223):write_transaction entered [2025-04-17 16:32:23.578614][00:00:02.941867][RIGCTRL:debug] network_flush called [2025-04-17 16:32:23.578614][00:00:02.941917][RIGCTRL:trace] write_block(): TX 22 bytes [2025-04-17 16:32:23.578614][00:00:02.941924][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 3e 3c 2f <CMD><READBMF></ [2025-04-17 16:32:23.578614][00:00:02.941927][RIGCTRL:trace] 0010 43 4d 44 3e 0d 0a CMD>.. [2025-04-17 16:32:23.578614][00:00:02.941931][RIGCTRL:debug] *****5:aclog.c(247):write_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.941934][RIGCTRL:debug] *****5:aclog.c(141):read_transaction entered [2025-04-17 16:32:23.578614][00:00:02.942350][RIGCTRL:trace] read_string_generic(): RX 109 characters, direct=1 [2025-04-17 16:32:23.578614][00:00:02.942365][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 52 45 41 44 42 4d 46 52 45 53 <CMD><READBMFRES [2025-04-17 16:32:23.578614][00:00:02.942369][RIGCTRL:trace] 0010 50 4f 4e 53 45 3e 3c 42 41 4e 44 3e 32 33 3c 2f PONSE><BAND>23</ [2025-04-17 16:32:23.578614][00:00:02.942372][RIGCTRL:trace] 0020 42 41 4e 44 3e 3c 4d 4f 44 45 3e 53 53 42 3c 2f BAND><MODE>SSB</ [2025-04-17 16:32:23.578614][00:00:02.942375][RIGCTRL:trace] 0030 4d 4f 44 45 3e 3c 4d 4f 44 45 54 45 53 54 3e 50 MODE><MODETEST>P [2025-04-17 16:32:23.578614][00:00:02.942378][RIGCTRL:trace] 0040 48 3c 2f 4d 4f 44 45 54 45 53 54 3e 3c 46 52 45 H</MODETEST><FRE [2025-04-17 16:32:23.578614][00:00:02.942383][RIGCTRL:trace] 0050 51 3e 31 2c 32 39 36 2e 31 37 31 31 30 30 3c 2f Q>1,296.171100</ [2025-04-17 16:32:23.578614][00:00:02.942390][RIGCTRL:trace] 0060 46 52 45 51 3e 3c 2f 43 4d 44 3e 0d 0a FREQ></CMD>.. [2025-04-17 16:32:23.578614][00:00:02.942396][RIGCTRL:trace] read_transaction: string='<CMD><READBMFRESPONSE><BAND>23</BAND><MODE>SSB</MODE><MODETEST>PH</MODETEST><FREQ>1,296.171100</FREQ></CMD> ' [2025-04-17 16:32:23.578614][00:00:02.942401][RIGCTRL:trace] read_transaction: got </CMD> [2025-04-17 16:32:23.578614][00:00:02.942406][RIGCTRL:debug] *****5:aclog.c(208):read_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.942412][RIGCTRL:debug] ****4:aclog_transaction: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.942416][RIGCTRL:debug] ****4:aclog.c(311):aclog_transaction returning(0) [2025-04-17 16:32:23.578614][00:00:02.942427][RIGCTRL:trace] modeMapGetHamlib: find '|SSB|' in '|USB|' [2025-04-17 16:32:23.578614][00:00:02.942431][RIGCTRL:trace] modeMapGetHamlib: find '|SSB|' in '|SSB|' [2025-04-17 16:32:23.578614][00:00:02.942434][RIGCTRL:trace] aclog_get_mode: mode='USB' [2025-04-17 16:32:23.578614][00:00:02.942438][RIGCTRL:debug] ***3:aclog.c(556):aclog_get_mode returning(0) [2025-04-17 16:32:23.578614][00:00:02.942443][RIGCTRL:trace] rig_get_mode: retcode after get_mode=0 [2025-04-17 16:32:23.578614][00:00:02.942449][RIGCTRL:trace] rig_get_mode(3091): debug [2025-04-17 16:32:23.578614][00:00:02.942454][RIGCTRL:debug] ***3:cache.c(40):rig_set_cache_mode entered [2025-04-17 16:32:23.578614][00:00:02.942464][RIGCTRL:debug] ***3:cache.c(156):rig_set_cache_mode returning(0) [2025-04-17 16:32:23.578614][00:00:02.942470][RIGCTRL:debug] **2:rig_get_mode: elapsed=0ms [2025-04-17 16:32:23.578614][00:00:02.942475][RIGCTRL:debug] **2:rig.c(3108):rig_get_mode returning(0) [2025-04-17 16:32:23.578614][00:00:02.942479][RIGCTRL:debug] network_flush called [2025-04-17 16:32:23.578614][00:00:02.942486][RIGCTRL:debug] **2:network.c(1589):network_multicast_publisher_start entered [2025-04-17 16:32:23.578614][00:00:02.942490][RIGCTRL:debug] network.c(1598): multicast publisher address=0.0.0.0, port=4532 [2025-04-17 16:32:23.585489][00:00:02.950811][RIGCTRL:debug] is_networked: network IfType = 6, name=Ethernet [2025-04-17 16:32:23.585489][00:00:02.950836][RIGCTRL:debug] 192.168.2.65: Address: 192.168.2.65 [2025-04-17 16:32:23.585489][00:00:02.950843][RIGCTRL:trace] network.c(1616): not starting multicast publisher [2025-04-17 16:32:23.585489][00:00:02.950850][RIGCTRL:debug] **2:network.c(1618):network_multicast_publisher_start returning(0) [2025-04-17 16:32:23.585489][00:00:02.950861][RIGCTRL:debug] **2:network.c(1800):network_multicast_receiver_start entered [2025-04-17 16:32:23.585489][00:00:02.950865][RIGCTRL:debug] network.c(1810): multicast receiver address=0.0.0.0, port=4532 [2025-04-17 16:32:23.585489][00:00:02.950869][RIGCTRL:trace] network.c(1817): not starting multicast receiver [2025-04-17 16:32:23.585489][00:00:02.950878][RIGCTRL:debug] **2:network.c(1819):network_multicast_receiver_start returning(0) [2025-04-17 16:32:23.585489][00:00:02.950882][RIGCTRL:debug] **2:event.c(272):rig_poll_routine_start entered [2025-04-17 16:32:23.585489][00:00:02.950948][RIGCTRL:debug] **2:event.c(312):rig_poll_routine_start returning(0) [2025-04-17 16:32:23.585489][00:00:02.950955][RIGCTRL:debug] rig.c(288):add_opened_rig entered [2025-04-17 16:32:23.585489][00:00:02.950960][RIGCTRL:debug] rig.c(300):add_opened_rig returning2(0) [2025-04-17 16:32:23.585489][00:00:02.950964][RIGCTRL:debug] rig.c(1641):rig_open returning2(0) [2025-04-17 16:32:23.585489][00:00:02.950970][RIGCTRL:debug] **2:rig.c(3449):rig_get_vfo entered [2025-04-17 16:32:23.585489][00:00:02.950974][RIGCTRL:trace] rig_get_vfo: cache hit age=6ms, vfo=VFOA [2025-04-17 16:32:23.585489][00:00:02.950981][RIGCTRL:debug] **2:rig_get_vfo: elapsed=0ms [2025-04-17 16:32:23.585489][00:00:02.950985][RIGCTRL:debug] **2:rig.c(3478):rig_get_vfo returning(0) [2025-04-17 16:32:23.585489][00:00:02.950991][RIGCTRL:debug] **2:rig.c(2433):rig_get_freq entered [2025-04-17 16:32:23.585489][00:00:02.950995][RIGCTRL:debug] rig_get_freq called vfo=currVFO [2025-04-17 16:32:23.585489][00:00:02.950999][RIGCTRL:debug] rig_get_freq(2451) called vfo=currVFO [2025-04-17 16:32:23.585489][00:00:02.951008][RIGCTRL:trace] vfo_fixup:(from rig_get_freq:2458) vfo=currVFO, vfo_curr=VFOA, split=0 [2025-04-17 16:32:23.585489][00:00:02.951011][RIGCTRL:trace] vfo_fixup: Leaving currVFO alone [2025-04-17 16:32:23.585489][00:00:02.951014][RIGCTRL:debug] rig.c(2460) vfo=currVFO, curr_vfo=VFOA [2025-04-17 16:32:23.585489][00:00:02.951027][RIGCTRL:trace] rig_get_freq: VFOA cache hit age=6ms, freq=1000000, use_cached_freq=0 [2025-04-17 16:32:23.585489][00:00:02.951031][RIGCTRL:debug] **2:rig_get_freq: elapsed=0ms [2025-04-17 16:32:23.585489][00:00:02.951034][RIGCTRL:debug] **2:rig.c(2554):rig_get_freq returning(0) [2025-04-17 16:32:23.585489][00:00:02.951044][RIGCTRL:debug] rig_get_band called [2025-04-17 16:32:23.585489][00:00:02.951048][RIGCTRL:debug] **2:rig.c(2102):rig_set_freq entered [2025-04-17 16:32:23.585489][00:00:02.951052][RIGCTRL:debug] rig_set_freq called vfo=currVFO, freq=1000055 [2025-04-17 16:32:23.585489][00:00:02.951057][RIGCTRL:trace] vfo_fixup:(from rig_set_freq:2179) vfo=currVFO, vfo_curr=VFOA, split=0 [2025-04-17 16:32:23.585489][00:00:02.951060][RIGCTRL:trace] vfo_fixup: Leaving currVFO alone [2025-04-17 16:32:23.585489][00:00:02.951063][RIGCTRL:debug] skip_freq: not skipping set_freq on vfo VFOA [2025-04-17 16:32:23.585489][00:00:02.951066][RIGCTRL:trace] rig_set_freq: TARGETABLE_FREQ vfo=VFOA [2025-04-17 16:32:23.585489][00:00:02.951069][RIGCTRL:trace] aclog_set_freq [2025-04-17 16:32:23.585489][00:00:02.951073][RIGCTRL:trace] aclog_set_freq: vfo=VFOA freq=1000055 [2025-04-17 16:32:23.585489][00:00:02.951079][RIGCTRL:debug] ***3:aclog.c(256):aclog_transaction entered [2025-04-17 16:32:23.585489][00:00:02.951084][RIGCTRL:debug] ****4:aclog.c(223):write_transaction entered [2025-04-17 16:32:23.585489][00:00:02.951087][RIGCTRL:debug] network_flush called [2025-04-17 16:32:23.585489][00:00:02.951142][RIGCTRL:debug] event.c(85): Starting rig poll routine thread [2025-04-17 16:32:23.585489][00:00:02.951182][RIGCTRL:trace] write_block(): TX 95 bytes [2025-04-17 16:32:23.585489][00:00:02.951193][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 43 48 41 4e 47 45 46 52 45 51 <CMD><CHANGEFREQ [2025-04-17 16:32:23.585489][00:00:02.951197][RIGCTRL:trace] 0010 3e 3c 56 41 4c 55 45 3e 31 2e 30 30 30 30 35 35 ><VALUE>1.000055 [2025-04-17 16:32:23.585489][00:00:02.951212][RIGCTRL:trace] rig_set_cache_timeout_ms: called selection=0, ms=1000 [2025-04-17 16:32:23.585489][00:00:02.951230][RIGCTRL:trace] 0020 3c 2f 56 41 4c 55 45 3e 3c 53 55 50 50 52 45 53 </VALUE><SUPPRES [2025-04-17 16:32:23.585489][00:00:02.951238][RIGCTRL:trace] 0030 53 4d 4f 44 45 44 45 46 41 55 4c 54 3e 54 52 55 SMODEDEFAULT>TRU [2025-04-17 16:32:23.585489][00:00:02.951242][RIGCTRL:trace] 0040 45 3c 2f 53 55 50 50 52 45 53 53 4d 4f 44 45 44 E</SUPPRESSMODED [2025-04-17 16:32:23.585489][00:00:02.951246][RIGCTRL:trace] 0050 45 46 41 55 4c 54 3e 3c 2f 43 4d 44 3e 0d 0a EFAULT></CMD>.. [2025-04-17 16:32:23.585489][00:00:02.951252][RIGCTRL:debug] ****4:aclog.c(247):write_transaction returning(0) [2025-04-17 16:32:23.585489][00:00:02.951256][RIGCTRL:debug] ****4:aclog.c(141):read_transaction entered [2025-04-17 16:32:23.585489][00:00:02.951652][RIGCTRL:trace] read_string_generic(): RX 56 characters, direct=1 [2025-04-17 16:32:23.585489][00:00:02.951668][RIGCTRL:trace] 0000 3c 43 4d 44 3e 3c 43 48 41 4e 47 45 46 52 45 51 <CMD><CHANGEFREQ [2025-04-17 16:32:23.585489][00:00:02.951673][RIGCTRL:trace] 0010 52 45 53 50 4f 4e 53 45 3e 3c 56 41 4c 55 45 3e RESPONSE><VALUE> [2025-04-17 16:32:23.585489][00:00:02.951677][RIGCTRL:trace] 0020 31 2e 30 30 30 30 35 35 3c 2f 56 41 4c 55 45 3e 1.000055</VALUE> [2025-04-17 16:32:23.585489][00:00:02.951681][RIGCTRL:trace] 0030 3c 2f 43 4d 44 3e 0d 0a </CMD>.. [2025-04-17 16:32:23.585489][00:00:02.951686][RIGCTRL:trace] read_transaction: string='<CMD><CHANGEFREQRESPONSE><VALUE>1.000055</VALUE></CMD> ' |
|
From: Christopher S. <nx...@vc...> - 2025-04-17 17:55:13
|
When upgrading to version 2.7.0 I can no longer control my Icom R8600. It was working with earlier versions (2.6.1). I am running Windows 10 Pro. The program starts and shows the current radio frequency. (This seems to be the case whether I start the program with the radio in the VFO mode or memory mode - it has never mattered before.) When I use the frequency drop down box the frequency does not change. When I try again I get a Rig Control Error box with details: > Hamlib error: > icom.c(9652):set_vfo_curr returning2(-9) Command rejected by the rig > > icom.c(1595):icom_set_freq returning2(-9) Command rejected by the rig > > rig_set_cache_freq(171): vfo=VFOA, current_vfo=currVFO > rig_set_freq: vfo=VFOA, save=currVFO > *rig.c(2410) trace > **2:rig.c(3333):rig_set_vfo entered > rig_set_vfo called vfo=currVFO > vfo_fixup:(from rig_set_vfo:3347) vfo=currVFO, vfo_curr=currVFO, split=0 > vfo_fixup: Leaving currVFO alone > **2:rig_set_vfo: elapsed=0ms > **2:rig.c(3352):rig_set_vfo returning(0) > *1:rig_set_freq: elapsed=31ms > rig_lock: client lock disengaged > *1:rig.c(2416):rig_set_freq returning(-9) Command rejected by the rig > > Command rejected by the rig > Command rejected by the rig > while setting frequency > > Timestamp: 2025-04-15T16:31:36.050Z When reverting to the previous hamlib version, but still running WSJT-X version 2.7.0 I have the same problem. I might note the current FLDIGI embedded hamlib version works, to a point. I can always set the frequency from the radio, but when I vary the frequency from the radio, FLDIGI only follows it for a few changes, then the display (on the program, not the radio) locks up. 73, Chris NX0E |
|
From: Andy D. <a.d...@ms...> - 2025-04-17 13:18:06
|
Since OmniRig works for other users I tried to find out what configuration difference could account for my problem. I have always used Mode = None because I want to take responsibility for my rig configuration. 2.8.0 improved, when used with OnmiRig, does not control rig frequency when Mode = None. It does control rig frequency when Mode = USB. 2.7.1 and all earlier versions control rig frequency when Mode = none. I hope this can be corrected. 73, Andy, k3wyc |
|
From: Andy D. <a.d...@ms...> - 2025-04-17 13:16:46
|
I am using OmniRig 1.20 as downloaded from DX Atlas site. Would anyone who is using OmniRig with 2.8.0 improved please send me a screen shot of their Settings/Radio. If my address is not visible here it is good on QRZ. It is obvious that some aspect of the OmiRig interface was changed between 2.7.1 improved and 2.8.0 improved since the former works and the latter does not work at my station. 73, Andy, k3wyc |
|
From: Hasan N. <hba...@gm...> - 2025-04-17 12:14:28
|
Make sure you are using the right version of Omni-rig...the "unapproved" new version does not work right. 9Unapproved means, not from the author's site) 73, N0AN Hasan On Wed, Apr 16, 2025 at 5:14 PM Andy Durbin via wsjt-devel < wsj...@li...> wrote: > Is anyone else seeing problems with 2.8.0 250314 improved PLUS when using > OmniRig? > > Changing band on WSJT-X changes the "dial" frequency displayed my WSJT-X > but does not change the frequency of my TS-590S. I revert to devel 240721 > improved PLUS and rig control works. WSJT-X "dial" does not display what > the rig is tuned to. It only displays what WSJT-X was told to tune it to. > > I have emailed Uwe twice about this issue but have received no reply. > > 73, > Andy, k3wyc > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > |
|
From: Lance C. W. <w7...@bi...> - 2025-04-16 22:48:30
|
It works FB with OMNIRIG here...I am using OMNIRIG to control my K4. GL and VY 73, Lance On 4/16/2025 21:37:20, Andy Durbin via wsjt-devel wrote: > Is anyone else seeing problems with 2.8.0 250314 improved PLUS when using OmniRig? > > Changing band on WSJT-X changes the "dial" frequency displayed my WSJT-X but does > not change the frequency of my TS-590S. I revert to devel 240721 improved PLUS and > rig control works. WSJT-X "dial" does not display what the rig is tuned to. It > only displays what WSJT-X was told to tune it to. > > I have emailed Uwe twice about this issue but have received no reply. > > 73, > Andy, k3wyc > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > 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, FO/W7GJ, TX7MB, TO7GJ, 3B9GJ, ZD9GJ, H40GJ) 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)! |
|
From: Andy D. <a.d...@ms...> - 2025-04-16 22:12:11
|
Is anyone else seeing problems with 2.8.0 250314 improved PLUS when using OmniRig? Changing band on WSJT-X changes the "dial" frequency displayed my WSJT-X but does not change the frequency of my TS-590S. I revert to devel 240721 improved PLUS and rig control works. WSJT-X "dial" does not display what the rig is tuned to. It only displays what WSJT-X was told to tune it to. I have emailed Uwe twice about this issue but have received no reply. 73, Andy, k3wyc |
|
From: Mark G. <n7...@mg...> - 2025-04-16 21:32:24
|
Gotcha. I appreciate the effort you put into making this modular. I retired about a year ago after 45+ years of writing code and supporting systems. 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD From: DG2YCB <DG...@gm...> Sent: Wednesday, April 16, 2025 14:29 To: Mark Galbraith <n7...@mg...>; WSJT software development <wsj...@li...> Subject: Re: Request for new filter (was RE: [wsjt-devel] FW: Button sizes not correct) Hi Mark, A new filter "Hide stations worked today" is doable. Presumably even with a relatively small code addition. I'll have a look at the code tomorrow. A small update is planned for next month anyway. Let's see ... Both editions of WSJT-X are one and the same program. They have the same source code core and are created on the same computers by (nearly) the same dev team. If you don't like some of the additional features in v2.8.0, you can disable them individually. If you disable all of them (or do not use them), you basically have the plain WSJT-X v2.7.0. 73 de DG2YCB, Uwe _________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: DG...@gm...<mailto:DG...@gm...> Info: www.qrz.com/db/DG2YCB<http://www.qrz.com/db/DG2YCB> Am 16. April 2025 21:50:10 schrieb Mark Galbraith <n7...@mg...<mailto:n7...@mg...>>: Ok, Uwe. I went ahead and did it. I admit the “Wait” features threw me off a bit at first, but I can see the usefulness of them. The filters are also useful for decluttering the list, especially for stations recently worked. I do have one suggestion for the filters. While the filters for Hide and Ignore stations worked yesterday or today are useful, a more focused filter would be even more useful for things like POTA hunting. If you haven’t hunted POTA stations before, an “Activation” is for a single UTC day. You can work a station at 23:59 on UTC Friday, and then turn around and work the station again at 00:02. Each contact counts under the POTA rules. However the currently available filter will still hide the station from the list. What I would like to have is a filter that hides stations that I’ve worked on the current UTC day. This way, once I work a POTA station they won’t show up again until the UTC day rolls over, but once it does they will be back in the list. Is something like that doable? 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD From: Uwe, DG2YCB <dg...@gm...<mailto:dg...@gm...>> Sent: Monday, April 14, 2025 23:54 To: WSJT software development <wsj...@li...<mailto:wsj...@li...>> Cc: Mark Galbraith <n7...@mg...<mailto:n7...@mg...>> Subject: Re: [wsjt-devel] FW: Button sizes not correct Hi Mark, Why don't you use WSJT-X Improved v2.8.0? It has high-DPI scaling built in, as well as dozens of other useful extra features. [cid:image001.png@01DBAEDC.4A678CE0] But if you really want to develop the wheel a second time, feel free to do so ... 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm...<mailto:dg...@gm...> Info: www.qrz.com/db/DG2YCB<http://www.qrz.com/db/DG2YCB> Am 15.04.2025 um 01:53 schrieb Mark Galbraith via wsjt-devel: I suppose the images included in my email are making it too large for the mailing list. I’m forwarding this back to the wsjt-devel team with the images removed. Anyone wanting to see the full email with the images restored can email me for a direct copy. 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD From: Mark Galbraith Sent: Sunday, April 13, 2025 17:25 To: Black Michael <mdb...@ya...><mailto:mdb...@ya...>; WSJT software development <wsj...@li...><mailto:wsj...@li...>; Mark Galbraith <ma...@mg...><mailto:ma...@mg...> Subject: RE: [wsjt-devel] Button sizes not correct I apologize for the long delay in replying. I had gotten feedback that this was not something that could be fixed, so I set it aside. However, my background in programming would not let this go, and eventually I had time and the drive to dig into this further. Along the way I determined the use of Qt tools and dug into this a bit more. I found the location where the UI buttons are set, and saw they have a minimum size of 32. I couldn’t see anything else that jumped out of the source code, so I went looking for other information available. I found a few items on StackOvervlow and eventually found this article on the Qt Forum that seemed to be on point. https://doc.qt.io/qt-5/highdpi.html In reading through, I see that there is a workaround by setting the environment variable QT_ENABLE_HIGHDPI_SCALING prior to running the application should enable the high-DPI support. I ran some experiments, and this is what I found. BEFORE The buttons on the main UI panel are clipped: And the font size on the waterfall display is huge: AFTER setting the environment variable: The buttons as well asother screen elements are no longer clipped: And the waterfall font size is back to normal: CONCLUSION The WSJT-X program will display properly if the high-DPI support in Qt is enabled. While setting the environment variable is a workaround for this, the proper course of action would be to enable this support in the source code. According to the StackOverflow pages, the following line, executed prior to initializing the application will enable the high-DPI support. QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); In the WSJT-X, the initialization of the Qt application occurs inside ExceptionCatchingApplication.hpp, which is included into main.cpp and called at line 118 (as found in the 2.7.0 code on SourceForge). In my view, inserting the above “setAttribute” just above line 118 will properly enable the high-DPI support for Qt, and solve this and possibly many other issues with users of high-DPI monitors in the userbase. Please feel free to reach out if you have any questions or would like to discuss this issue further. 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD From: Black Michael <mdb...@ya...<mailto:mdb...@ya...>> Sent: Friday, September 1, 2023 12:53 To: WSJT software development <wsj...@li...<mailto:wsj...@li...>>; Mark Galbraith <n7...@mg...<mailto:n7...@mg...>>; mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct Can you provide a screen shot? What font are you using -- I have Microsoft Sans Serif 8pt. Mike W9MDB On Friday, September 1, 2023 at 01:01:45 PM CDT, mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> wrote: After switching back, and the problem with the button sizes returns, I make the following observations. 1. The text margins for the “H” button seem to be correct. 2. The remaining buttons in the column use the same button size as the “H” button. 3. Scaling those buttons on one of the longer button labels may resolve the problem for all resolutions. I’m a retired programmer with 45 years of experience. I’ve seen these types of problems many times. Sometimes, the hard problems have easy solutions. Other times you grab a big hammer… --Mark From: mark mgg4.com via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> Sent: Friday, September 1, 2023 10:54 AM To: Black Michael <mdb...@ya...<mailto:mdb...@ya...>>; WSJT software development <wsj...@li...<mailto:wsj...@li...>>; Mark Galbraith <n7...@mg...<mailto:n7...@mg...>> Cc: mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct All of them. Most annoying is the Log popup which I have positioned for easy tapping (touch screen). --Mark From: Black Michael <mdb...@ya...<mailto:mdb...@ya...>> Sent: Friday, September 1, 2023 10:52 AM To: WSJT software development <wsj...@li...<mailto:wsj...@li...>>; Mark Galbraith <n7...@mg...<mailto:n7...@mg...>> Cc: mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct Which windows? On Friday, September 1, 2023 at 12:46:50 PM CDT, Mark Galbraith <n7...@mg...<mailto:n7...@mg...>> wrote: After a few more experiments, I’ve reverted this change. The program no longer remembers where certain windows open on the screen, opening all windows in the center. This is a bit more disruptive than the narrow buttons. --Mark, N7YD From: mark mgg4.com via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> Sent: Friday, September 1, 2023 10:37 AM To: Black Michael <mdb...@ya...<mailto:mdb...@ya...>>; WSJT software development <wsj...@li...<mailto:wsj...@li...>> Cc: mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct Thank you. That does change a few things, and some of the text seems a bit less sharp, but it does fix the problem and I like the overall effect better. I very much appreciate your response. --Mark, N7YD From: Black Michael via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> Sent: Friday, September 1, 2023 9:25 AM To: WSJT software development <wsj...@li...<mailto:wsj...@li...>> Cc: Black Michael <mdb...@ya...<mailto:mdb...@ya...>> Subject: Re: [wsjt-devel] Button sizes not correct Try this to replace the qt.conf in your bin directory [Paths] Plugins = ../plugins [Platforms] WindowsArguments = dpiawareness=0 Mike W9MDB On Thursday, August 31, 2023 at 10:43:43 PM CDT, Laurie, VK3AMA via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> wrote: On 01/09/2023 8:15 am, Mark Galbraith via wsjt-devel wrote: Not sure what’s happening here, but my guess would be that the screen resolution may be off, but I was seeing this on other computers as well. My computer is a Microsoft Surfacebook 2, with a screen resolution of 3240 x 2160. I was also seeing the same thing on my other computer with a 32” ultra widescreen resolution of 2560 x 1080. I’m also seeing this on v2.6.1 and v2.7.0-rc2. Is there a setting I need to adjust, or is this something that requires a program change to fix? 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD A long standing defect that I gave up on getting the devs to correct. All other UI controls inducing the Tx1-6 buttons are scaled correctly except these buttons! Here's mine, like you replicated across multiple devices. de Laurie VK3AMA _______________________________________________ wsjt-devel mailing list wsj...@li...<mailto:wsj...@li...> https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list wsj...@li...<mailto:wsj...@li...> https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: DG2YCB <DG...@gm...> - 2025-04-16 21:29:05
|
Hi Mark, A new filter "Hide stations worked today" is doable. Presumably even with a relatively small code addition. I'll have a look at the code tomorrow. A small update is planned for next month anyway. Let's see ... Both editions of WSJT-X are one and the same program. They have the same source code core and are created on the same computers by (nearly) the same dev team. If you don't like some of the additional features in v2.8.0, you can disable them individually. If you disable all of them (or do not use them), you basically have the plain WSJT-X v2.7.0. 73 de DG2YCB, Uwe _________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: DG...@gm... Info: www.qrz.com/db/DG2YCB Am 16. April 2025 21:50:10 schrieb Mark Galbraith <n7...@mg...>: > Ok, Uwe. I went ahead and did it. I admit the “Wait” features threw me > off a bit at first, but I can see the usefulness of them. The filters are > also useful for decluttering the list, especially for stations recently > worked. I do have one suggestion for the filters. > > > > While the filters for Hide and Ignore stations worked yesterday or today > are useful, a more focused filter would be even more useful for things like > POTA hunting. If you haven’t hunted POTA stations before, an “Activation” > is for a single UTC day. You can work a station at 23:59 on UTC Friday, > and then turn around and work the station again at 00:02. Each contact > counts under the POTA rules. However the currently available filter will > still hide the station from the list. > > > > What I would like to have is a filter that hides stations that I’ve worked > on the current UTC day. This way, once I work a POTA station they won’t > show up again until the UTC day rolls over, but once it does they will be > back in the list. > > > > Is something like that doable? > > > > > > 73 > > -.. . / -- .- .-. -.- / -. --... -.-- -.. > > DE MARK N7YD > > > > From: Uwe, DG2YCB <dg...@gm...> > Sent: Monday, April 14, 2025 23:54 > To: WSJT software development <wsj...@li...> > Cc: Mark Galbraith <n7...@mg...> > Subject: Re: [wsjt-devel] FW: Button sizes not correct > > > > Hi Mark, > > Why don't you use WSJT-X Improved v2.8.0? It has high-DPI scaling built in, > as well as dozens of other useful extra features. > > > But if you really want to develop the wheel a second time, feel free to do > so ... > > > 73 de DG2YCB, > Uwe > ________________________________________ > German Amateur Radio Station DG2YCB > Dr. Uwe Risse > eMail: dg...@gm... > Info: www.qrz.com/db/DG2YCB > > > > Am 15.04.2025 um 01:53 schrieb Mark Galbraith via wsjt-devel: > > I suppose the images included in my email are making it too large for the > mailing list. I’m forwarding this back to the wsjt-devel team with the > images removed. Anyone wanting to see the full email with the images > restored can email me for a direct copy. > > > > > > 73 > > -.. . / -- .- .-. -.- / -. --... -.-- -.. > > DE MARK N7YD > > > > From: Mark Galbraith > Sent: Sunday, April 13, 2025 17:25 > To: Black Michael <mdb...@ya...>; WSJT software development > <wsj...@li...>; Mark Galbraith <ma...@mg...> > Subject: RE: [wsjt-devel] Button sizes not correct > > > > I apologize for the long delay in replying. I had gotten feedback that > this was not something that could be fixed, so I set it aside. However, my > background in programming would not let this go, and eventually I had time > and the drive to dig into this further. Along the way I determined the use > of Qt tools and dug into this a bit more. I found the location where the > UI buttons are set, and saw they have a minimum size of 32. I couldn’t see > anything else that jumped out of the source code, so I went looking for > other information available. I found a few items on StackOvervlow and > eventually found this article on the Qt Forum that seemed to be on point. > > > > https://doc.qt.io/qt-5/highdpi.html > > > > In reading through, I see that there is a workaround by setting the > environment variable QT_ENABLE_HIGHDPI_SCALING prior to running the > application should enable the high-DPI support. I ran some experiments, > and this is what I found. > > > > BEFORE > > > > The buttons on the main UI panel are clipped: > > > > > > > > And the font size on the waterfall display is huge: > > > > > > > > > > AFTER setting the environment variable: > > > > The buttons as well asother screen elements are no longer clipped: > > > > > > > > And the waterfall font size is back to normal: > > > > > > > > > > CONCLUSION > > > > The WSJT-X program will display properly if the high-DPI support in Qt is > enabled. While setting the environment variable is a workaround for this, > the proper course of action would be to enable this support in the source > code. According to the StackOverflow pages, the following line, executed > prior to initializing the application will enable the high-DPI support. > > > > QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); > > > > In the WSJT-X, the initialization of the Qt application occurs inside > ExceptionCatchingApplication.hpp, which is included into main.cpp and > called at line 118 (as found in the 2.7.0 code on SourceForge). In my > view, inserting the above “setAttribute” just above line 118 will properly > enable the high-DPI support for Qt, and solve this and possibly many other > issues with users of high-DPI monitors in the userbase. > > > > Please feel free to reach out if you have any questions or would like to > discuss this issue further. > > > > > > 73 > > -.. . / -- .- .-. -.- / -. --... -.-- -.. > > DE MARK N7YD > > > > From: Black Michael <mdb...@ya...> > Sent: Friday, September 1, 2023 12:53 > To: WSJT software development <wsj...@li...>; Mark > Galbraith <n7...@mg...>; mark mgg4.com <ma...@mg...> > Subject: Re: [wsjt-devel] Button sizes not correct > > > > Can you provide a screen shot? > > > > What font are you using -- I have Microsoft Sans Serif 8pt. > > > > > > > > Mike W9MDB > > > > > > > > > > On Friday, September 1, 2023 at 01:01:45 PM CDT, mark mgg4.com > <ma...@mg...> wrote: > > > > > > After switching back, and the problem with the button sizes returns, I make > the following observations. > > > > The text margins for the “H” button seem to be correct. > The remaining buttons in the column use the same button size as the “H” button. > Scaling those buttons on one of the longer button labels may resolve the > problem for all resolutions. > > > > I’m a retired programmer with 45 years of experience. I’ve seen these > types of problems many times. Sometimes, the hard problems have easy > solutions. Other times you grab a big hammer… > > > > > > --Mark > > > > From: mark mgg4.com via wsjt-devel <wsj...@li...> > Sent: Friday, September 1, 2023 10:54 AM > To: Black Michael <mdb...@ya...>; WSJT software development > <wsj...@li...>; Mark Galbraith <n7...@mg...> > Cc: mark mgg4.com <ma...@mg...> > Subject: Re: [wsjt-devel] Button sizes not correct > > > > All of them. Most annoying is the Log popup which I have positioned for > easy tapping (touch screen). > > > > > > --Mark > > > > From: Black Michael <mdb...@ya...> > Sent: Friday, September 1, 2023 10:52 AM > To: WSJT software development <wsj...@li...>; Mark > Galbraith <n7...@mg...> > Cc: mark mgg4.com <ma...@mg...> > Subject: Re: [wsjt-devel] Button sizes not correct > > > > Which windows? > > > > > > > > > > On Friday, September 1, 2023 at 12:46:50 PM CDT, Mark Galbraith > <n7...@mg...> wrote: > > > > > > After a few more experiments, I’ve reverted this change. The program no > longer remembers where certain windows open on the screen, opening all > windows in the center. This is a bit more disruptive than the narrow buttons. > > > > --Mark, N7YD > > > > > > From: mark mgg4.com via wsjt-devel <wsj...@li...> > Sent: Friday, September 1, 2023 10:37 AM > To: Black Michael <mdb...@ya...>; WSJT software development > <wsj...@li...> > Cc: mark mgg4.com <ma...@mg...> > Subject: Re: [wsjt-devel] Button sizes not correct > > > > Thank you. That does change a few things, and some of the text seems a bit > less sharp, but it does fix the problem and I like the overall effect > better. I very much appreciate your response. > > > > > > --Mark, N7YD > > > > > > > > From: Black Michael via wsjt-devel <wsj...@li...> > Sent: Friday, September 1, 2023 9:25 AM > To: WSJT software development <wsj...@li...> > Cc: Black Michael <mdb...@ya...> > Subject: Re: [wsjt-devel] Button sizes not correct > > > > Try this to replace the qt.conf in your bin directory > > > > [Paths] > > Plugins = ../plugins > > > > [Platforms] > > WindowsArguments = dpiawareness=0 > > > > > > Mike W9MDB > > > > > > On Thursday, August 31, 2023 at 10:43:43 PM CDT, Laurie, VK3AMA via > wsjt-devel <wsj...@li...> wrote: > > > > > > On 01/09/2023 8:15 am, Mark Galbraith via wsjt-devel wrote: > > Not sure what’s happening here, but my guess would be that the screen > resolution may be off, but I was seeing this on other computers as well. > > > > > > > > My computer is a Microsoft Surfacebook 2, with a screen resolution of 3240 > x 2160. I was also seeing the same thing on my other computer with a 32” > ultra widescreen resolution of 2560 x 1080. I’m also seeing this on v2.6.1 > and v2.7.0-rc2. Is there a setting I need to adjust, or is this something > that requires a program change to fix? > > > > > > 73 > > -.. . / -- .- .-. -.- / -. --... -.-- -.. > > DE MARK N7YD > > > > A long standing defect that I gave up on getting the devs to correct. > > All other UI controls inducing the Tx1-6 buttons are scaled correctly > except these buttons! > > Here's mine, like you replicated across multiple devices. > > > de Laurie VK3AMA > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel > > > > > > > _______________________________________________ > wsjt-devel mailing list > wsj...@li... > https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
|
From: Mark G. <n7...@mg...> - 2025-04-16 20:08:45
|
Ok, Uwe. I went ahead and did it. I admit the “Wait” features threw me off a bit at first, but I can see the usefulness of them. The filters are also useful for decluttering the list, especially for stations recently worked. I do have one suggestion for the filters. While the filters for Hide and Ignore stations worked yesterday or today are useful, a more focused filter would be even more useful for things like POTA hunting. If you haven’t hunted POTA stations before, an “Activation” is for a single UTC day. You can work a station at 23:59 on UTC Friday, and then turn around and work the station again at 00:02. Each contact counts under the POTA rules. However the currently available filter will still hide the station from the list. What I would like to have is a filter that hides stations that I’ve worked on the current UTC day. This way, once I work a POTA station they won’t show up again until the UTC day rolls over, but once it does they will be back in the list. Is something like that doable? 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD From: Uwe, DG2YCB <dg...@gm...> Sent: Monday, April 14, 2025 23:54 To: WSJT software development <wsj...@li...> Cc: Mark Galbraith <n7...@mg...> Subject: Re: [wsjt-devel] FW: Button sizes not correct Hi Mark, Why don't you use WSJT-X Improved v2.8.0? It has high-DPI scaling built in, as well as dozens of other useful extra features. [cid:image001.png@01DBAECB.EA18A780] But if you really want to develop the wheel a second time, feel free to do so ... 73 de DG2YCB, Uwe ________________________________________ German Amateur Radio Station DG2YCB Dr. Uwe Risse eMail: dg...@gm...<mailto:dg...@gm...> Info: www.qrz.com/db/DG2YCB<http://www.qrz.com/db/DG2YCB> Am 15.04.2025 um 01:53 schrieb Mark Galbraith via wsjt-devel: I suppose the images included in my email are making it too large for the mailing list. I’m forwarding this back to the wsjt-devel team with the images removed. Anyone wanting to see the full email with the images restored can email me for a direct copy. 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD From: Mark Galbraith Sent: Sunday, April 13, 2025 17:25 To: Black Michael <mdb...@ya...><mailto:mdb...@ya...>; WSJT software development <wsj...@li...><mailto:wsj...@li...>; Mark Galbraith <ma...@mg...><mailto:ma...@mg...> Subject: RE: [wsjt-devel] Button sizes not correct I apologize for the long delay in replying. I had gotten feedback that this was not something that could be fixed, so I set it aside. However, my background in programming would not let this go, and eventually I had time and the drive to dig into this further. Along the way I determined the use of Qt tools and dug into this a bit more. I found the location where the UI buttons are set, and saw they have a minimum size of 32. I couldn’t see anything else that jumped out of the source code, so I went looking for other information available. I found a few items on StackOvervlow and eventually found this article on the Qt Forum that seemed to be on point. https://doc.qt.io/qt-5/highdpi.html In reading through, I see that there is a workaround by setting the environment variable QT_ENABLE_HIGHDPI_SCALING prior to running the application should enable the high-DPI support. I ran some experiments, and this is what I found. BEFORE The buttons on the main UI panel are clipped: And the font size on the waterfall display is huge: AFTER setting the environment variable: The buttons as well asother screen elements are no longer clipped: And the waterfall font size is back to normal: CONCLUSION The WSJT-X program will display properly if the high-DPI support in Qt is enabled. While setting the environment variable is a workaround for this, the proper course of action would be to enable this support in the source code. According to the StackOverflow pages, the following line, executed prior to initializing the application will enable the high-DPI support. QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); In the WSJT-X, the initialization of the Qt application occurs inside ExceptionCatchingApplication.hpp, which is included into main.cpp and called at line 118 (as found in the 2.7.0 code on SourceForge). In my view, inserting the above “setAttribute” just above line 118 will properly enable the high-DPI support for Qt, and solve this and possibly many other issues with users of high-DPI monitors in the userbase. Please feel free to reach out if you have any questions or would like to discuss this issue further. 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD From: Black Michael <mdb...@ya...<mailto:mdb...@ya...>> Sent: Friday, September 1, 2023 12:53 To: WSJT software development <wsj...@li...<mailto:wsj...@li...>>; Mark Galbraith <n7...@mg...<mailto:n7...@mg...>>; mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct Can you provide a screen shot? What font are you using -- I have Microsoft Sans Serif 8pt. Mike W9MDB On Friday, September 1, 2023 at 01:01:45 PM CDT, mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> wrote: After switching back, and the problem with the button sizes returns, I make the following observations. 1. The text margins for the “H” button seem to be correct. 2. The remaining buttons in the column use the same button size as the “H” button. 3. Scaling those buttons on one of the longer button labels may resolve the problem for all resolutions. I’m a retired programmer with 45 years of experience. I’ve seen these types of problems many times. Sometimes, the hard problems have easy solutions. Other times you grab a big hammer… --Mark From: mark mgg4.com via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> Sent: Friday, September 1, 2023 10:54 AM To: Black Michael <mdb...@ya...<mailto:mdb...@ya...>>; WSJT software development <wsj...@li...<mailto:wsj...@li...>>; Mark Galbraith <n7...@mg...<mailto:n7...@mg...>> Cc: mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct All of them. Most annoying is the Log popup which I have positioned for easy tapping (touch screen). --Mark From: Black Michael <mdb...@ya...<mailto:mdb...@ya...>> Sent: Friday, September 1, 2023 10:52 AM To: WSJT software development <wsj...@li...<mailto:wsj...@li...>>; Mark Galbraith <n7...@mg...<mailto:n7...@mg...>> Cc: mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct Which windows? On Friday, September 1, 2023 at 12:46:50 PM CDT, Mark Galbraith <n7...@mg...<mailto:n7...@mg...>> wrote: After a few more experiments, I’ve reverted this change. The program no longer remembers where certain windows open on the screen, opening all windows in the center. This is a bit more disruptive than the narrow buttons. --Mark, N7YD From: mark mgg4.com via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> Sent: Friday, September 1, 2023 10:37 AM To: Black Michael <mdb...@ya...<mailto:mdb...@ya...>>; WSJT software development <wsj...@li...<mailto:wsj...@li...>> Cc: mark mgg4.com <ma...@mg...<mailto:ma...@mg...>> Subject: Re: [wsjt-devel] Button sizes not correct Thank you. That does change a few things, and some of the text seems a bit less sharp, but it does fix the problem and I like the overall effect better. I very much appreciate your response. --Mark, N7YD From: Black Michael via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> Sent: Friday, September 1, 2023 9:25 AM To: WSJT software development <wsj...@li...<mailto:wsj...@li...>> Cc: Black Michael <mdb...@ya...<mailto:mdb...@ya...>> Subject: Re: [wsjt-devel] Button sizes not correct Try this to replace the qt.conf in your bin directory [Paths] Plugins = ../plugins [Platforms] WindowsArguments = dpiawareness=0 Mike W9MDB On Thursday, August 31, 2023 at 10:43:43 PM CDT, Laurie, VK3AMA via wsjt-devel <wsj...@li...<mailto:wsj...@li...>> wrote: On 01/09/2023 8:15 am, Mark Galbraith via wsjt-devel wrote: Not sure what’s happening here, but my guess would be that the screen resolution may be off, but I was seeing this on other computers as well. My computer is a Microsoft Surfacebook 2, with a screen resolution of 3240 x 2160. I was also seeing the same thing on my other computer with a 32” ultra widescreen resolution of 2560 x 1080. I’m also seeing this on v2.6.1 and v2.7.0-rc2. Is there a setting I need to adjust, or is this something that requires a program change to fix? 73 -.. . / -- .- .-. -.- / -. --... -.-- -.. DE MARK N7YD A long standing defect that I gave up on getting the devs to correct. All other UI controls inducing the Tx1-6 buttons are scaled correctly except these buttons! Here's mine, like you replicated across multiple devices. de Laurie VK3AMA _______________________________________________ wsjt-devel mailing list wsj...@li...<mailto:wsj...@li...> https://lists.sourceforge.net/lists/listinfo/wsjt-devel _______________________________________________ wsjt-devel mailing list wsj...@li...<mailto:wsj...@li...> https://lists.sourceforge.net/lists/listinfo/wsjt-devel |
68 messages has been excluded from this view by a project administrator.
