¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Linuxham
  2. Messages
Expanded Topics Messages Polls
Date
Re: fldigi abort witnessed - Pi 4.2.05.24

 

¿ªÔÆÌåÓý

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 utilization.
It's intermittent and during FM and HF nets. It happened to 2 different computers, new Linux and Fldigi build. I can't be sure but it may have started happening when Linux moved to Pipe Wire audio. I am using the WIKI for the Fldigi build.
I don't have any problems using Windows.

73, Ron NY3J


On 1/5/2025 10:26 PM, Bob Cameron, VK2YQA via groups.io wrote:

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 plus dmesg may also contain some clues. ie things that happened at the same time the program died.

Also possible to run fldigi from the debugger. Would be a good idea to build to the latest version first though. Buster is getting a bit old too.

Cheers Bob VK2YQA

On 6/1/25 13:45, Rick KD8WCK wrote:
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 actually looking at the display when it happened. I had entered a command, and it timed out dues to open squelch, reported that in the receive pan then immediately aborted.

Anything I can look for to help troubleshot this issue?

Re: fldigi abort witnessed - Pi 4.2.05.24

 

¿ªÔÆÌåÓý

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 plus dmesg may also contain some clues. ie things that happened at the same time the program died.

Also possible to run fldigi from the debugger. Would be a good idea to build to the latest version first though. Buster is getting a bit old too.

Cheers Bob VK2YQA

On 6/1/25 13:45, Rick KD8WCK wrote:

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 actually looking at the display when it happened. I had entered a command, and it timed out dues to open squelch, reported that in the receive pan then immediately aborted.

Anything I can look for to help troubleshot this issue?

Re: fldigi abort witnessed - Pi 4.2.05.24

 

Bad typing, sorry:

"timed out due to open squelch"

"in the receive pane"

sri de KD8WCK
fldigi abort witnessed - Pi 4.2.05.24

 

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 actually looking at the display when it happened. I had entered a command, and it timed out dues to open squelch, reported that in the receive pan then immediately aborted.

Anything I can look for to help troubleshot this issue?
Re: Call sign. K9TWC Robert Hadley. [email protected].

 

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

On Sunday, January 5, 2025 at 01:12:46 PM CST, Robert Hadley, K9TWC via groups.io <rhadley06@...> wrote:


Requesting membership. No email with call sign.





Call sign. K9TWC Robert Hadley. [email protected].

Robert Hadley, K9TWC
 

Requesting membership. No email with call sign.
Re: #fldigi #hamlib Hamlib 4.6 not working #fldigi #hamlib

 

¿ªÔÆÌåÓý

Thanks Steve

Did a git pull & build of 4.7 and 4.2.06.19 is now most happy!

Cheers Bob VK2YQA

On 5/1/25 15:55, Steve, KB5AW via groups.io wrote:

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 right
// riglist_foreach is now constant again but others are not
// #define RIGCAPS_NOT_CONST 1
?
RIGCAPS_NOT_CONST should be removed now because rig_caps has been reverted to type const.
This was still in place after rig_caps was reverted to type const, causing fldigi to fail.
?
I installed the latest Hamlib 4.7~git and reinstalled fldigi 4.2.06.19 successfully.
It is working and now listening to the ARRL RTTY roundup.
_._,_._,_
Re: #fldigi #hamlib Hamlib 4.6 not working #fldigi #hamlib

 

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 right
// riglist_foreach is now constant again but others are not
// #define RIGCAPS_NOT_CONST 1
?
RIGCAPS_NOT_CONST should be removed now because rig_caps has been reverted to type const.
This was still in place after rig_caps was reverted to type const, causing fldigi to fail.
?
I installed the latest Hamlib 4.7~git and reinstalled fldigi 4.2.06.19 successfully.
It is working and now listening to the ARRL RTTY roundup.
Re: Icom IC-7100 USB Driver

 

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 may change...) using LMDE 6 as my OS, but that (on the same previous hardware) seems to create more mayhem by enumerating things differently each time it boots, or is awoken from a sleep or hibernation.

I now have the new FTDI based serial adapters, and that port assignment mayhem at least, has now been eliminated.

Pavucontrol (in conjunction with the new pipewire audio server) even with the helper file referenced in boot config file tweaks, absolutely will not allow the renaming audio devices, that worked solidly with LMDE 5 in the past (as previously, on the exact same hardware.)

From what I can gather (online information is still varied and sketchy about pipewire) it may not even be possible to rename them at all at present.

Someone tell me different if it is possible, with a link to a site describing all that is needed please.? Not just hints that it can be done with no specifics!? ;-)


At least building Fldigi/Flrig etc, works successfully as normal.


73 and happy new year.

Dave G0WBX.


--
Created on and sent from a Unix like PC running and using open source software:
Re: Icom IC-7100 USB Driver

 

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 names. On macOS at least there is a work around using one of the system apps to give things meaningful names (something like a virtual device linked to the generically named device).
?
On Fri, Jan 3, 2025 at 04:27 AM, Philip Rose, GM3ZZA wrote:

Icom radios have serial numbers implanted in the USB Serial chips, their audio codecs are indistinguishable from USB point of view.
Re: Icom IC-7100 USB Driver

 

¿ªÔÆÌåÓý

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 view. On Linux I can configure the likes of wsjt-x to connect to what I think is the correct audio. If ever I need to reboot then the audio codecs may be named the same or they may not. It depends on the combination of radios powered on when I reboot and then the order I power them on.

It should be possible to analyse then USB connections and identify which audio codec and serial chip are on the same USB hub and keep them associated in some way, but so far it's been easier to suck it and see. If I press the tune button on wsjt-x and the target radio generates RF then the audio is connected correctly: if not, then swap the audio connections around.

73 and HNY 2025.
Phil GM3ZZA


From: [email protected] <[email protected]> on behalf of Dave, G?WBX via groups.io <g8kbvdave@...>
Sent: 03 January 2025 9:26 AM
To: [email protected] <[email protected]>
Subject: Re: [linuxham] Icom IC-7100 USB Driver
?
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 seems later ICOM radios)
as they have unique serial numbers that are convenient to use with udev
rules, giving 100% predictable device names.

If you only have one USB<>Serial device, or if more than one, they have
different chipsets (Prolific, Silicon Labs etc) you'll likely never
experience the confusion of seemingly random /dev/TTYUSB* assignments!

The problem has got worse with the newer kernels too (from observation &
experience) on the same fixed hardware on two PC's.? (Dell and HP.)

Imagine if you have a remote base with such issues, and it reboots for
some reason...

"Have Fun"!? :-)

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using open source software:
Re: Icom IC-7100 USB Driver

 

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 seems later ICOM radios) as they have unique serial numbers that are convenient to use with udev rules, giving 100% predictable device names.

If you only have one USB<>Serial device, or if more than one, they have different chipsets (Prolific, Silicon Labs etc) you'll likely never experience the confusion of seemingly random /dev/TTYUSB* assignments!

The problem has got worse with the newer kernels too (from observation & experience) on the same fixed hardware on two PC's.? (Dell and HP.)

Imagine if you have a remote base with such issues, and it reboots for some reason...

"Have Fun"!? :-)

Dave G0WBX.

--
Created on and sent from a Unix like PC running and using open source software:
Re: #fldigi #hamlib Hamlib 4.6 not working #fldigi #hamlib

 

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 may be a workaround until a permanent fix is available.
?
Re: #fldigi #hamlib Hamlib 4.6 not working #fldigi #hamlib

 

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 problem, fldigi 4.2.06.19 should build with hamlib 4.6.
?
Now flgidi has to decide whether or not to revert the hamlib changes, as hamlib will eventually make a new release with the rig_caps changes.
?
My fldigi 4.2.06.19 build is also failing because of rig_caps.
?
CTY-3501 Country Files - 02 January 2025

 

The Country (CTY) Files were updated on 02 January 2025:



For installation instructions, start at:



Hover your mouse over the word Contest in the menu, then select the
software you are using.

To install the file, follow the link to your software at the top of the page.

If you are interested in a bigger CTY.DAT for everyday logging, you can get
it here:



Note that the release notes (and Version Entity) for this larger file are
different than what is shown below. There is a separate link to them.

As a reminder, there is an RSS feed of the latest country file announcements:



Here are the release notes:

2 January 2025 (CTY-3501)
VER20250102, Version entity is Bonaire, PJ4

Added/changed Entities/Prefixes/Callsigns:

* N0VAO, W0GG, W9CTY and WD8DII are all United States, K in CQ zone 3, ITU zone 6
* N7ML is United States, K in CQ zone 4, ITU zone 6
* AI8L, K1AF, KA4RUR, KB9SCT, KF9MT, KK7TZP, KN4SLP, N2GJ, N2UR and W9BED
are all United States, K in CQ zone 4, ITU zone 7
* AE4GW, AE4M, AK4QR, K1SPD, K4CCT, KB2UQS, KD5PCK, KI5ZQZ, KN4JGH,
KO4NOL, KZ4IT, N4AER, N5DF, NT0Y, W4AUB, W4BQK, W4KAM, W4NYZ, WA6CW and WB4KUU
are all United States, K in CQ zone 4, ITU zone 8
* K5ADR, K5YDR, K7KHZ, K8VAN, KE5MHV and W7VOA are all United States, K in CQ zone 5, ITU zone 8
* N7DKL is Alaska, KL
* W4I is Puerto Rico, KP4
* R9FCS/4 and R9JAB/6/P are both European Russia, UA
* RV3DSA/0 is Asiatic Russia, UA9 in CQ zone 19, ITU zone 34

Removed Entities/Prefixes/Callsigns:

* KK4MQM/C6A in Bahamas, C6
* GB0GTS in Scotland, GM
* AA5UZ, AG2TH, AK4I, K0IE, K0NW, K0SB, K4MQM, K7UPJ, K9GS, K9OR, KA9A,
KB8KMH, KC6UCN, KH6NO, KI4BIY, KI4ZZJ, KT4DW, KU4H, N0GAF, N0MU, N7CR,
N9SZ, NH6Z, W0ZZ, W3FU, W4KD, W4PGM, W4YEM, W7HJ, W8DX, W8HOT, W8ZM, W9BS,
WA4AA, WA4USA, WB8PAF, WB9IRF and WB9PRG in United States, K
* L73HAT/H in Argentina, LU
* R100R, R100RA, R100RN, R100RP, R100RR, R100RS, R100RV and R9XD/6
in European Russia, UA
* RX9SR/2 in Kaliningrad, UA2
* R100RB, R100RE, R100RU and R7HJ/0 in Asiatic Russia, UA9

Though I am subscribed to this reflector so that I can make these
announcements, I do not see most messages posted to it. If you have
any comments or corrections to the country file, please contact me
directly.

73 - Jim AD1C

--
Jim Reisert AD1C, <jjreisert at alum.mit.edu>,

Re: #fldigi #hamlib Hamlib 4.6 not working #fldigi #hamlib

 

¿ªÔÆÌåÓý

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 ¡®void hamlib_get_rigs()¡¯:
rigcontrol/hamlib.cxx:612:26: error: invalid conversion from ¡®int (*)(rig_caps*, void*)¡¯ to ¡®int (*)(const rig_caps*, void*)¡¯ [-fpermissive]
? 612 |???????? rig_list_foreach(add_to_list, 0);
????? |????????????????????????? ^~~~~~~~~~~
????? |????????????????????????? |
????? |????????????????????????? int (*)(rig_caps*, void*)
In file included from ./include/rigclass.h:27,
???????????????? from ./include/main.h:36,
???????????????? from ./include/squelch_status.h:31,
???????????????? from ./include/status.h:29,
???????????????? from ./include/nanoIO.h:42,
???????????????? from ./include/confdialog.h:424,
???????????????? from rigcontrol/hamlib.cxx:34:
/usr/local/include/hamlib/rig.h:3794:18: note:?? initializing argument 1 of ¡®int rig_list_foreach(int (*)(const rig_caps*, void*), void*)¡¯
?3794 | rig_list_foreach HAMLIB_PARAMS((int (*cfunc)(const struct rig_caps *, rig_ptr_t),

Cheers Bob VK2YQA

On 3/1/25 08:24, Steve, KB5AW via groups.io wrote:

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 expect that this will fix fldigi hamlib control.
_._,_._,_
Re: #fldigi #hamlib Hamlib 4.6 not working #fldigi #hamlib

 

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 expect that this will fix fldigi hamlib control.
fldigi 4.2.06.19 posted for testing

 

¿ªÔÆÌåÓý

commit e8bec83905a081e385ecc14777bae7edbd8887fe
Author: dave-w1hkj <w1hkj@...>
Date:?? Wed Jan 1 20:39:59 2025 -0600

??? THOR-25
?? ?
????? * add new THOR modem with following characteristics
??????? . symlen = 320
??????? . samplerate = 8000
??????? . flushlength = 40
??????? . bandwidth = 460
??????? . interleave depth = 50, 2 second
??????? . IEEE coefficients for viterbi encode/decode algorithms
????????? THOR_K15? 15
????????? K15_POLY1 044735
????????? K15_POLY2 063057
??????? . objective to provide highest baud within 500 Hertz bandwidth for
????????? European amateurs
??????? . CPS test for THOR-25
????????? - text:
??????????? 0123456789
??????????? abcdefghijklmnopqrstuvwxyz
??????????? ABCDEFGHIJKLMNOPQRSTUVWXYZ
????????? - # chars:????? 65
????????? - overhead:???? 10.720000 sec
????????? - xmt time:???? 10.080000 sec
????????? - xmt samples:? 166400
????????? - sample rate:? 8000
????????? - chars/sec:??? 6.45
????? * assigned secondary RsID code 691 to THOR-25
????? * increased flush length for all THOR baud rates
????? * added configurable start and end of signal shaping to these modem types:
??????? . dominoEX
??????? . psk
??????? . mfsk
??????? . rtty
??????? . thor
??????? . selectable on configuration tab Modem/General
????? * restored selectable paths to all THOR modem types
????? * added individual tone shaping for all THOR modem types

Increased the interleave duration to 2 seconds.? Not compatible with earlier test versions.

73, David, W1HKJ
Re: Icom IC-7100 USB Driver

 

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 rigs.
?
On Thu, Jan 2, 2025 at 01:51 AM, Dave, G?WBX wrote:

the serial/by-id values can change, and ruin your day.
fldigi on MacOS 15.2

 

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 SystemsSetting I granted already Microphone access to fldigi without success.
?
On this net I was reading about:
?
codesign --force --deep --sign - /Applications/fldigi-4.x.xx.app
?
Event this is not revolving the matter. Any help is welcome.
?
73
?
Jens
?
581 - 600 of 54090