Re: QtSoundModem: you may be able to compile from source.

开云体育

correction

sudo apt install libasound2-dev

Op 22-1-2025 om 14:31 schreef Niels PD9Q:

sudo apt install libasound-dev

Op 22 jan 2025 om 13:45 heeft Chuck Gelm <nc8q-aredn@...> het volgende geschreven:

?I am trying to install QtSoundModem on a 'new' linux laptop.

sudo apt-get install libqt5serialport5-dev libfftw3-dev libpulse-dev
[sudo] password for gelmce:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libqt5serialport5-dev is already the newest version (5.15.13-1).
libfftw3-dev is already the newest version (3.3.10-1ubuntu3).
libpulse-dev is already the newest version (1:16.1+dfsg1-2ubuntu10.1).
0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded.

Then download , unzip and run qmake then make
unzip QtSMSource.zip
cd QtSoundModem/
qmake
make <--- lots of warnings

ALSASound.c:36:10: fatal error: alsa/asoundlib.h: No such file or directory
   36 | #include <alsa/asoundlib.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:574: ALSASound.o] Error 1

apt install alsasound
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package alsasound

apt install alsa
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'alsa-base' instead of 'alsa'
alsa-base is already the newest version (1.0.25+dfsg-0ubuntu7).
0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded.
gelmce@hp-small:~/Downloads/QtSoundModem$ apt install alsalib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package alsalib
gelmce@hp-small:~/Downloads/QtSoundModem$ apt install asoundlib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package asoundlib

Re: QtSoundModem: you may be able to compile from source.

#42994

sudo apt install libasound-dev

Show quoted text

Op 22 jan 2025 om 13:45 heeft Chuck Gelm <nc8q-aredn@...> het volgende geschreven:

?I am trying to install QtSoundModem on a 'new' linux laptop.

sudo apt-get install libqt5serialport5-dev libfftw3-dev libpulse-dev
[sudo] password for gelmce:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libqt5serialport5-dev is already the newest version (5.15.13-1).
libfftw3-dev is already the newest version (3.3.10-1ubuntu3).
libpulse-dev is already the newest version (1:16.1+dfsg1-2ubuntu10.1).
0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded.

Then download , unzip and run qmake then make
unzip QtSMSource.zip
cd QtSoundModem/
qmake
make <--- lots of warnings

ALSASound.c:36:10: fatal error: alsa/asoundlib.h: No such file or directory
   36 | #include <alsa/asoundlib.h>
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:574: ALSASound.o] Error 1

apt install alsasound
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package alsasound

apt install alsa
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'alsa-base' instead of 'alsa'
alsa-base is already the newest version (1.0.25+dfsg-0ubuntu7).
0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded.
gelmce@hp-small:~/Downloads/QtSoundModem$ apt install alsalib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package alsalib
gelmce@hp-small:~/Downloads/QtSoundModem$ apt install asoundlib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package asoundlib

QtSoundModem: you may be able to compile from source.

#42993

I am trying to install QtSoundModem on a 'new' linux laptop.

sudo apt-get install libqt5serialport5-dev libfftw3-dev libpulse-dev
[sudo] password for gelmce:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
libqt5serialport5-dev is already the newest version (5.15.13-1).
libfftw3-dev is already the newest version (3.3.10-1ubuntu3).
libpulse-dev is already the newest version (1:16.1+dfsg1-2ubuntu10.1).
0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded.

Then download , unzip and run qmake then make
unzip QtSMSource.zip
cd QtSoundModem/
qmake
make <--- lots of warnings

ALSASound.c:36:10: fatal error: alsa/asoundlib.h: No such file or directory
?? 36 | #include <alsa/asoundlib.h>
????? |????????? ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:574: ALSASound.o] Error 1

apt install alsasound
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package alsasound

apt install alsa
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'alsa-base' instead of 'alsa'
alsa-base is already the newest version (1.0.25+dfsg-0ubuntu7).
0 upgraded, 0 newly installed, 0 to remove and 104 not upgraded.
gelmce@hp-small:~/Downloads/QtSoundModem$ apt install alsalib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package alsalib
gelmce@hp-small:~/Downloads/QtSoundModem$ apt install asoundlib
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package asoundlib

