w1hkj / flrig Goto Github PK

See https://bugs.gentoo.org/921405

Compilation fails with
widgets/FreqControl.cxx:82:29: error: unknown type name 'intptr_t'; did you mean '__intptr_t'? 82 | int Nbr = reinterpret_cast<intptr_t> (nbr);

Adding
#include <stdint.h>
to widgets/FreqControl.cxx fixes the problem.

First of all, thank you for a great program.

I was using v1.3.39 up until today and realized that I an upgrade was available (apparently , I missed one or two.) I jumped up to V2.0.04 and found that my FT-450D configuration no longer works properly when Flrig is started using Auto on with the rig off, which still works fine on v1.3.39. All v2.0.04 settings that relate to the rig are matched to the v1.3.39. I have deleted the preferences file and rebuilt it from a clean install to see if it would change anything but it does not.

If this issue is something I am doing, please let me know but I have tried everything I can think of to get this to work the same but cannot.

Below are my preferences for the FT-450D currently being used:

; FLTK preferences file format 1.0
; vendor: w1hkj.com
; application: FT-450D

[.]

version:2.0.04
mainx:50
mainy:50
mainw:735
mainh:148
uisize:1
memx:20
memy:31
memw:600
memh:182
metersx:785
metersy:50
meters_dialog_visible:0
ddx:20
ddy:20
xcvr_serial_port:COM14
serial_baudrate:7
serial_stopbits:1
serial_retries:10
serial_write_delay:0
serial_post_write_delay:0
serial_timeout:50
serloop_timing:10
ptt_via_cat:1
ptt_via_rts:0
ptt_via_dtr:0
rts_cts_flow:1
rts_plus:1
dtr_plus:0
disable_CW_ptt:0
civadr:0
usbaudio:0
aux_serial_port:NONE
aux_rts:0
aux_dtr:0
sep_serial_port:NONE
sep_rtsptt:0
sep_dtrptt:0
sep_rtsplus:0
set_dtrplus:0
xmlport:12345
cmedia_device:NONE
cmedia_gpio_line:GPIO-3
cmedia_ptt:0
tmate2_device:NONE
tmate2_freq_step:5000
tmate2_connected:0
poll_smeter:1
poll_frequency:1
poll_mode:1
poll_bandwidth:1
poll_volume:4
poll_auto_notch:0
poll_notch:4
poll_ifshift:4
poll_pbt:0
poll_power_control:4
poll_pre_att:4
poll_micgain:0
poll_squelch:0
poll_rfgain:4
poll_pout:1
poll_swr:1
poll_alc:1
poll_split:0
poll_noise:4
poll_nr:4
poll_compression:0
poll_tuner:4
poll_ptt:4
poll_break_in:0
poll_all:4
bw_A:0
mode_A:10
freq_A_u:0
freq_A_l:21071500
bw_B:0
mode_B:10
freq_B_u:0
freq_B_l:28121500
filters:
bandwidths:0 0 -1 -1 -1 -1 -1 -1 -1 -1 0 -1 0 -1 -1 -1 -1 -1 -1 -1 -1 0
+
use_rig_data:1
restore_frequency:1
restore_mode:1
restore_bandwidth:1
restore_volume:1
restore_mic_gain:1
restore_rf_gain:1
restore_power_control:1
restore_if_shift:1
restore_notch:1
restore_auto_notch:1
restore_noise:1
restore_squelch:1
restore_split:1
restore_pre_att:1
restore_nr:1
restore_comp_on_off:1
restore_comp_level:1
bool_spkr_on:1
int_volume:7
dbl_power:50
power_limit:100
enable_power_limit:0
int_mic:1
bool_notch:0
int_notch:0
bool_shift:0
int_shift:0
pbt_lock:0
pbt_inner:0
pbt_outer:0
rfgain:79
squelch:10
no_txqsy:0
schema:0
embed_tabs:0
show_tabs:0
visible_tab:Misc
rx_avg:1
rx_peak:4
pwr_avg:1
pwr_peak:4
pwr_scale:4
sync_clock:1
sync_gmt:1
digi_sel_on_off:0
digi_sel_val:0
dual_watch:0
ic7610att:6
ft950_rg_reverse:0
line_out:0
data_port:0
vox_on_dataport:1
agc_level:0
cw_wpm:18
cw_weight:3
cw_vol:0
cw_spot:0
spot_onoff:0
cw_spot_tone:700
cw_qsk:15
cw_delay:50
enable_keyer:0
break_in:0
vox_onoff:0
vox_gain:10
vox_anti:10
vox_hang:100
compression:0
compON:0
noise_reduction:0
noise_red_val:11
nb_level:0
bool_noise:0
int_preamp:1
int_att:0
vfo_adj:0
bfo_freq:600
rit_freq:0
xit_freq:0
bpf_center:1500
use_bpf_center:1
label1:cmd 1
command1:
shftcmd1:
label2:cmd 2
command2:
shftcmd2:
label3:cmd 3
command3:
shftcmd3:
label4:cmd 4
command4:
shftcmd4:
label5:cmd 5
command5:
shftcmd5:
label6:cmd 6
command6:
shftcmd6:
label7:cmd 7
command7:
shftcmd7:
label8:cmd 8
command8:
shftcmd8:
label9:cmd 9
command9:
shftcmd9:
label10:cmd 10
command10:
shftcmd10:
label11:cmd 11
command11:
shftcmd11:
label12:cmd 12
command12:
shftcmd12:
label13:cmd 13
command13:
shftcmd13:
label14:cmd 14
command14:
shftcmd14:
label15:cmd 15
command15:
shftcmd15:
label16:cmd 16
command16:
shftcmd16:
label17:cmd 17
command17:
shftcmd17:
label18:cmd 18
command18:
shftcmd18:
label19:cmd 19
command19:
shftcmd19:
label20:cmd 20
command20:
shftcmd20:
label21:cmd 21
command21:
shftcmd21:
label22:cmd 22
command22:
shftcmd22:
label23:cmd 23
command23:
shftcmd23:
label24:cmd 24
command24:
shftcmd24:
st_label1:1
st_cmd1:
st_label2:2
st_cmd2:
st_label3:3
st_cmd3:
st_label4:4
st_cmd4:
ex_label1:1
ex_cmd1:
ex_label2:2
ex_cmd2:
ex_label3:3
ex_cmd3:
ex_label4:4
ex_cmd4:
fg_red:0
fg_green:0
fg_blue:0
bg_red:232
bg_green:255
bg_blue:232
smeter_red:0
smeter_green:180
smeter_blue:0
power_red:180
power_green:0
power_blue:0
swr_red:148
swr_green:0
swr_blue:148
peak_red:255
peak_green:0
peak_blue:0
volt_red:0
volt_green:0
volt_blue:255
display_voltmeter:1
fg_sys_red:0
fg_sys_green:0
fg_sys_blue:0
bg_sys_red:192
bg_sys_green:192
bg_sys_blue:192
bg2_sys_red:255
bg2_sys_green:255
bg2_sys_blue:255
slider_red:232
slider_green:255
slider_blue:232
slider_btn_red:0
slider_btn_green:0
slider_btn_blue:128
lighted_btn_red:255
lighted_btn_green:255
lighted_btn_blue:0
tab_red:230
tab_green:230
tab_blue:230
fontnbr:0
tooltips:0
ui_scheme:base
xmlrig_port:12345
xmlrig_addr:127.0.0.1
tcpip_port:4001
tcpip_addr:127.0.0.1
tcpip_ping_delay:50
tcpip_tcpip_reconnect_after:10
tcpip_drops_allowed:10
use_tcpip:0
tci_port:40001
tci_addr:127.0.0.1
tci_center:10
xcvr_auto_on:1
xcvr_auto_off:1
external_tuner:0
trace:0
rigtrace:0
gettrace:1
settrace:0
debugtrace:0
xmltrace:0
rpctrace:0
serialtrace:0
startstoptrace:0
tcitrace:0
rpc_level:0
f160:1805000
m160:0
txT160:0
rxT160:0
offset_160:0
oF_160:600
f80:3580000
m80:0
txT80:0
rxT80:0
offset_80:0
oF_80:600
f40:7070000
m40:0
txT40:0
rxT40:0
offset_40:0
oF_40:600
f30:10140000
m30:0
txT30:0
rxT30:0
offset_30:0
oF_30:600
f20:14070000
m20:0
txT20:0
rxT20:0
offset_20:0
oF_20:600
f17:18100000
m17:0
txT17:0
rxT17:0
offset_17:0
oF_17:600
f15:21070000
m15:0
txT15:0
rxT15:0
offset_15:0
oF_15:600
f12:24920000
m12:0
txT12:0
rxT12:0
offset_12:0
oF_12:600
f10:28070000
m10:0
txT10:0
rxT10:0
offset_10:0
oF_10:600
f6:50070000
m6:0
txT6:0
rxT_6:0
offset_6:0
oF_6:600
f2:144070000
m2:0
txT2:0
rxT2:0
offset_2:0
oF_2:600
f70:432100000
m70:0
txT70:0
rxT70:0
offset_70:0
oF_70:600
f12G:1210000000
m12G:0
txT12G:0
rxT12G:0
offset_12G:0
oF_12G:600
fgen:15000000
mgen:0
txTgen:0
rxTgen:0
offset_gen:0
oF_gen:600
hrd_buttons:1
sliders_button:1
memfontnbr:4
memfontsize:14
gpio_ptt:0
enable_gpio:0
gpio_on:0
gpio_pulse_width:0
cwioWPM:20
cwio_comp:0
cwio_keycorr:0
cwioKEYLINE:2
cwioSHARED:0
cwioPTT:0
cwioCONNECTED:0
cwioINVERTED:0
cwioPORT:
cwiolabel[0]:m2
cwiomessage[0]:
cwiolabel[1]:m2
cwiomessage[1]:
cwiolabel[2]:m3
cwiomessage[2]:
cwiolabel[3]:m4
cwiomessage[3]:
cwiolabel[4]:m4
cwiomessage[4]:
cwiolabel[5]:m6
cwiomessage[5]:
cwiolabel[6]:m7
cwiomessage[6]:
cwiolabel[7]:m8
cwiomessage[7]:
cwiolabel[8]:m9
cwiomessage[8]:
cwiolabel[9]:m10
cwiomessage[9]:
cwiolabel[10]:m11
cwiomessage[10]:
cwiolabel[11]:m12
cwiomessage[11]:
BT:=
AA:~
AS:<
AR:>
KN:%
SK:+
INT:&
HM:{
VE:}
FSK_KEYLINE:1
FSK_SHARED:0
FSK_PTT:0
FSK_CONNECTED:0
FSK_INVERTED:0
FSK_STOPBITS:1
FSK_IDLES:8
FSK_PORT:
fskiolabel[0]:m2
fskiomessage[0]:
fskiolabel[1]:m2
fskiomessage[1]:
fskiolabel[2]:m3
fskiomessage[2]:
fskiolabel[3]:m4
fskiomessage[3]:
fskiolabel[4]:m4
fskiomessage[4]:
fskiolabel[5]:m6
fskiomessage[5]:
fskiolabel[6]:m7
fskiomessage[6]:
fskiolabel[7]:m8
fskiomessage[7]:
fskiolabel[8]:m9
fskiomessage[8]:
fskiolabel[9]:m10
fskiomessage[9]:
fskiolabel[10]:m11
fskiomessage[10]:
fskiolabel[11]:m12
fskiomessage[11]:
CW_LOG_NAME:
CW_CUT_NUMBERS:0
CW_LEADING_ZEROS:0
CW_DUPCHECK:1
CW_LOG_NBR:0
FSK_LOG_NAME:
FSK_CUT_NUMBERS:0
FSK_LEADING_ZEROS:0
FSK_DUPCHECK:1
FSK_LOG_NBR:0

