Brett,

If you are starting QtSoundModem remotely from Windows via PuTTY you will need to use the nogui option e.g. "piQtSoundModem nogui" or "QtSoundModem nogui".? It wasn't clear if you got things working by successfully compiling the source code or by switching to the binary, so I'm not sure how your executable is named.

Given you have made multiple attempts, be sure you don't have more than one instance of QtSoundModem running. Generally I have pretty good luck running "top" to see what processes are running and issuing "sudo pkill <process name>" e.g. "sudo pkill QtSoundModem" in order to kill things and start over.

If it's a BPQ port conflict, one tip is to remove all port numbering in each port if it exists.? BPQ will automatically number the ports in the order they appear in the configuration, and there won't be any conflicts.

"...until the qt soundmodem executes? a command to transmit, after that BPQ will not respond for the ports for the KAMplus"

The fact that it happens after a transmit could be an indication of an RFI problem.? The Direwolf forum seems to have quite a few reports of RFI issues when Raspberry Pi's are in the mix.

73,

Lee K5DAT

On Sun, Jun 12, 2022 at 10:04 AM Brett Williams <KB5YZB@...> wrote:

John that worked. Thanks. So now I think I have a port conflict. I start my pi, BPQ. working fine....I did try to start qtsoundmodem from command line (putty), says it running, however qt Term report"tnc is not ready" for the new qtSM port...... Log into the pi, run the qtSM from command line on the pi, all is working BPQ and qtsound modem. until the qt soundmodem executes? a command to transmit, after that BPQ will not respond for the ports for the KAMplus which is VHF amd 20 meters, the new signal link port will be 30 or 40 meters.

Again, thanks for help. I'm almost 100%

Brett

KB5YZB