./QtSoundModem -v,-bash: ./QtSoundModem: cannot execute: required file not found

#42992

I downloaded QtSoundModem Binary for x86 Linux systems

chmod +x QtSoundModem
./QtSoundModem
-bash: ./QtSoundModem: cannot execute: required file not found

Re: QtSoundModem on a separate host: changing radios

#42991

Update 20250121 2300Z

BPQ/QtSoundModem +IC-7100 +IC-7300
has PTT on the IC-7300 but no RF output
is decoding on the IC-7100.

I am going to add another laptop QtSoundModem instance hopefully to segregate issues.
The IC-7100 fails to TX on HF, but did work on 2m VHF FM.

73, Chuck

Re: QtSoundModem on a separate host: changing radios

#42990

On Tue, Jan 21, 2025 at 1:22?PM Chuck Gelm via <nc8q-aredn=[email protected]> wrote:

Hi, Lee:

Many thanks.

For ~2 years, the only think I have in the 'rig control area of bpq32.cfg' is

RADIO 1
HAMLIB # IP address of QtSoundModem (my tiny x86 laptop).

For ~2 years before that I ran QtSoundModem on the same RPI as pilinbpq:

RADIO 1
HAMLIB # IP address of pilinbpq (RPI)
-----

In
rigctld -vv -m 3073 -s 19200 -r /dev/ttyUSB73 -T 10.78.196.98 F 7101000 M PKTUSB 3000
I thought '-m 3073' pulls the '94h' from a rigctld library for my IC-7300 like my previous
rigctld -vv -m 3070 -s 19200 -r /dev/ttyUSB71A -T 10.78.196.98 F 7101300 M PKTUSB 3000
pulled '88h' from a rigctld library for the IC-7100.

Is it rigctld/QtSoundModem on the laptop that needs to know the C-IV port and not bpq32.cfg on the RPI?

I am going to set some 'styling' on my coding so that is looks different than my comments.
?
73, Chuck

OK Chuck, so now I know you were using hamlib with the 7100. There are different ways to get this to work actually. Continuing to use hamlib is probably the most straightforward path, which is what Niels was pointing to. He had a better crystal ball than I did with respect to what you were already doing with the 7100. In your rigctld, 3073 looks like it is the right number for the 7300, and Niels' example matches that.

> Is it rigctld/QtSoundModem on the laptop that needs to know the C-IV port and not bpq32.cfg on the RPI?

?

Yes, rigctld needs to know the C-IV port and not BPQ in this case. QtSM uses hamlib as Niels example showed.

?

73,

Lee K5DAT

Re: QtSoundModem on a separate host: changing radios

#42989

开云体育

Update 20250121 19:41 UTC:

rpi-model3B:
bpq32.cfg:
...
HAMLIB 10.78.196.98:4532 ; <---- I think QtSoundModem picks up C-IV from 'rigctld -m 3073' parameter...not from bpq32.cfg. ???
00:00
99,3.5957,USB-D,F1,D
11:59
99,7.101,USB-D,F1,D
16:00
99,14.102,USB-D,F1,D
20:00
99,7.101,USB-D,F1,D
****
...
The Icom IC-7300 is following the 'RADIO 1' commands from BPQ
and apparently switching from Rx to Tx and back when executing
'Mail for:' and forwarding scripts, although no TX/audio is heard.
-----
tiny x86 laptop:
In separate command terminals:

Terminal A:
#IC-7100
#rigctld -vv -m 3070 -s 19200 -r /dev/ttyUSB71A -T 10.78.196.98 F 7101300 M PKTUSB 3000
#
#IC-7300
rigctld -vv -m 3073 -s 19200 -r /dev/ttyUSB73 -T 10.78.196.98 F 7101000 M PKTUSB 3000

Terminal B:
QtSoundModem64

Terminal C:
sudo x11vnc -passwd blahblahblah -many -display :0
-----

QtSoundModem:
Still no TX/RF/audio, but
the GUI is displaying and decoding from the IC-7100 if it is turned on! <---- ?
Else, if the IC-7100 is off, QtSoundModem waterfall is blank.