Thank you for any assistance.

Walter W5WEO

Environment:

flrig 2.0.05
Windows 10 Pro
Yaesu FT-450D via serial port

Summary:

When I switch between CW and LSB/USB modes using flrig on my Yaesu FT-450D, the flrig GUI bandwidth drop-down does not display the correct bandwidth: not only do they not match the bandwidth the radio is actually using, but it shows bandwidths that are not available in the drop-down. The radio is switching correctly, but the flrig GUI is not displaying correctly. This is a regression from 1.4.7, which worked correctly.

Steps to reproduce:

The radio remembers the last bandwidth used. So, I use flrig to set mode to CW and bandwidth to 300. The radio shows the narrowest bandwidth (1 notch). I now switch to LSB and set the bandwidth to 3000. The radio shows the widest bandwidth (11 notches). If I now use flrig to switch back to CW, the radio now shows 1 notch correctly. But the flrig GUI shows 1800, which is not even in the bandwidth dropdown. I have to manually set it to 300, though this doesn't actually change anything on the radio. If I now switch back to LSB, the radio now shows 11 notches correctly. But the flrig GUI shows 2400 for the bandwidth, not 3000 as it was originally set to. Once again, I have to manually set the bandwidth to 3000, which again does not change anything on the radio. If I were to repeat the switch from CW to LSB and then select 2400 from the drop-down (which is what it was already displaying) the radio does change to the narrower bandwidth.

