开云体育

Rick, I'm seeing the same issue with my Linux Mint 22 machine using Fldigi 4.2.06. Usually during a busy net Fldigi just stops. When I run TOP it tells me that Fldigi is running way above 100% CPU

Hi Rick .xsession-errors in the home directory usually contains the terminal output of any application errors. The other possibility being run fldigi from a terminal. A look at the journal or syslog

Bad typing, sorry: "timed out due to open squelch" "in the receive pane" sri de KD8WCK

I'm running fldigi 4.2.05.24 on a RaspberryPi4 on Raspbian 10 buster. The station runs 24/7 and several times a week when I remote in to the Pi I find fldigi is no longer running. This evening I was

Is that a question?Call Sign KQ5DX Email bobgroselle@... or bob.groselle@...

Requesting membership. No email with call sign.

Thanks Steve Did a git pull & build of 4.7 and 4.2.06.19 is now most happy! Cheers Bob VK2YQA

Compiling fldigi with Hamlib 4.7~git may have been resolved. On Jan 3, Hamlib made this change: #define RIGCAPS_NOT_CONST 1 // As of 2025-01-03 removeing this -- fldigi was the only one that got it

Phil. If your system reliably uses the same "device path" to reach the codec chips, then you can use that to steer things in the right direction with a couple of udev rules. I'm (currently, but that

ok, well two rigs the same is different, no one mentions two rigs until now :-) Re audio dev names, same problem on macOS with Icom and the integrated USB audio, they appear with the same generic

Have fun, indeed. The same is true for USB Audio Codecs. Although my two Icom radios have serial numbers implanted in the USB Serial chips, their audio codecs are indistinguishable from USB point of

Lonney, the issue is only a problem when one has multiple same make of USB<>Serial products showing the exact same information to the PC when enumerated. The exception being FTDI based devices (and it

I reverted to hamlib 4.6 and successfully built fldigi 4.2.06.19. It works with my Yaesu FT-890. I switched Hamlib back to version 4.7~git and fldigi 4.2.06.19 still works with my Yaesu FT-890. This

I compiled 4.2.06.17 with hamlib 4.6, which did not work, but it now works with hamlib 4.7. It is apparent that he "fixed" fldigi 4.2.06.18 for hamlib 4.6. Since the rig_caps variable is the source of

The Country (CTY) Files were updated on 02 January 2025: https://www.country-files.com/cty-3501-02-january-2025/ For installation instructions, start at: https://www.country-files.com/ Hover your

Hi Steve It actually broke my fldigi/hamlib alpha builds. ie 4.2.06.18 and 19 now fails with Hamlib 4.7~git 2024-12-29T16:43:39Z SHA=028d75 64-bit (and later) rigcontrol/hamlib.cxx: In function

Hamlib has recently reverted the change that broke fldigi hamlib control build with this comment: Change rig_list_foreach back to using const argument -- was breaking many C++ application builds I

http://www.w1hkj.com/alpha/fldigi * fldigi-4.2.06.19.dmg <http://www.w1hkj.com/alpha/fldigi/fldigi-4.2.06.19.dmg> * fldigi-4.2.06.19.tar.gz <http://www.w1hkj.com/alpha/fldigi/fldigi-4.2.06.19.tar.gz>

I'll read more into it later, I've never ever had a problem? using the sym links in /dev/serial/by-id , they always work, they always point to the right device on my Debian 12(ish) systems and Icom

Hello, I purchased a new MacMiniv M4. Now I am having the issue on my Mac when starting fldigi that I am always bothered by a pop-up message asking for Microphone access. How to overcome it? In the