search

drowe67 / freedv-gui

GUI Application for FreeDV – open source digital voice for HF radio
https://freedv.org/
GNU Lesser General Public License v2.1
209 stars 52 forks source link

1.9.5-devel/Report Frequency sets only MHz #594

Closed OH1KH closed 1 year ago

OH1KH commented 1 year ago

Main window/Report Frequency sets only full MHz when frequency is selected from combo box. I.E. selecting 14,2360 will set rig to 14,0000 21,313 wil set rig to 21,0000

and so on... Rigctld started from script (linux) and rig model set to -m2 with FreeDV

rigctld Hamlib 4.6~git 2023-10-31T03:53:13Z SHA=fb03d0 64-bit

rig IC7300

Tyrbiter commented 1 year ago

What does 'locale' report from the command line on your system?

vwpolo16 commented 1 year ago

I have a similar problem with the 1.9.5-devel. I have a Kenwood TS850 that is connected via the Rig Model "Hamlib Net rigctl" and as serial Device "localhost:4532". In this configuration I get no frequency report in the GUI. When I type in a new frequency eg. 14,220 and press enter it sets the transceiver to 14.000MHz. But when I type in 14.220 and press enter it sets the frequency to 14.200MHz. So there is a mixup between "dot" and "comma" as decimal separator. So with Rig Model "Hamlib Net rigctl" I have to use the "dot" as decimal seperator. When I use the Rig Model "Kenwood TS850" with 4800 baud, then the frequency reporting is working. But now I have to use the "comma" as decimal separator. But Rig Model "Kenwood TS850" is not an option for me because I have to deliver the frequency information also to my logbook program and to my RFKit PA. Therefor I need the "Hamlib Net rigctl" as Rig Model.

I also assume that the problem with no frequency reading vor the Rig Model "Hamlib Net rigctl" is related to this different use of "dot" and "comma".

rigctl -m 2 -r localhost:4532 Linux Mint 19.3

tmiw commented 1 year ago

Yeah, this should have been fixed in https://github.com/drowe67/freedv-gui/pull/561 and https://github.com/drowe67/freedv-gui/pull/509. A few questions for @vwpolo16 and @OH1KH:

  1. Do you see this issue in 1.9.4?
  2. Per @Tyrbiter, what's the output of the locale command? I can try forcing FreeDV to use that locale and see if I can duplicate.
vwpolo16 commented 1 year ago

Hello tmiw, also in 1.9.4 together with rig model "Hamlib Net rigctl" I have a similar behaviour. When I select a frequency in the drop list it goes to the full MHz, e.g. I click on 7.177 it goes to 7.000MHz. But frequency reporting works fine and it follows the frequency when I tune on the radio wheel. Frequency can be entered only with the decimal "dot" and very fast due to the fast frequency reading.

If I chose the rig model "Kenwood TS850" then I can select a frequency from the drop list an it sets also the kHz, e.g when I click on 21.3130 it really commands the transceiver to that frequency. And if I am able to enter manually a new frequency very fast then I need the "comma" as decimal separator. Frequency reporting also works

vwpolo16 commented 1 year ago

If you choose kHz instead of MHz in the GUI, than you could avoid this problem.

tmiw commented 1 year ago

Looks like I'm able to duplicate with locale fr_FR.utf8. See https://github.com/drowe67/freedv-gui/pull/595 for a solution.

vwpolo16 commented 1 year ago

manfred@Cubi-5:~$ locale LANG=de_DE.UTF-8 LANGUAGE=de_DE LC_CTYPE="de_DE.UTF-8" LC_NUMERIC="de_DE.UTF-8" LC_TIME="de_DE.UTF-8" LC_COLLATE="de_DE.UTF-8" LC_MONETARY="de_DE.UTF-8" LC_MESSAGES="de_DE.UTF-8" LC_PAPER="de_DE.UTF-8" LC_NAME="de_DE.UTF-8" LC_ADDRESS="de_DE.UTF-8" LC_TELEPHONE="de_DE.UTF-8" LC_MEASUREMENT="de_DE.UTF-8" LC_IDENTIFICATION="de_DE.UTF-8" LC_ALL=

tmiw commented 1 year ago

Thanks! Have you tried the code changes in #595 to confirm that the issue is fixed for you?

OH1KH commented 1 year ago

It must be locale problem. I do not have time to test latest , but yesterday compiled 1.9.5 shows everything with commas, not with dots that I assume is the right separator. image

tmiw commented 1 year ago

It must be locale problem. I do not have time to test latest , but yesterday compiled 1.9.5 shows everything with commas, not with dots that I assume is the right separator.