There are similar problems when CW is set to 500 (flrig displays 2400 when you switch into CW) and 2400 (flrig displays 3000) and when LSB is set to 1800 (flrig displays 300), and 2400 (flrig displays 500). USB has the same results as LSB. DATA-L/DATA-R have similar results. I did not test other modes.

My guess at the issue:

There is a very clear pattern. For CW, there are three different widths. For LSB/USB, there are three different widths. But the frequencies for these three different widths are not the same. For CW, they are 300, 500 and 2400. For LSB/USB they are 1800, 2400 and 3000.

What seems to be happening is when flrig switches into a mode, it seems to query the radio for which bandwidth it's using, and it's getting a response. According to the 450D CAT manual, the response is just 'narrow' (00), 'normal' (16) or 'wide' (31). The problem is, the GUI code seems to be using the list of frequencies for the mode it is leaving, instead of the mode it is entering. So when we switch into CW from LSB and CW is in narrow mode, the GUI is showing 1800, which is the 'narrow' mode for LSB, the mode we just left. The same thing when we switch into LSB mode from CW: if LSB is in the widest mode, we get 2400 in the GUI, which is the 'wide' mode for CW.

Again, this is a regression from 1.4.7, which worked correctly.

Thank you very much for your time and attention. Please let me know if you would like any more information or any additional testing.