There is no RX/audio output from the IC-7300 while monitoring with the IC-7100 or a Kenwood TS-50.
QtSoundModem displays TX data from BPQ, radio PTT works, but no apparent RF/audio.

Issues:

PTT, but no RF/audio out from QtSoundModem.
No waterfall indication so no audio in from IC-7300 to QtSoundModem.

73, Chuck

Re: QtSoundModem on a separate host: changing radios

#42988

On 1/21/25 13:18, Niels PD9Q wrote:
[Init]
CM108Addr=
DispMode=1
DualChan=1
DualPTT=1
FLRigHost=127.0.0.1
FLRigPort=12345
HamLibHost=44.137.31.76
HamLibPort=4532
MinimizetoTray=0
PTT=HAMLIB
PTTBAUD=19200
PTTMode=17
PTTOffString=
PTTOnString=
RXSampleRate=12000
SCO=1
SndRXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"
SndTXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"
SoundMode=0
TXPort=8884
TXRotate=0
TXSampleRate=12000
UDPClientPort=8888
UDPHost=127.0.0.1\n
UDPServer=0
UDPServerPort=8884
WaterfallMax=3300
WaterfallMin=0
Wisdom=(fftw-3.3.8 fftwf_wisdom #x4a633eef #xb5a95564 #x91014bdd #x9c85ce5f\n? (fftwf_codelet_n1fv_3_neon 0 #x30bff #x30bff #x0 #xd8eb4fc2 #xb4b7ddcb #xc648e13b #x97a64eef)\n (fftwf_dft_vrank_geq1_register 0 #x30bff #x30bff #x0 #x86ba2fc3 #xd9d37881 #xffbbb400 #x20032685)\n (fftwf_dft_vrank_geq1_register 0 #x30bff #x30bff #x0 #xb1615290 #x725e2d62 #xa4c41a4d #x764c835f)\n? (fftwf_codelet_t1fuv_6_neon 0 #x30bff #x30bff #x0 #xa1dae1f9 #xcf4175ca #x165c93d4 #x431b4b4f)\n? (fftwf_dft_vrank_geq1_register 0 #x31bff #x31bff #x0 #x51999523 #x06be4b5b #xc7d1dd51 #x53b6199d)\n (fftwf_rdft_rank0_register 2 #x31bff #x31bff #x0 #xff75c762 #x3a0ee093 #x5b78d592 #x6b6be60e)\n? (fftwf_codelet_t1fv_3_neon 0 #x30bff #x30bff #x0 #xf6ecde88 #x78652c9c #xfb4aeade #xb66f7fb6)\n? (fftwf_codelet_t3fv_16_neon 0 #x31bff #x31bff #x0 #x466cbe30 #x384c6da7 #x95d87b8c #xe3cecc25)\n (fftwf_dft_r2hc_register 0 #x31bff #x31bff #x0 #xe57fac2b #x1a805e91 #x77bebbbf #xc7df4f55)\n? (TIMEOUT 0 #x1040 #x11bdd #x11c #xd124ca6c #xeb82cd90 #x28cd6189 #x0412976b)\n (fftwf_dft_bluestein_register 0 #x31bff #x31bff #x0 #x95391a46 #xf3b5f154 #x7e4c9611 #x9c236d23)\n? (fftwf_dft_nop_register 0 #x31bff #x31bff #x0 #xdf288e01 #x21687a96 #xf5aa97df #x2b6cb1e3)\n? (fftwf_dft_buffered_register 1 #x31bff #x31bff #x0 #x48f7cedd #x5ddc4b78 #xe6834056 #xf22ff7fa)\n)\n
darkTheme=false
multiCore=1
onlyMixSnoop=false
pttGPIOPin=17
pttGPIOPinR=17
txLatency=50
useKISSControls=falseHi, Niels:

I ran a diff from 'Init' through UDPServerPort:
You are '<', I am '>'.
diff 0 1
2c2
< CM108Addr=
---
CM108Addr=/dev/hidraw0 ; I wonder if this should be void or '/dev/hidraw1' ?
4d3
< DualChan=1 ; You do not use this.
8c7
< HamLibHost=44.137.31.76
---
HamLibHost=10.78.196.98 ; These IP addresses look good to me.10c9
< MinimizetoTray=0
---
MinimizetoTray=115c14
< PTTOnString=
---
PTTOnString=10.78.196.98 ; My PTT command goes elsewhere.17,19c16,18
< SCO=1
< SndRXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"
< SndTXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"
---
SCO=0
SndRXDeviceName="hw:2,0 USB Audio(USB Audio CODEC)"
SndTXDeviceName="hw:2,0 USB Audio(USB Audio CODEC)"25c24
< UDPHost=127.0.0.1\n
---
UDPHost=192.168.1.255 ; I am not sure about this value. If this is 'UDP Sound Server', mine is not enabled. ?
28,30c27,29

73, Chuck

Re: QtSoundModem on a separate host: changing radios

#42987

开云体育

On 1/21/25 11:37, Lee Bengston via groups.io wrote:

GM Chuck,
On Tue, Jan 21, 2025 at 10:00?AM Chuck Gelm via <nc8q-aredn=[email protected]> wrote:

My IC-7100 stopped transmitting power.
I want to use my IC-7300 in its place.
I have been running pilinbpq (on a rpi;-) since December 2020 and
QtSoundModem64 on a tiny x86 laptop for about 2 years.
I am no longer familiar with how to select my radio's serial port;
/dev/ttyUSB73 .

'aplay -l/arecord -l' reports my IC-7300 on "Card 2" ("hw:2,0" ?).
My IC-7100 was "Card 1" ("hw:1,0 ?)

I cannot find a reference to "/dev/ttyUSB" nor "hw:#,0" in QtSoundModem.ini.

I found a previous reference to "hw:1,0" in
(GUI) QtSoundModem64 -> Settings -> Setup Devices -> Dialog -> Sound Card.
I changed that to 'hw:2,0'.

That should be correct for the sound device in QtSM based on what was reported via aplay and arecord.

BPQ did set my IC-7300 to 7.101 MHz, so maybe something is working.

My IC-7100 uses CI-V address 88h, my IC-7300 uses CI-V address 94h.
Where to I edit this setting?

That should be in the rig control area in bpq32.cfg. Assuming you are using the "new method" per , you would need a line like this for the IC7300, and there should be an old one for the IC7100. I'm assuming /dev/ttyUSB73 is the serial port for CAT control on the 7300.
RADIO 1
/dev/ttyUSB73 9600 ICOM IC7300 94
For the most part I don't know either radio, but I do know that the 7300 has built-in sound. Based on what you mentioned above, it sounds like the 7100 does also. I'm not sure how you had PTT set up in QtSM with the 7100. With QtSM running on a different machine than BPQ, it can be set to use Hamlib for PTT, which will connect to BPQ's hamlib emulator. Then QtSM's PTT via hamlib is converted by BPQ to CAT commands for PTT. In that case the rig control line would need to include invoking the hamlib emulator:
RADIO 1
/dev/ttyUSB73 9600 ICOM IC7300 94 HAMLIB=4532
- and QtSM will need to be set to use hamlib for PTT using the IP address of the BPQ machine.
For all I know you may already be using the hamlib method with the 7100 given QtSM and BPQ are on separate computers.

73,
Lee K5DAT

Hi, Lee:

Many thanks.

For ~2 years, the only think I have in the 'rig control area of bpq32.cfg' is

RADIO 1
HAMLIB 10.78.196.98:4532 # IP address of QtSoundModem (my tiny x86 laptop).

For ~2 years before that I ran QtSoundModem on the same RPI as pilinbpq:

RADIO 1
HAMLIB 10.174.162.40:4532 # IP address of pilinbpq (RPI)
-----

In
rigctld -vv -m 3073 -s 19200 -r /dev/ttyUSB73 -T 10.78.196.98 F 7101000 M PKTUSB 3000
I thought '-m 3073' pulls the '94h' from a rigctld library for my IC-7300 like my previous
rigctld -vv -m 3070 -s 19200 -r /dev/ttyUSB71A -T 10.78.196.98 F 7101300 M PKTUSB 3000
pulled '88h' from a rigctld library for the IC-7100.

Is it rigctld/QtSoundModem on the laptop that needs to know the C-IV port and not bpq32.cfg on the RPI?

I am going to set some 'styling' on my coding so that is looks different than my comments.
?
73, Chuck

Re: ARDOPCF and QtSoundModem?

#42986

Works well now for me too on both x86 and x64. Thank you John!

73 de Rich WA3WLH

Re: QtSoundModem on a separate host: changing radios

#42985

开云体育

Hi Chuck,

Qtsoundmodem running on different machine. 44.137.31.76

QtSoundModem.ini

[Init]
CM108Addr=
DispMode=1
DualChan=1
DualPTT=1
FLRigHost=127.0.0.1
FLRigPort=12345
HamLibHost=44.137.31.76
HamLibPort=4532
MinimizetoTray=0
PTT=HAMLIB
PTTBAUD=19200
PTTMode=17
PTTOffString=
PTTOnString=
RXSampleRate=12000
SCO=1
SndRXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"
SndTXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"
SoundMode=0
TXPort=8884
TXRotate=0
TXSampleRate=12000
UDPClientPort=8888
UDPHost=127.0.0.1\n
UDPServer=0
UDPServerPort=8884
WaterfallMax=3300
WaterfallMin=0
Wisdom=(fftw-3.3.8 fftwf_wisdom #x4a633eef #xb5a95564 #x91014bdd #x9c85ce5f\n? (fftwf_codelet_n1fv_3_neon 0 #x30bff #x30bff #x0 #xd8eb4fc2 #xb4b7ddcb #xc648e13b #x97a64eef)\n? (fftwf_dft_vrank_geq1_register 0 #x30bff #x30bff #x0 #x86ba2fc3 #xd9d37881 #xffbbb400 #x20032685)\n? (fftwf_dft_vrank_geq1_register 0 #x30bff #x30bff #x0 #xb1615290 #x725e2d62 #xa4c41a4d #x764c835f)\n? (fftwf_codelet_t1fuv_6_neon 0 #x30bff #x30bff #x0 #xa1dae1f9 #xcf4175ca #x165c93d4 #x431b4b4f)\n? (fftwf_dft_vrank_geq1_register 0 #x31bff #x31bff #x0 #x51999523 #x06be4b5b #xc7d1dd51 #x53b6199d)\n? (fftwf_rdft_rank0_register 2 #x31bff #x31bff #x0 #xff75c762 #x3a0ee093 #x5b78d592 #x6b6be60e)\n? (fftwf_codelet_t1fv_3_neon 0 #x30bff #x30bff #x0 #xf6ecde88 #x78652c9c #xfb4aeade #xb66f7fb6)\n? (fftwf_codelet_t3fv_16_neon 0 #x31bff #x31bff #x0 #x466cbe30 #x384c6da7 #x95d87b8c #xe3cecc25)\n? (fftwf_dft_r2hc_register 0 #x31bff #x31bff #x0 #xe57fac2b #x1a805e91 #x77bebbbf #xc7df4f55)\n? (TIMEOUT 0 #x1040 #x11bdd #x11c #xd124ca6c #xeb82cd90 #x28cd6189 #x0412976b)\n? (fftwf_dft_bluestein_register 0 #x31bff #x31bff #x0 #x95391a46 #xf3b5f154 #x7e4c9611 #x9c236d23)\n? (fftwf_dft_nop_register 0 #x31bff #x31bff #x0 #xdf288e01 #x21687a96 #xf5aa97df #x2b6cb1e3)\n? (fftwf_dft_buffered_register 1 #x31bff #x31bff #x0 #x48f7cedd #x5ddc4b78 #xe6834056 #xf22ff7fa)\n)\n
darkTheme=false
multiCore=1
onlyMixSnoop=false
pttGPIOPin=17
pttGPIOPinR=17
txLatency=50
useKISSControls=false

Use hamlib for TX (also on the qtsoundmodem machine, there is where your ic7300 is connected)

/usr/local/bin/rigctld -m 3073 -r /dev/ttyUSB0 -s 19200 -T 44.137.31.76 -t 4532

On my BPQ32 machine

bqp32.cfg

; My Radio Number 1 that automatically switches bands and updates frequency every 5 seconds
RADIO 1
HAMLIB 44.137.31.76:4532
00:00
5,14.102300,USB,F1,D,P123
06:00
5,7.049450,USB,F1,D,P123
19:00
5,14.102300,USB,F1,D,P123
****

Running QtSoundModem and bpq32 on the same machine

HamLibHost=44.137.31.70
HamLibPort=4532
PTT=HAMLIB
SndRXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"
SndTXDeviceName="hw:1,0 USB Audio(USB Audio CODEC)"

bpq32.cfg

; My Radio Number 1 that automatically switches bands and updates frequency every 5 seconds
RADIO 1
/dev/ttyUSB0 19200 ICOM IC7300 94 PTT_SETS_INPUT AUX HAMLIB=4532
00:00
5,14.102300,USB,F1,D,P123
06:00
5,7.049450,USB,F1,D,P123
19:00
5,14.102300,USB,F1,D,P123
****

The above works well for me.

73 Niels PD9Q

Op 21-1-2025 om 17:00 schreef Chuck Gelm:

Show quoted text

My IC-7100 stopped transmitting power.
I want to use my IC-7300 in its place.
I have been running pilinbpq (on a rpi;-) since December 2020 and
QtSoundModem64 on a tiny x86 laptop for about 2 years.
I am no longer familiar with how to select my radio's serial port; /dev/ttyUSB73 .

'aplay -l/arecord -l' reports my IC-7300 on "Card 2" ("hw:2,0" ?).
My IC-7100 was "Card 1" ("hw:1,0 ?)

I cannot find a reference to "/dev/ttyUSB" nor "hw:#,0" in QtSoundModem.ini.

I found a previous reference to "hw:1,0" in
(GUI) QtSoundModem64 -> Settings -> Setup Devices -> Dialog -> Sound Card.
I changed that to 'hw:2,0'.

BPQ did set my IC-7300 to 7.101 MHz, so maybe something is working.

My IC-7100 uses CI-V address 88h, my IC-7300 uses CI-V address 94h.
Where to I edit this setting?

73, Chuck

Re: QtSoundModem on a separate host: changing radios

#42984

BPQ controls the radio, so you set CI-V address and serial port in the Radio or RigConfig sections of bpq32.cfg.

In QtSM change the Sound Card setting to match your new hw: number.

73, John

Show quoted text

On 21/01/2025 16:00, Chuck Gelm wrote:
My IC-7100 stopped transmitting power.
I want to use my IC-7300 in its place.
I have been running pilinbpq (on a rpi;-) since December 2020 and
QtSoundModem64 on a tiny x86 laptop for about 2 years.
I am no longer familiar with how to select my radio's serial port; /dev/ttyUSB73 .

'aplay -l/arecord -l' reports my IC-7300 on "Card 2" ("hw:2,0" ?).
My IC-7100 was "Card 1" ("hw:1,0 ?)

I cannot find a reference to "/dev/ttyUSB" nor "hw:#,0" in QtSoundModem.ini.

I found a previous reference to "hw:1,0" in
(GUI) QtSoundModem64 -> Settings -> Setup Devices -> Dialog -> Sound Card.
I changed that to 'hw:2,0'.

BPQ did set my IC-7300 to 7.101 MHz, so maybe something is working.

My IC-7100 uses CI-V address 88h, my IC-7300 uses CI-V address 94h.
Where to I edit this setting?

73, Chuck

Re: ARDOPCF and QtSoundModem?

#42983

开云体育

Hi

This works very well for me, I don't notice any performance change either. Works perfectly with the original source and the snoop/mix.

Thanks.

73 Niels

Op 21-1-2025 om 17:57 schreef John G8BPQ via groups.io:

Show quoted text

With both the latest master and develop branches removing the call to? snd_pcm_hw_params_set_period_size_near fixes the sharing problem for me. This is in ALSASound.c or ALSA.c depending on the version.

I haven't noticed any difference in performance compared with using the original source and not using snoop/mix.

73, John

On 05/01/2025 20:44, Rich Sahlender via groups.io wrote:

Hi Niels,

Thanks for the feedback. I have spent the better part of the last two days reviewing group threads and anything else I could find that might help. I pretty much get the same results you show below with versions?1.0.4.1.1, 1.0.4.1.2, and 1.0.4.1.3 no matter how I tweak values within dsnoop and dmix.

I even tried compiling with different hard coded values as suggested in one of the threads by Peter LaRue and while I have little experience coding for soundcard audio I think the following results from a test with hard coded values suggests that the inability to utilize dsnoop / dmix within .asoundrc is at least in part still an issue with ardopcf and not entirely an alsa problem as some suggest.

WARNING: Inconsistent ALSA playback configuration: 1000000 * 12000 != 12000 * 1000000.
WARNING: The -A option was specified.? So, ALSA misconfiguration will be ignored.? This option is ONLY intended for testing/debuging.? It IS NOT INTENDED FOR NORMAL USE.

Very curious that ardopcf determines 1000000 * 12000 != 12000 * 1000000 ???

Between that error / bug and what seems like little interest in pursuing the issue based on Peter's comments at the bottom of the discussion at I am inclined to pass on ardopcf at least until it is a little further along in development. Running ARDOP_Win.exe via wine on linux works far better on the x86 and x64 systems here than does ardopcf and it plays nice with dsnoop and dmix as long as the wine registry is updated properly.

73 de Rich WA3WLH

Re: ARDOPCF and QtSoundModem?

#42982

With both the latest master and develop branches removing the call to? snd_pcm_hw_params_set_period_size_near fixes the sharing problem for me. This is in ALSASound.c or ALSA.c depending on the version.

I haven't noticed any difference in performance compared with using the original source and not using snoop/mix.

73, John

Show quoted text

On 05/01/2025 20:44, Rich Sahlender via groups.io wrote:
Hi Niels,

Thanks for the feedback. I have spent the better part of the last two days reviewing group threads and anything else I could find that might help. I pretty much get the same results you show below with versions?1.0.4.1.1, 1.0.4.1.2, and 1.0.4.1.3 no matter how I tweak values within dsnoop and dmix.

I even tried compiling with different hard coded values as suggested in one of the threads by Peter LaRue and while I have little experience coding for soundcard audio I think the following results from a test with hard coded values suggests that the inability to utilize dsnoop / dmix within .asoundrc is at least in part still an issue with ardopcf and not entirely an alsa problem as some suggest.

WARNING: Inconsistent ALSA playback configuration: 1000000 * 12000 != 12000 * 1000000.
WARNING: The -A option was specified.? So, ALSA misconfiguration will be ignored.? This option is ONLY intended for testing/debuging.? It IS NOT INTENDED FOR NORMAL USE.

Very curious that ardopcf determines 1000000 * 12000 != 12000 * 1000000 ???

Between that error / bug and what seems like little interest in pursuing the issue based on Peter's comments at the bottom of the discussion at  I am inclined to pass on ardopcf at least until it is a little further along in development. Running ARDOP_Win.exe via wine on linux works far better on the x86 and x64 systems here than does ardopcf and it plays nice with dsnoop and dmix as long as the wine registry is updated properly.

73 de Rich WA3WLH

Re: QtSoundModem on a separate host: changing radios

#42981

GM Chuck,

On Tue, Jan 21, 2025 at 10:00?AM Chuck Gelm via <nc8q-aredn=[email protected]> wrote:

My IC-7100 stopped transmitting power.
I want to use my IC-7300 in its place.
I have been running pilinbpq (on a rpi;-) since December 2020 and
QtSoundModem64 on a tiny x86 laptop for about 2 years.
I am no longer familiar with how to select my radio's serial port;
/dev/ttyUSB73 .

'aplay -l/arecord -l' reports my IC-7300 on "Card 2" ("hw:2,0" ?).
My IC-7100 was "Card 1" ("hw:1,0 ?)

I cannot find a reference to "/dev/ttyUSB" nor "hw:#,0" in QtSoundModem.ini.

I found a previous reference to "hw:1,0" in
(GUI) QtSoundModem64 -> Settings -> Setup Devices -> Dialog -> Sound Card.
I changed that to 'hw:2,0'.

That should be correct for the sound device in QtSM based on what was reported via aplay and arecord.

BPQ did set my IC-7300 to 7.101 MHz, so maybe something is working.

My IC-7100 uses CI-V address 88h, my IC-7300 uses CI-V address 94h.
Where to I edit this setting?

That should be in the rig control area in bpq32.cfg. Assuming you are using the "new method" per , you would need a line like this for the IC7300, and there should be an old one for the IC7100. I'm assuming /dev/ttyUSB73 is the serial port for CAT control on the 7300.

RADIO 1
/dev/ttyUSB73 9600 ICOM IC7300 94

For the most part I don't know either radio, but I do know that the 7300 has built-in sound. Based on what you mentioned above, it sounds like the 7100 does also. I'm not sure how you had PTT set up in QtSM with the 7100. With QtSM running on a different machine than BPQ, it can be set to use Hamlib for PTT, which will connect to BPQ's hamlib emulator. Then QtSM's PTT via hamlib is converted by BPQ to CAT commands for PTT. In that case the rig control line would need to include invoking the hamlib emulator:

RADIO 1
/dev/ttyUSB73 9600 ICOM IC7300 94 HAMLIB=4532

- and QtSM will need to be set to use hamlib for PTT using the IP address of the BPQ machine.

For all I know you may already be using the hamlib method with the 7100 given QtSM and BPQ are on separate computers.

73,
Lee K5DAT

QtSoundModem on a separate host: changing radios

#42980

My IC-7100 stopped transmitting power.
I want to use my IC-7300 in its place.
I have been running pilinbpq (on a rpi;-) since December 2020 and
QtSoundModem64 on a tiny x86 laptop for about 2 years.
I am no longer familiar with how to select my radio's serial port; /dev/ttyUSB73 .

'aplay -l/arecord -l' reports my IC-7300 on "Card 2" ("hw:2,0" ?).
My IC-7100 was "Card 1" ("hw:1,0 ?)

I cannot find a reference to "/dev/ttyUSB" nor "hw:#,0" in QtSoundModem.ini.

I found a previous reference to "hw:1,0" in
(GUI) QtSoundModem64 -> Settings -> Setup Devices -> Dialog -> Sound Card.
I changed that to 'hw:2,0'.

BPQ did set my IC-7300 to 7.101 MHz, so maybe something is working.

My IC-7100 uses CI-V address 88h, my IC-7300 uses CI-V address 94h.
Where to I edit this setting?

73, Chuck

Re: DIGIFLAG=1 with UH7ZO

#42979

开云体育

DIGIFLAG works if using the KISS interface but not the UZ7HO driver. Or you can set up SoundModem to digipeat independent of BPQ

73, John

On 16/01/2025 21:21, David VK2NA via groups.io wrote:

Show quoted text

Hi,

?

Does the DIGIFLAG for digipeating work with UZ7HO soundmodem?

?

My system is not digipeating here.? ?Any advice appreciated.

?

Cheers.

Re: DIGIFLAG=1 with UH7ZO

#42978

I do not use soundmodem but if I remember correctly, if you use the UZ7HO driver then the L2 processing happens in the soundmodem configuration.? If you use the BPQ2AGW driver then L2 processing happens in BPQ and is controlled in the bpq32.cfg file.

?

Someone may surely correct me with finer details...

?

--

73,

Mark, N5MDT

Montgomery, Texas

?

DIGIFLAG=1 with UH7ZO

#42977

Hi,

?

Does the DIGIFLAG for digipeating work with UZ7HO soundmodem?

?

My system is not digipeating here.? ?Any advice appreciated.

?

Cheers.

Re: Help with CTEXT Format and ASCII Codes

#42976

I provided the original file to John, and he informed me that the CTText I used was too long.

CTText is limited to 510 characters, but mine was 533 characters.

Thank you, John and everyone.

73,
Tom