That part is correct as we really should be trying to match the user's locale as much as possible for display and data entry. Internally, FreeDV converts to Hz prior to sending to Hamlib, so no decimals involved there.

vwpolo16 commented 1 year ago

Hello tmiw, I tried to compile "ms-freq-locale" but this was not possible. After 2 hours I get the following error:

manfred@Cubi-5:~$ cd freedv_1_9_5_ms-freq-locale/ manfred@Cubi-5:~/freedv_1_9_5_ms-freq-locale$ cd freedv-gui manfred@Cubi-5:~/freedv_1_9_5_ms-freq-locale/freedv-gui$ ./build_linux.sh pulseaudio

-- Compilation date = XX20231101XX -- Configuring done -- Generating done -- Build files have been written to: /home/manfred/freedv_1_9_5_ms-freq-locale/freedv-gui/LPCNet/build_linux

CMakeFiles/build_sioclient.dir/build.make:97: recipe for target 'build_sioclient-prefix/src/build_sioclient-stamp/build_sioclient-download' failed make[2]: [build_sioclient-prefix/src/build_sioclient-stamp/build_sioclient-download] Error 1 make[2]: Verzeichnis „/home/manfred/freedv_1_9_5_ms-freq-locale/freedv-gui/build_linux“ wird verlassen CMakeFiles/Makefile2:293: recipe for target 'CMakeFiles/build_sioclient.dir/all' failed make[1]: [CMakeFiles/build_sioclient.dir/all] Error 2 make[1]: Verzeichnis „/home/manfred/freedv_1_9_5_ms-freq-locale/freedv-gui/build_linux“ wird verlassen Makefile:155: recipe for target 'all' failed make: *** [all] Error 2 manfred@Cubi-5:~/freedv_1_9_5_ms-freq-locale/freedv-gui$ manfred@Cubi-5:~/freedv_1_9_5_ms-freq-locale/freedv-gui$

tmiw commented 1 year ago

It sounds like you might have had a network issue preventing the build from cloning additional required repos. Try again?

vwpolo16 commented 1 year ago

Hello tmiw, today I could successfully compile "freedv 1.9.5-devel ms-freq-locale". But it works only in some parts: Rig model "Kenwood TS-850": frequency from the combo box can be selected (e.g. click on 21,313 sets the transceiver to 21,313MHz. A new frequency can be entered with the "comma" from the number key block e.g. 7,064 sets the transceiver to 7,064MHz. But frequency reporting from the transceiver when I turn the frequency wheel only works sometimes. Sometimes mean it can take 1 minute until the frequency is updated, or sometimes only 5 seconds and sometimes never.

Rig Model "Hamlib NET rigctl": Here the frequency report back from the transceiver never works. But I can select new frequencies from the combo box and also enter manually a new frequency with the "comma" from the number key block and this works.

tmiw commented 1 year ago

There's logic to prevent updates from the radio as long as the frequency text box has focus (intended to avoid overwriting users' entry as they're entering it). I suspect that clicking in the box and then clicking somewhere else (like one of the tabs in the main window) will cause updates to start happening every 5 seconds again.

Also, there are some changes in https://github.com/drowe67/freedv-gui/pull/596 that impact this as well. I'll go ahead and merge #595 in now and then merge master down to #596 in case that helps.

vwpolo16 commented 1 year ago

Hi tmiw, you are right. "I suspect that clicking in the box and then clicking somewhere else (like one of the tabs in the main window) will cause updates to start happening every 5 seconds again." I tried this with rig model "Hamlib NET rigctl" and now the frequency is read back from the tranceiver every 5 s. But after a few frequency changes on the transceiver it shows now 0,0027MHz and this frequency is not updated anymore, even not when I select a new frequency from the combo box. After a stop - start it works again.

tmiw commented 1 year ago

How many times do you think you had to change frequency before you ran into that problem? With a Flex 6300 ("Kenwood TS-2000" in FreeDV), I changed it from within SmartSDR around 10 or so times and didn't see any issues. I'm not running Hamlib 4.6, though, just the version of 4.5.5 that gets built into the macOS binary.

That said, I did notice a few commits in Hamlib 4.6 after the one you grabbed that do impact Kenwoods (https://github.com/Hamlib/Hamlib/commit/6cb17e49dcf1219d9c44b684356797128daf4209 and https://github.com/Hamlib/Hamlib/commit/f4f4d122a850bd2cffe586a2850b45fc5fa1b6ca) so pulling the latest Hamlib from GitHub might help.