Tim
AD8JL

I never use the flrig GUI. However, I do use the flrig functionality. Is there a command line option to start flrig up minimized in Ubuntu 22.04 (and soon 24.04) or will I forever have to minimize it after I start it up from a script?
Thanks for such a great app!
-David, N9KT

When submitting the XML-RPC 'rig.get_AB' command to flrig (v1.4.4), flrig returns previously set value, even after changing the VFO using the 'rig.set_AB' command. XML-RPC trace for the typical exchange (VFO initially set to 'A' for this example):

17:58:51.483 : XmlRpcServer::acceptConnection: socket 10
17:58:51.483 : XmlRpcServer::acceptConnection: creating a connection
17:58:51.483 : XmlRpcServerConnection: new socket 10.
17:58:51.485 : XmlRpcServerConnection::readHeader: read 271 bytes.
17:58:51.485 : XmlRpcServerConnection::readHeader: read 417 bytes.
17:58:51.485 : readHeader: specified content length is 146.
17:58:51.485 : KeepAlive: 1
17:58:51.485 : readRequest:
 
<?xml version="1.0" encoding="UTF-8"?>
  <methodCall>
    <methodName>rig.set_AB
    </methodName>
    <params>
      <param>
        <value>B
        </value>
      </param>
    </params>
  </methodCall>
17:58:51.485 : XmlRpcServer::executeRequest: server calling method 'rig.set_AB'
17:58:51.485 [UNKNOWN] : set_AB  B   7110000, USB, 200, 2600
17:58:51.485 : XmlRpcServerConnection::writeResponse:
HTTP/1.1 200 OK
Server: XMLRPC++ 0.8
Content-Type: text/xml
Content-length: 110
<?xml version="1.0"?>
  <methodResponse>
    <params>
      <param>
        <value>
        </value>
      </param>
    </params>
  </methodResponse>
17:58:51.485 : writeResponse:
 HTTP/1.1 200 OK
Server: XMLRPC++ 0.8
Content-Type: text/xml
Content-length: 110
<?xml version="1.0"?>
  <methodResponse>
    <params>
      <param>
        <value>
        </value>
      </param>
    </params>
  </methodResponse>
17:58:51.511 : XmlRpcServerConnection::readHeader: read 271 bytes.
17:58:51.511 : XmlRpcServerConnection::readHeader: read 416 bytes.
17:58:51.511 : readHeader: specified content length is 145.
17:58:51.511 : KeepAlive: 1
17:58:51.511 : readRequest:
 
<?xml version="1.0" encoding="UTF-8"?>
  <methodCall>
    <methodName>rig.get_AB
    </methodName>
    <params>
      <param>
        <value>
        </value>
      </param>
    </params>
  </methodCall>
