I wrote a very basic powershell script to get the latest BPQ beta binaries and DLL from John’s website to help simplify the process of updating. It is not a smart script, its basic but could be the foundation for a more advanced script that does version backups and so forth. However, as I do not run windows myself that is a bit beyond my scope of abilities :-)
Here’s a write-up included for the list, but any corrections will be posted here:
73s Red de PE1RRR
Simple (Windows) Powershell Script to Update?BPQ32
This very VERY basic script was created for a friend to update their Windows 10 install of BPQ32 to the latest beta releases. As beta releases by John G8BPQ don’t have any identifying characteristics other than file server time stamp, the update process is as simple as downloading the latest binaries and zipped DLL from the same locations periodically.
To get this script to work on your system you will be required to enable Powershell scripts in the system settings. Follow the below menu path to locate the section containing the security override.?
Start Menu -> PC Settings -> Updates & Security -> Developer Options -> Scroll down to Powershell section.
Check the box next to ”Change execution policy to allow local Powershell scripts to run” and click Apply.
To create the script, find and run from the start menu:
powershell_ise
Clear-Host
# Edit paths below to suit your system
# Please note that the Upgrade folder is emptied on each script run.
$BpqUpgradeFolder = "D:\BPQ32\UPGRADE"
$BpqMainFolder = "D:\BPQ32"
Write-Host "Updating BPQ DLL and EXE files, please make sure BPQ is shut down first..."
pause
New-Item -ItemType Directory -Force -Path "$BpqUpgradeFolder"
Get-ChildItem -Path $BpqUpgradeFolder -File -Recurse | Remove-Item
Invoke-WebRequest -Uri "https://www.cantab.net/users/john.wiseman/Downloads/Beta/bpq32.zip" -OutFile "$BpqUpgradeFolder\bpq32.zip"
Invoke-WebRequest -Uri "https://www.cantab.net/users/john.wiseman/Downloads/Beta/BPQChat.exe" -OutFile "$BpqUpgradeFolder\BPQChat.exe"
Invoke-WebRequest -Uri "https://www.cantab.net/users/john.wiseman/Downloads/Beta/BPQMail.exe" -OutFile "$BpqUpgradeFolder\BPQMail.exe"
Expand-Archive -Path "$BpqUpgradeFolder\bpq32.zip" -DestinationPath "$BpqUpgradeFolder" -Force
ForEach($file in Get-Childitem $BpqUpgradeFolder -Recurse -ErrorAction SilentlyContinue `
| Where-Object {$_.Extension -Match "dll" -or $_.Extension -Match "pdb" -or $_.Extension -Match "exe"} )
{
Write-Host "Copying file: $file"
Copy-Item -Path $file.fullname -Destination $BpqMainFolder -force
}
Write-Host "Update Complete"
pause
Copy the contents of the script into the upper part of the PowerShell editor,?
Then edit the following lines to match your system:
The ”BpqUpgradeFolder” folder mentioned above is a temporary directory created each time the script is run where the zip file and executables are then downloaded to, the entire directory is erased each time the script is executed, so be sure not to set this incorrectly as you may lose files.
After setting the paths appropriately, use the?File?menu to save the script into an appropriate location.
Before testing, shut down your BPQ32 application, test the script by using the green Play button in the PowerShell editor. It is necessary to shut down BPQ before running the script from wherever you saved it to.
On Jun 14, 2022, at 4:23 AM, Red - PE1RRR - Masochistic Test Pilot <rrrtuby@...> wrote:
Hello folks, Thought to contribute to the group with a recent success of getting a RPI to take over doing all of the things at once on one audio interface including VARA running simultaneously as other native Linux modems:
The original document with images and a demo video is up here:
—- included below for archival —-
RPI4 Trifecta: VARA, Packet & ARDOP – One Audio?Interface
A Short Demonstration
Requirements
This document assumes you have already installed the VARA suite of modems and the companion programs via the Winelink project. If not, now is your chance-
Word of caution: installing wine is disk intensive, if you have not yet got your home directory on a real physical disk instead of the SD Card- now is the time to consider doing that. The SD Card is also incredibly slow for wine applications.
To install Wine and the ARM x86 emulator system, visit the?
Or go wild and run it live from the command line:
curl -O && \ bash install_winelink.sh
VARA: dsnoop & dmix
Physical audio interface mapping to the virtual sound devices for playback (dsnoop) and recording (dmix), the device shown below- “hw:1,0” refers to the audio interface ID provided by the ‘aplay -l’ command. Yours may differ. E.g.?hw:2,0?etc.
Both VARA and ARDOP require 48KHz sample rate to be forced (default is 44.1 for system sounds) so two new audio streams are required and this is accomplished using the?.asoundrc?file configuration.?
Below is a snip showing the previously configured dsnoop0 & dmix0 interfaces, we’re going to call them?ARDOP2IN?and?ARDOP2OUT.
Wine (for VARA) requires these 48KHz audio device streams, but in a slightly different presentation to the system. Wine requires asymmetrical streams that we currently do not have, these are provisioned by combining the two previously configured ARDOP streams into a new virtual device “asymwine”.
pcm.asymwine { type asym playback.pcm "ARDOP2OUT" capture.pcm "ARDOP2IN" }
pcm.!default { type plug slave.pcm "asymwine" }
pcm.dsp { type plug slave.pcm "asymwine" }
The next bit gets hairy as we are now required to edit the Wine Registry- what happens is that ‘winecfg’ enumerates (gathers) what it can glean from the host operating system about the audio drivers, unfortunately this process does not scrape the?.asoundrc?file so this particular gotcha requires a couple of new entries in the registry to be made by hand.
From within winealsa.drv, create a new “Multi-string value”.
Name this key:
ALSAOutputDevices
Hit enter to save, then create another key and title it:
ALSAInputDevices
After adding the keys, double-click each newly created key to open it in data entry mode. Insert the device name previously configured in the .asoundrc file –?asymwine,?do this for?BOTH?ALSAOutputDevices?and?ALSAInputDevices.
Close the registry editor and relax.
Now run “winecfg” again and navigate to the Audio tab, from the list of each input/output it should now be possible to select the newly appearing “asymwine” audio interface. If all things went to plan, be sure to do this action for each of the 4 fields.
Apply, OK and exit?winecfg.
Open up VARA HF and navigate to sound settings to select the?asymwineinterfaces.
This concludes the VARA part.
Download & Resources for QtSoundModem & ARDOP
QtSoundModem:?
ARDOP:?
QtSoundModem (Packet)
We are assuming that?piQtSoundModem?has already been set up using a regular audio interface and all of your options and modem settings are ready- if not, go do that first.
To configure QtSoundModem to use the?dsnoop0/dmix0?device the INI file has to be edited manually, any changes made with the GUI of QtSoundModem will overwrite your manual changes and break your setup, so consider fixing the permissions on the INI file so that it can’t write to the file, using “chmod 444 QtSoundModem.ini”
Edit QtSoundModem.ini:
Find and replace the?SndRX/TX?lines:
SndRXDeviceName=:dsnooped0 SndTXDeviceName=:dmix0
That concludes the QtSoundModem setup.
ARDOP
Using a script to launch?piardopc, tailored to your own system, below is an example.
/home/pi/bin/piardopc 8515 ARDOP2IN ARDOP2OUT
8515 is the port ARDOP will listen for TNC connections on (as used when configured in BPQ node suite etc).
ARDOP2IN?and?ARDOP2OUT?are the virtual interfaces previously configured in?.asoundrc?to provision the required 48KHz sample rate streams.
This concludes the ARDOP setup.
Full disclosure
Thanks and credit due to Matt?KB8UVN?& Steve?G7TAJ?for the initial annotated?.asoundrc?dsnoop/dmix syntax that got the ball rolling, and WheezyE/Winelink (on GitHub) for the massive effort getting VARA to run on the Pi in the first place.
Below is the full?.asoundrc?file that works for me:
@hooks [
{
func load
files [
{
@func concat
strings [
{ @func datadir }
"/alsa.conf.pulse/"
]
}
]
errors false
}
]
# Point applications to plughw:dsnooped0 for input and plug:dmix0 for output
pcm.dsnooped0 {
type dsnoop
ipc_key 50000
ipc_key_add_uid false # let multiple users share
ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
slave {
pcm "hw:1,0"
channels 1
}
}
pcm.dmix0 {
type dmix
ipc_key 60000
ipc_key_add_uid false # let multiple users share
ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
slave {
pcm "hw:1,0"
rate 44000
}
}
# Point ARDOP to ARDOP2IN and ARDOP2OUT for rate conversion
pcm.ARDOP2IN {type rate slave {pcm "plug:dsnooped0" rate 48000}}
pcm.ARDOP2OUT {type rate slave {pcm "plug:dmix0" rate 48000}}
# Wine: combine the capture and playback
pcm.asymwine {
type asym
playback.pcm "ARDOP2OUT"
capture.pcm "ARDOP2IN"
}
# Wine: make a default plug for it
pcm.!default {
type plug
slave.pcm "asymwine"
}
# Wine: define a plug for /dev/dsp
pcm.dsp {
type plug
slave.pcm "asymwine"
}
On Jun 9, 2022, at 7:12 AM, Charlie Hein <chein@...> wrote:
?I use QtTerm TCP exclusively to connect to my node locally.? Since upgrading to?Version 6.0.22.70, every time I connect to the node it displays the node list without being asked.? Is this normal behavior?? -- Charlie (N4NVD)
Raspberry PI4 trifecta: VARA, ARDOP & Packet on one audio interface nut cracked.
Hello folks, Thought to contribute to the group with a recent success of getting a RPI to take over doing all of the things at once on one audio interface including VARA running simultaneously as other native Linux modems:
The original document with images and a demo video is up here:
—- included below for archival —-
RPI4 Trifecta: VARA, Packet & ARDOP – One Audio?Interface
A Short Demonstration
Requirements
This document assumes you have already installed the VARA suite of modems and the companion programs via the Winelink project. If not, now is your chance-
Word of caution: installing wine is disk intensive, if you have not yet got your home directory on a real physical disk instead of the SD Card- now is the time to consider doing that. The SD Card is also incredibly slow for wine applications.
To install Wine and the ARM x86 emulator system, visit the?
Physical audio interface mapping to the virtual sound devices for playback (dsnoop) and recording (dmix), the device shown below- “hw:1,0” refers to the audio interface ID provided by the ‘aplay -l’ command. Yours may differ. E.g.?hw:2,0?etc.
Both VARA and ARDOP require 48KHz sample rate to be forced (default is 44.1 for system sounds) so two new audio streams are required and this is accomplished using the?.asoundrc?file configuration.?
Below is a snip showing the previously configured dsnoop0 & dmix0 interfaces, we’re going to call them?ARDOP2IN?and?ARDOP2OUT.
Wine (for VARA) requires these 48KHz audio device streams, but in a slightly different presentation to the system. Wine requires asymmetrical streams that we currently do not have, these are provisioned by combining the two previously configured ARDOP streams into a new virtual device “asymwine”.
pcm.asymwine { type asym playback.pcm "ARDOP2OUT" capture.pcm "ARDOP2IN" }
pcm.!default { type plug slave.pcm "asymwine" }
pcm.dsp { type plug slave.pcm "asymwine" }
The next bit gets hairy as we are now required to edit the Wine Registry- what happens is that ‘winecfg’ enumerates (gathers) what it can glean from the host operating system about the audio drivers, unfortunately this process does not scrape the?.asoundrc?file so this particular gotcha requires a couple of new entries in the registry to be made by hand.
From within winealsa.drv, create a new “Multi-string value”.
Name this key:
ALSAOutputDevices
Hit enter to save, then create another key and title it:
ALSAInputDevices
After adding the keys, double-click each newly created key to open it in data entry mode. Insert the device name previously configured in the .asoundrc file –?asymwine,?do this for?BOTH?ALSAOutputDevices?and?ALSAInputDevices.
Close the registry editor and relax.
Now run “winecfg” again and navigate to the Audio tab, from the list of each input/output it should now be possible to select the newly appearing “asymwine” audio interface. If all things went to plan, be sure to do this action for each of the 4 fields.
Apply, OK and exit?winecfg.
Open up VARA HF and navigate to sound settings to select the?asymwineinterfaces.
This concludes the VARA part.
Download & Resources for QtSoundModem & ARDOP
QtSoundModem:?
ARDOP:?
QtSoundModem (Packet)
We are assuming that?piQtSoundModem?has already been set up using a regular audio interface and all of your options and modem settings are ready- if not, go do that first.
To configure QtSoundModem to use the?dsnoop0/dmix0?device the INI file has to be edited manually, any changes made with the GUI of QtSoundModem will overwrite your manual changes and break your setup, so consider fixing the permissions on the INI file so that it can’t write to the file, using “chmod 444 QtSoundModem.ini”
Edit QtSoundModem.ini:
Find and replace the?SndRX/TX?lines:
SndRXDeviceName=:dsnooped0 SndTXDeviceName=:dmix0
That concludes the QtSoundModem setup.
ARDOP
Using a script to launch?piardopc, tailored to your own system, below is an example.
/home/pi/bin/piardopc 8515 ARDOP2IN ARDOP2OUT
8515 is the port ARDOP will listen for TNC connections on (as used when configured in BPQ node suite etc).
ARDOP2IN?and?ARDOP2OUT?are the virtual interfaces previously configured in?.asoundrc?to provision the required 48KHz sample rate streams.
This concludes the ARDOP setup.
Full disclosure
Thanks and credit due to Matt?KB8UVN?& Steve?G7TAJ?for the initial annotated?.asoundrc?dsnoop/dmix syntax that got the ball rolling, and WheezyE/Winelink (on GitHub) for the massive effort getting VARA to run on the Pi in the first place.
Below is the full?.asoundrc?file that works for me:
@hooks [
{
func load
files [
{
@func concat
strings [
{ @func datadir }
"/alsa.conf.pulse/"
]
}
]
errors false
}
]
# Point applications to plughw:dsnooped0 for input and plug:dmix0 for output
pcm.dsnooped0 {
type dsnoop
ipc_key 50000
ipc_key_add_uid false # let multiple users share
ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
slave {
pcm "hw:1,0"
channels 1
}
}
pcm.dmix0 {
type dmix
ipc_key 60000
ipc_key_add_uid false # let multiple users share
ipc_perm 0666 # IPC permissions for multi-user sharing (octal, default 0600)
slave {
pcm "hw:1,0"
rate 44000
}
}
# Point ARDOP to ARDOP2IN and ARDOP2OUT for rate conversion
pcm.ARDOP2IN {type rate slave {pcm "plug:dsnooped0" rate 48000}}
pcm.ARDOP2OUT {type rate slave {pcm "plug:dmix0" rate 48000}}
# Wine: combine the capture and playback
pcm.asymwine {
type asym
playback.pcm "ARDOP2OUT"
capture.pcm "ARDOP2IN"
}
# Wine: make a default plug for it
pcm.!default {
type plug
slave.pcm "asymwine"
}
# Wine: define a plug for /dev/dsp
pcm.dsp {
type plug
slave.pcm "asymwine"
}
OK, that's the issue. Given you are using a Signalink, it
handles the PTT using its own VOX circuit, so QTSM doesn't
need a PTT setting.? If it is set to use USB0 then it is
interfering with what I assume is a usb to serial adapter that
is used to connect to the KAM.? So set PTT to "None" in QTSM,
and you should be good.
Lee K5DAT
On Sun, Jun 12, 2022 at 1:18
PM Brett Williams <KB5YZB@...>
wrote:
Thanks Lee, I think its a USB conflict not a port in BPQ.
I did test the RFI theory; as I stsrted the pi adn BPQ and
after the QTSM without a transmit, it still block the BPQ
from communicating with the KAM I think there is conflict
with USB0; as the QTSM now uses USB0 and continues to
work......communicate.? Can I change the one of the
configs to USB1 to remove the conflicts or does it have to
be assigned by the OS?
Brett
On 6/12/2022 10:11 AM, Lee Bengston wrote:
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.
OK, that's the issue. Given you are using a Signalink, it handles the PTT using its own VOX circuit, so QTSM doesn't need a PTT setting.? If it is set to use USB0 then it is interfering with what I assume is a usb to serial adapter that is used to connect to the KAM.? So set PTT to "None" in QTSM, and you should be good.
On Sun, Jun 12, 2022 at 1:18 PM Brett Williams <KB5YZB@...> wrote:
Thanks Lee, I think its a USB conflict not a port in BPQ. I did
test the RFI theory; as I stsrted the pi adn BPQ and after the
QTSM without a transmit, it still block the BPQ from communicating
with the KAM I think there is conflict with USB0; as the QTSM now
uses USB0 and continues to work......communicate.? Can I change
the one of the configs to USB1 to remove the conflicts or does it
have to be assigned by the OS?
Brett
On 6/12/2022 10:11 AM, Lee Bengston
wrote:
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.
Thanks Lee, I think its a USB conflict not a port in BPQ. I did
test the RFI theory; as I stsrted the pi adn BPQ and after the
QTSM without a transmit, it still block the BPQ from communicating
with the KAM I think there is conflict with USB0; as the QTSM now
uses USB0 and continues to work......communicate.? Can I change
the one of the configs to USB1 to remove the conflicts or does it
have to be assigned by the OS?
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.
On Fri, Jun 10, 2022 at 12:17 AM, John G8BPQ wrote:
There was a bug which meant that connecting to the application defined by the 4th parameter didn't work with QtTermTCP or the Web Terminal. This was fixed in an early 6.0.22 beta.
The documentation for the USER line includes "You may also set a user to automatically connect to one of your applications by adding the Application as a 4th parameter". Maybe this isn't entirely clear, but in this context application means the value from one of your APPLICATION lines, and NODE isn't an application. What the code actually does is pass whatever is specified to the command interpreter, so it doesn't need to be an application, and NODE causes the display of the Nodes List.
73, John
On 09/06/2022 22:43, Charlie Hein wrote:
Removed the NODE from the 4th position and that "fixed" it.? Will advise KF5RLL to do the same.? The odd thing about this is that that user line has been that way since I first set up the node going on three years ago now.? Never actually displayed the node list before until this upgrade.?? -- Charlie (N4NVD)
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.
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.
The very radio I have too. I do love the radio. Was you very
sensitive to noise? I have a TS2000 tight next to it, which is the
reason I trying to get the qtsound modem to work, and it very
quite.......
Looked-up your QRZ; my best friend from Army Signal Officer Basic
Course '90 was a graduate from MTSU. Love the campus....Small
world...
Thanks, the radio is a Kenwood ts480, so you are right the
audio levels can be off as the menu allows a rang from 1-8. I
think the norm is "3" .
Brett KB5YZB
On 6/12/2022 9:19 AM, Perry
Ogletree wrote:
All audio is handled in the KAM so the Pi only
sees serial data decoded by the KAM. Look at your KAM manual
to adjust audio levels. You may be swamping the KAM with
excess audio from the radio.
John, can alsamixer be used to increase the input audio
from KAM plus (using serial/USB connection)? the reason I
ask is, on HF i sometimes find my Mark and Space lights
are solid from a HF station, however my BPQ software dose
not code the data......
Bret
KB5YZB
On 6/12/2022 3:04 AM, John
G8BPQ wrote:
No, but make sure you've selected
the right audio device in QtSM and that there is
sufficient audio drive to trigger the PTT circuit on the
SignaLink. Check the audio levels - I use alsamixer.
73,
John
On 12/06/2022 05:06,
Brett Williams wrote:
Thanks Lee and John. I have the Program working well
and receiving packet. The only issue im having now is
transmit. QtSoundModem is receiving the command from
QtTerm TCP, however the signallink is not keying. Is
there an extra driver for the signal link?
On 6/10/2022 12:09 PM,
Lee Bengston wrote:
Brett,
The sudo commands I provided were the "extra's"
needed for compiling, but in hindsight you were
probably missing the standard prerequisites for
running the binary version.
It's all documented nicely here:
Good to know you have it working.? John was
right in saying it's easier to just download the
binary version and run it, and I should have
mentioned that yesterday.
73,
Lee K5DAT
On Thu, Jun
9, 2022 at 11:38 PM Brett Williams <KB5YZB@...>
wrote:
Thanks
I ran the SUDO command successfully.
I also have the file unzip on the pi.
I issued the "qmake" command and the
following is reported...
Thanks Perry. Its working now with John's instructions using
alsamixer. You're right, I just had to tweak the audio to key the
SL-Radio. However now I have a port conflict? with KAM and Signal
Link...
I will get there; I may not have hair left.; but thats the fun,
pulling you hair out.....:)
The Signalink USB uses internal VOX keying. Your
audio level of the Signalink's internal sound device must be set
high enough to trigger the VOX. If you have CAT control of the
radio, you'd be better off using CAT PTT to key the radio.
Thanks Lee and John. I have the Program working well and
receiving packet. The only issue im having now is transmit.
QtSoundModem is receiving the command from QtTerm TCP, however
the signallink is not keying. Is there an extra driver for the
signal link?
On 6/10/2022 12:09 PM, Lee
Bengston wrote:
Brett,
The sudo commands I provided were the "extra's" needed
for compiling, but in hindsight you were probably missing
the standard prerequisites for running the binary version.
It's all documented nicely here:
Good to know you have it working.? John was right in
saying it's easier to just download the binary version and
run it, and I should have mentioned that yesterday.
73,
Lee K5DAT
On Thu, Jun 9, 2022 at
11:38 PM Brett Williams <KB5YZB@...> wrote:
Thanks
I ran the SUDO command successfully.
I also have the file unzip on the pi.
I issued the "qmake" command and the following is
reported...
Thanks, the radio is a Kenwood ts480, so you are right the audio levels can be off as the menu allows a rang from 1-8. I think the norm is "3" .
Brett KB5YZB
On 6/12/2022 9:19 AM, Perry Ogletree wrote:
All audio is handled in the KAM so the Pi only sees serial data decoded by the KAM. Look at your KAM manual to adjust audio levels. You may be swamping the KAM with excess audio from the radio.
John, can alsamixer be used to increase the input audio from KAM plus (using serial/USB connection)? the reason I ask is, on HF i sometimes find my Mark and Space lights are solid from a HF station, however my BPQ software dose not code the data......
Bret
KB5YZB
On 6/12/2022 3:04 AM, John G8BPQ wrote:
No, but make sure you've selected the right audio device in QtSM and that there is sufficient audio drive to trigger the PTT circuit on the SignaLink. Check the audio levels - I use alsamixer.
73,
John
On 12/06/2022 05:06, Brett Williams wrote:
Thanks Lee and John. I have the Program working well and receiving packet. The only issue im having now is transmit. QtSoundModem is receiving the command from QtTerm TCP, however the signallink is not keying. Is there an extra driver for the signal link?
On 6/10/2022 12:09 PM, Lee Bengston wrote:
Brett,
The sudo commands I provided were the "extra's" needed for compiling, but in hindsight you were probably missing the standard prerequisites for running the binary version.
It's all documented nicely here:
Good to know you have it working.? John was right in saying it's easier to just download the binary version and run it, and I should have mentioned that yesterday.
73,
Lee K5DAT
On Thu, Jun 9, 2022 at 11:38 PM Brett Williams <KB5YZB@...> wrote:
Thanks
I ran the SUDO command successfully.
I also have the file unzip on the pi.
I issued the "qmake" command and the following is reported...
The Signalink USB uses internal VOX keying. Your audio level of the Signalink's internal sound device must be set high enough to trigger the VOX. If you have CAT control of the radio, you'd be better off using CAT PTT to key the radio.
Thanks Lee and John. I have the Program working well and receiving packet. The only issue im having now is transmit. QtSoundModem is receiving the command from QtTerm TCP, however the signallink is not keying. Is there an extra driver for the signal link?
On 6/10/2022 12:09 PM, Lee Bengston wrote:
Brett,
The sudo commands I provided were the "extra's" needed for compiling, but in hindsight you were probably missing the standard prerequisites for running the binary version.
It's all documented nicely here:
Good to know you have it working.? John was right in saying it's easier to just download the binary version and run it, and I should have mentioned that yesterday.
73,
Lee K5DAT
On Thu, Jun 9, 2022 at 11:38 PM Brett Williams <KB5YZB@...> wrote:
Thanks
I ran the SUDO command successfully.
I also have the file unzip on the pi.
I issued the "qmake" command and the following is reported...
Red R. R. Tuby (PE1RRR)
Ray Adkins
Ray Spreier-KG7AV