Re: FLDIGI and sequoia. linux
On Sat, Dec 14, 2024 at 12:57 PM, Gary Rogers, KO3F wrote:
fldigi-4.2.06.15.zip
Thanks, Gary. I'm just now getting to it and it appears that the file has been deleted.
John AB8O
|
Re: #flrig 2.0.05 Pi3 PTT-GPIO menu?
#flrig
Please try 4.2.05.93 posted at
David
|
Re: #flrig 2.0.05 Pi3 PTT-GPIO menu?
#flrig
I am investigating
On 1/6/25 13:41, Dave, W1HKJ wrote:
toggle quoted message
Show quoted text
Are you confusing flrig and
fldigi?
David
On 1/6/25 12:56, Eric Hansen, KB1VUN
via groups.io wrote:
I just installed FLrig 2.0.05 on a Pi3B+ running Bullseye.?
WiringPi is also installed, and the gpio command works.?
?
My previous FLrig (1.3-ish) had a PTT-GPIO configuration
panel.? It didn't work for me, but I had hopes it might in
this new version.? The panel is missing altogether in the new
version.? I can select Config > Setup > PTT-GPIO, but it
just takes me to a similar menu lacking the GPIO option. ?
?
Anybody have some knowledge / wisdom to share?
?
Thanks,
Eric
|
Re: #flrig 2.0.05 Pi3 PTT-GPIO menu?
#flrig
Are you confusing flrig and
fldigi?
David
On 1/6/25 12:56, Eric Hansen, KB1VUN
via groups.io wrote:
toggle quoted message
Show quoted text
I just installed FLrig 2.0.05 on a Pi3B+ running Bullseye.?
WiringPi is also installed, and the gpio command works.?
?
My previous FLrig (1.3-ish) had a PTT-GPIO configuration
panel.? It didn't work for me, but I had hopes it might in this
new version.? The panel is missing altogether in the new
version.? I can select Config > Setup > PTT-GPIO, but it
just takes me to a similar menu lacking the GPIO option. ?
?
Anybody have some knowledge / wisdom to share?
?
Thanks,
Eric
|
#flrig 2.0.05 Pi3 PTT-GPIO menu?
#flrig
I just installed FLrig 2.0.05 on a Pi3B+ running Bullseye.? WiringPi is also installed, and the gpio command works.?
?
My previous FLrig (1.3-ish) had a PTT-GPIO configuration panel.? It didn't work for me, but I had hopes it might in this new version.? The panel is missing altogether in the new version.? I can select Config > Setup > PTT-GPIO, but it just takes me to a similar menu lacking the GPIO option. ?
?
Anybody have some knowledge / wisdom to share?
?
Thanks,
Eric
|
It¡¯s who I am as there was not a place for a call sign at registration if call sign was not embedded in your email address. I¡¯m a newer Linux user but trying to go there and end the use of Windows. So I¡¯m looking for a resource for amateur radio software for a Linux help group. If this isn¡¯t what your group is then please disregard and I¡¯m sorry to bother you. Be well K9TWC.?
toggle quoted message
Show quoted text
On Jan 5, 2025, at 4:37?PM, Bob Groselle, KQ5DX via groups.io <bobgroselle@...> wrote:
?
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.
|
Re: fldigi abort witnessed - Pi 4.2.05.24
Rule out:
?
1) RFI. Nearly all problems with this setup are RFI until proven otherwise, including the RF from your antenna being too close to the computer (or battery sometimes).?
2) Vibration or movement of the computer-radio interface cable.
3) Static electricity sources
4) Aging micro SD card in the pi
5) Check uptime to verify if fldigi is crashing or if the computer is just power cycling.
?
|
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:
toggle quoted message
Show quoted text
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:
toggle quoted message
Show quoted text
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?
|
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.
|
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
On 5/1/25 15:55, Steve, KB5AW via
groups.io wrote:
toggle quoted message
Show quoted text
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.
_._,_._,_
|
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
toggle quoted message
Show quoted text
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:
|
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.
?
|
Dave, W1HKJ
Drew, KG7YSX
Ron NY3J
Philip Rose, GM3ZZA