17:58:51.511 : XmlRpcServer::executeRequest: server calling method 'rig.get_AB'
17:58:51.511 [UNKNOWN] : rig_get_AB:  A
17:58:51.511 : XmlRpcServerConnection::writeResponse:
HTTP/1.1 200 OK
Server: XMLRPC++ 0.8
Content-Type: text/xml
Content-length: 111
<?xml version="1.0"?>
  <methodResponse>
    <params>
      <param>
        <value>A
        </value>
      </param>
    </params>
  </methodResponse>
17:58:51.512 : writeResponse:
 HTTP/1.1 200 OK
Server: XMLRPC++ 0.8
Content-Type: text/xml
Content-length: 111
<?xml version="1.0"?>
  <methodResponse>
    <params>
      <param>
        <value>A
        </value>
      </param>
    </params>
  </methodResponse>
17:58:51.528 : XmlRpcServerConnection::readHeader: read 0 bytes.
17:58:51.528 : readHeader: EOF
17:58:51.528 : XmlRpcSource::close: closing socket 10.
17:58:51.528 : XmlRpcSocket::close: fd 10.
17:58:51.528 : XmlRpcSource::close: deleting this
17:58:51.528 : XmlRpcServerConnection dtor.

The above was generated by submitting the two XML-RPC client requests to the flrig XML-RPC server sequentially via a Java script with no other intervening interaction with flrig. The flrig hardware radio is set to 'TS-480HX'.

NOTE: This issue will be forwarded to [email protected] and [email protected] for attention: the problem will most likely be worked there. I will update this issue with relevant info as it appears there.

Environment:

flrig 2.0.05
Windows 10 Pro
Yaesu FT-450D via serial port

Issues

Three issues:

1. Certain elements in the Configuration window do not follow the settings set in User Interface.
2. Changes to the Tab Clr setting in User Interface are not reset when you use the Reset button.
3. Can all settings in User Interface be immediately visible like the System and Tab settings are?

Details

Configuration window not following User Interface settings
I'm trying to make a 'dark mode' configuration of flrig. Basically, everything that is white I want black, and vice-versa. Here's the result after a quick and dirty change that gives reasonable results:

While the main window is usable, the Configuration window is not. The background of that window follows my new User Interface settings: it's black. The problem is, so are several other items within that window, including the list of setting pages on the left and some of the other formatting elements.

For example, here is a screenshot of the Xcvr settings page:

As you can see, the list of pages on the left is unreadable. Also, the button to the left of "Default" is invisible. The border around all of the drop-downs are also invisible. It would be nice if there were a way for them to stay visible: maybe by using the foreground color or a modification of that color (shifting the RGB slightly toward the middle)?

And here is a screenshot of the Commands settings page. The missing borders around the input boxes is very noticeable here, which makes using this screen difficult.

While working with these settings, I found a couple of somewhat- related issues, outlined below.

User Interface reset not changing tab color setting
In the User Interface dialog box, the Reset button does not reset the Tab Clr setting. I have to manually click on the Def Clr button to restore it to the original setting. Here is a screenshot, right after clicking Reset to restore (ideally) all of the settings to reverse my 'dark mode' changes. Notice now both the Tab Clr button in the User Interface window and the tab at the bottom of the main window are still black.

Only some User Interface settings are immediate
This is more of a feature request. When you make changes in the User Interface dialog, changes made to certain settings (such as the System and Tab settings) appear instantly on the main window. This is very nice: you know what you've changed and how. This really speeds up the process of finding a decent setting. The others are not: you seem to have to click OK on the main User Interface dialog box for those changes to take effect, and then go back into the User Interface window to make more changes. It would be nice if the other settings would show up immediately as well. This is even more noticeable with the Configuration window: you have to actually close that one and re-open it to get it to use the new settings.

Thank you very much for your time and attention. I really appreciate your help!

Tim
AD8JL

Hi,

Radio: Xiegu G90
Firmware: 1.79 (body), 1.80 (head)
OS: macOS Sonoma

Thanks for all the work you put into flrig.

If I upgrade beyond v1.4.7 my radio locks up when trying to use flrig. It would be nice to be able to make use of CAT control for the new digital mode settings on the G90.

Let me know if there is any specific info I can provide to help troubleshoot this.

All the best.