scrape/quisk-kc4upr
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
742cc489ed
quisk-kc4upr/docs.html

1534 lines
53 KiB
HTML
Raw Normal View History

Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
<!DOCTYPE html>
<html lang="en"><head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta name="description" content="Documentation for Quisk">
<meta name="author" content="James C. Ahlstrom">
<meta name="keywords" content="quisk, sdr, software defined radio, ham radio">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Documentation for Quisk</title>
<style type="text/css">
* {
margin: 0px;
}
body {
padding: 0px;
}
ul.menu {
padding: 20px;
}
div.menu {
position: fixed;
float left;
background: #F9F9C9;
overflow: scroll;
width: 15%;
height: 100%;
padding: 5px;
font-family: sans-serif;
font-size: 16px;
}
div.contents {
position: relative;
float: right;
overflow: scroll;
width: 80%;
height: 100%;
padding: 10px;
}
</style>
</head>
<body>
<div class="menu">
<ul class="menu">
<li><a href="#Welcome">Welcome</a></li>
<li><a href="#Credits">Credits</a></li>
<li><a href="#Installation">Installation</a></li>
<li><a href="#Configuration">Configuration</a></li>
<li><a href="#SoundCards">Sound Cards</a></li>
<li><a href="#SDRIQ">SDR-IQ</a></li>
Updated local repository to 4.1.54
2020-04-29 23:09:06 -04:00
<li><a href="#Perseus">Perseus</a></li>
Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
<li><a href="#Timing">Timing</a></li>
<li><a href="#USBControl">USB Control</a></li>
<li><a href="#CustomHardware">Custom Hardware</a></li>
<li><a href="#ExtensionPackages">Extensions</a></li>
<li><a href="#Digital">Digital Modes</a></li>
<li><a href="#Hamlib">Rig Control and Logging</a></li>
<li><a href="#VNA">VNA</a></li>
</ul>
</div>
<div class="contents">
<h1>
<a id="Welcome"></a>
Welcome to QUISK (December 2018)
</h1>
<p>
This is Quisk, a Software Defined Radio (SDR). You supply an antenna and
a complex (I/Q) mixer to convert the radio spectrum to a low IF. Then send
that IF to your computer using the sound card, Ethernet or USB.
The Quisk software will read the I/Q data, tune it, filter it,
demodulate it, and send the audio to headphones or speakers.
Quisk has a microphone input and a key input so it can operate as a
complete transceiver. Quisk works with this hardware:
</p>
<br>
<ul>
<li>SoftRock connected to the sound card</li>
<li>Many other SDR's connected to the sound card</li>
<li>SDR-IQ connected by USB</li>
Updated local repository to 4.1.54
2020-04-29 23:09:06 -04:00
<li>Perseus connected by USB</li>
Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
<li>N2ADR hardware connected by Ethernet and IP</li>
<li>HiQSDR hardware connected by Ethernet and IP</li>
<li>The Hermes-Lite project at <a href="http://hermeslite.com">hermeslite.com</a></li>
<li>Quisk can be used as a pan adapter, and can control some radios</li>
</ul>
<br>
Quisk is small and simple, and has been designed so that it is easy to
change Quisk to suit your own hardware. Quisk rhymes with
"brisk", and is QSK plus a few letters to make it
easier to pronounce. QSK is a Q signal meaning full breakin CW
operation,
and Quisk has been designed for low latency. Quisk includes an input
keying signal that can mute the audio and substitute a sidetone.
<br>
<br>
Please read the file <a href="http://james.ahlstrom.name/quisk/CHANGELOG.txt">CHANGELOG.txt</a>
for changes.
<br>
<br>
When running Quisk for the first time, please press the "Help"
button on the lower right.
<br>
<br>
<h2 id="Credits">Credits </h2>
Quisk was originally written by James Ahlstrom, N2ADR.
<br>
<br>
Thanks to Leigh L. Klotz, Jr. WA5ZNU for configuration improvements,
factoring
out my eccentric hardware control, and adding panadapter and other
hardware
support.
<br>
<br>
Thanks to Franco Spinelli for a fix for the H101 hardware.
<br>
<br>
Thanks to Andrew Nilsson VK6JBL for adding support for SoftRock Rx and
Tx.
<br>
<br>
Thanks to Terry Fox, WB4JFI, for code to support the Charleston
hardware.
<br>
<br>
Thanks to Maitland Bottoms, AA4HS, for the sub-module linkage patches.
<br>
<br>
Thanks to Philip G. Lee for adding native support for PulseAudio.
<br>
<br>
Thanks to Eric Thornton, KM4DSJ, for adding async support for PulseAudio.
<br>
<br>
Many others contributed to Quisk, and are mentioned in comments in the source code.
<br>
<br>
<h2 id="Installation">Installation</h2>
<p>
Quisk is free open source software. It is hosted on the PyPi repository
<a href="https://pypi.org">https://pypi.org</a>.
It can be installed using the standard Python setup tools. See specific directions below.
Python is available as a series 2.7 release or a series 3 release, and there are 32-bit and 64-bit
versions of each. You can continue to use the Python you have. If you don't have Python, install
the most recent 64-bit Python3. It is possible to have both Python 2.7 and Python3 installed,
and then install Quisk on both. If you have both Python2 and Python3, you can start them with
"py -2" or "py -3". See the Python documentation for the py launcher.
</p>
<br>
<p>
Note that the 32 and 64-bit versions of Quisk are for the 32 and 64-bit versions of Python.
The machine archetecture (32 or 64 bit) does not matter. Quisk must agree with the Python version.
But a machine with 32-bit archetecture will not run 64-bit software, so you will need 32-bit Python.
If you have a 64-bit machine, you can use either 32 or 64-bit Python, but most software is changing to 64 bit.
You don't have to worry about this, because when you run pip from Python, pip will choose the correct version
of Quisk.
</p>
<br>
<h3 id="g0.2.2">Windows Initial Installation</h3>
<p>
If you have Python, you can continue to use the version you have if it is recent.
If you don't have Python installed,
visit <a href="http://www.python.org/">http://www.python.org</a>
and download the Windows installer for the most recent Python3. Use 64-bit for a 64-bit computer.
To get there from python.org, click on "Downloads", then "Windows", then
"Latest Python 3 Release". Under "Files" click on "Windows installer".
The x86 is the 32-bit version and x86-64 is the 64-bit version.
When installing, write down your install directory so you know where Python is located.
There is an option to "Add python.exe to Path". It is best to select
this option so that you can start python by just typing "python" instead of the whole path
from your install directory. But don't do this if you have multiple versions of Python.
</p>
<br>
<p>
Next open a Command Prompt. This is located under "Windows System" on Windows 10; or use the
search bar. Enter "python --version" and then "pip --version" to make sure that these programs are installed,
and what version you have. If "python" is not found, it might not be on your Path.
Try your_install_directory\python --version.
For pip, it is your_install_directory\Scripts\pip --version. If you can find Python but not pip, you can run pip
with "python -m pip".
</p>
<br>
<p>
First upgrade some Python modules to the newest version, then install Quisk. Enter these commands. The upgrade of pip
gave error messages on my machine, but it worked anyway.
</p>
<br>
pip install --upgrade pip
<br><br>
pip install --upgrade setuptools
<br><br>
pip install --upgrade wxPython
<br><br>
pip install --upgrade pyserial
<br><br>
pip install --upgrade quisk
<br><br>
<p>
You should then be able to start Quisk with the command "quisk" or "your_install_directory\Scripts\quisk".
To create a Quisk shortcut on your desktop, right-click an empty space and select "New" and "Shortcut".
Use "your_install_directory\Scripts\quisk.exe" as the command and "Quisk" as the name. Create another shortcut for
quisk_vna if you plan to use it. To install a newer version of Quisk, just use "pip install --upgrade quisk".
You could check for newer versions of the other modules twice a year if you want.
</p>
<br>
<p>
To get started you must tell Quisk what kind of radio hardware you have. Press the Config button and select Radios.
Then set your sound devices for that radio; the device for the radio speakers, the microphone and so forth. All configuration
is (mostly) from the Config button. Ignore old directions and don't bother with a config file.
</p>
<br>
<h3>Windows Quisk Upgrade</h3>
To upgrade to a newer version of Quisk, use pip. Remember that if Python is not on your Path, you will
need to type out the whole path.
<br>
<br>
pip install --upgrade quisk
<br>
<br>
<h3>Windows Uninstall Quisk</h3>
pip uninstall quisk
<br>
<br>
<h3 id="g0.2.1">Linux Initial Installation</h3>
Most likely both Python2 and Python3 are already installed on your computer. Either the 32-bit or 64-bit
version will work. On my Ubuntu machine, "python2" starts Python2 and "python3" starts Python3.
Just "python" starts python2, but this will change as Python2 is phased out.
Install these packages. Some of these can be installed from Python using "pip",
but it is better to use your package manager because pip and the package manager do not coordinate.
If newer versions of these packages become available, Linux will notify you.
<br>
<br>
sudo apt-get install python-wxgtk3.0 ## Use this for Python2
<br>
sudo apt-get install python3-wxgtk4.0 ## Use this for Python3
<br>
sudo apt-get install libfftw3-dev
<br>
sudo apt-get install libasound2-dev
<br>
sudo apt-get install portaudio19-dev
<br>
sudo apt-get install libpulse-dev
<br>
Updated local repository to 4.1.53
2020-04-29 22:46:57 -04:00
sudo apt-get install python-dev
<br>
Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
sudo apt-get install libpython2.7-dev
<br>
Updated local repository to 4.1.53
2020-04-29 22:46:57 -04:00
sudo apt-get install python3-dev
<br>
Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
sudo apt-get install libpython3-dev
<br>
sudo apt-get install python-usb
<br>
sudo apt-get install python3-usb
<br>
sudo apt-get install python-setuptools
<br>
sudo apt-get install python3-setuptools
<br>
sudo apt-get install python-pip
<br>
sudo apt-get install python3-pip
<br>
<br>
Then install either or both versions of quisk. They will not interfere with each other.
<br>
<br>
sudo python2 -m pip install --upgrade quisk
<br>
sudo python3 -m pip install --upgrade quisk
<br>
<br>
This will install the Python files and all other files except for the C source. This is the easiest method
if you do not want to work in C.
If you have both Python2 and Python3 quisk, you can run either with these commands:
<br>
<br>
python2 -m quisk
<br>
python3 -m quisk
<br>
<br>
If you have only one quisk you can run it with the command "quisk".
You can create a panel launcher on your desktop with the command to run Quisk.
<br>
<br>
To get started you must tell Quisk what kind of radio hardware you have. Press the Config button and select Radios.
Then set your sound devices for that radio; the device for the radio speakers, the microphone and so forth. All configuration
is (mostly) from the Config button. Ignore old directions and don't bother with a config file.
<br>
<br>
To edit the Quisk Python files you need to know where they are. To find out, import quisk and print it:
<br>
<br>
<pre>
jim@IntelNUC:~$ python
Python 2.7.12 (default, Nov 12 2018, 14:36:49)
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import quisk
>>> quisk
module 'quisk' from '/usr/local/lib/python2.7/dist-packages/quisk/__init__.pyc'
>>>
</pre>
<br>
<h3>Linux Quisk Upgrade</h3>
To upgrade to a newer version of Quisk, use pip:
<br>
<br>
sudo python2 -m pip install --upgrade quisk
<br>
sudo python3 -m pip install --upgrade quisk
<br>
<br>
<h3>Linux Uninstall Quisk</h3>
sudo python2 -m pip uninstall quisk
<br>
sudo python3 -m pip uninstall quisk
<br>
<br>
<h3>Linux Quisk Source Files</h3>
The previous method using pip is simple, but will not install the C source files. If you want those proceed as follows.
Go to <a href="https://pypi.org/project/quisk/">https://pypi.org/project/quisk</a> and under "Navigation"
select "Download files". Download the quisk-x-x-xx.tar.gz file. This is the source file. The ".whl" files are for Windows.
Change directory to where the file was downloaded, probably "Downloads", and uncompress and untar it.
<br><br>
cd ~/Downloads
<br>
tar zxf quisk-x.x.xx.tar.gz
<br><br>
Change directories to the Quisk directory:
<br><br>
cd quisk-x.x.xx
<br><br>
Now compile Quisk with the "make" command:
<br><br>
make quisk2 # for python2
<br>
make quisk3 # for python3
<br><br>
If "make" fails, you probably have missing packages or missing "-dev" packages. Try to figure out what is missing from the error messages.
Now you can run quisk with the command:
<br><br>
python2 quisk.py
<br>
python3 quisk.py
<br><br>
At this point you have a choice of where to install Quisk. You could just rename the quisk-x.x.xx directory
to a more convenient name, like "quisk" in your home directory, and run Quisk from there.
This is convenient if you want to
alter the Quisk code. Or you could install Quisk into the Python system.
<br><br>
python2 setup.py build
<br>
sudo python2 setup.py install
<br><br>
<h3 id="g0.2.4">Quisk Files</h3>
<br>
These are the Quisk files in the distribution:
<br>
<br>
<ul>
<li>quisk.py is the main program and is written in the Python
language.
Python is a powerful but easy to learn language, and I hope you have
fun changing Quisk to make it do what you want. Python is also useful
for general electronics calculations such as complex arithmetic. See
www.python.org. Quisk.py uses the wxPython Python package to make the
screen interface. </li>
</ul>
<ul>
<li>help.html is the help file for quisk. Press the "Help" button. </li>
</ul>
<ul>
<li>_quisk.so is the _quisk extension module for Linux, and _quisk.pyd is the extension module DLL used by Windows.
<br>
</li>
</ul>
<ul>
<li>sdriq.so is the extension module needed for the SDR-IQ. It needs
_quisk.so to be available when it starts. </li>
</ul>
<ul>
<li>makefile is the makefile, and you must run "make" to create a new
_quisk.so unless you use a Python installer that creates _quisk.so
itself. </li>
</ul>
<ul>
<li>setup.py is used by makefile and the Python installers. </li>
</ul>
<ul>
<li>quisk_conf_defaults.py is the basic configuration file imported
into
all other configuration files. Read it (but don't change it) to see
what you can change in your own quisk_conf.py. </li>
</ul>
<ul>
<li>quisk_conf_*.py are various Quisk configuration files. Copy one
of them
to your own .quisk_conf.py and edit that file. I may publish new model
files in the future, and you don't want your changes to be overwritten.
</li>
</ul>
<ul>
<li>quisk_hardware_*.py are various quisk hardware control programs.
If you
have custom hardware, import one of these files into your
quisk_conf.py. Or copy one of them to your own quisk_hardware.py, edit
that file, and import it in .quisk_conf.py. </li>
</ul>
<ul>
<li>quisk.c, quisk.h are the files for the _quisk extension module
used by
quisk.py. The other C-language files are linked with these to make
_quisk.so and _quisk.pyd.
<br>
</li>
</ul>
<ul>
<li>sound.c is the general purpose sound code for all sources.</li>
</ul>
<ul>
<li>sound_portaudio.c is the sound card access code for PortAudio. </li>
</ul>
<ul>
<li>sound_pulseaudio.c is the sound card access code for PulseAudio. </li>
</ul>
<ul>
<li>sound_alsa.c is the sound card access code for the ALSA drivers.
<br>
</li>
</ul>
<ul>
<li>sound_directx.c is the sound card access code for DirectX. </li>
</ul>
<ul>
<li>is_key_down.c is the hardware key checker for the PC. I use
Ethernet to
send the key status, but there is code for the parallel port and dummy
code too. </li>
</ul>
<ul>
<li>sdriq.c, sdriq.h are the files that make sdriq.so and support the
SDR-IQ. </li>
</ul>
<ul>
<li>microphone.c reads the microphone audio and sends it to your
hardware
using Ethernet. Change it for other sound access.</li>
</ul>
<ul>
</ul>
<ul>
<li>docs.html is Quisk documentation. Look for other *.html and *.txt too.</li>
</ul>
<ul>
<li>portaudio.py is a utility program. Run it to list your PortAudio
devices. It is not used by the Quisk program. </li>
</ul>
<br>
<h2 id="Configuration">Configuration</h2>
The Quisk "Config" button brings up a number of status and configuration screens. When starting with Quisk, you need to create a named "radio"
and then set the configuration for that radio. You can have multiple radios to support several hardwares, or different settings
for the same hardware. Use the "Help with Radios" button for documentation. A special radio named "ConfigFileRadio" is always available.
It doesn't use the settings screens and takes all its settings from the configuration file.
When Quisk starts, it reads an initial configuration from the Quisk file quisk_conf_defaults.py.
Then it reads your configuration file if you have one. Then it reads settings from the configuration screens,
which are stored in the file quisk_settings.json.
You can set almost everything with the screens, but you can have a configuration file if you want.
For Linux, the default configuration file name is ".quisk_conf.py" in
your home
directory; that is, "~/.quisk_conf.py". For Windows, the default
configuration file name is quisk_conf.py in your My Documents folder.
<br>
<ul>
<li>Linux config
file:
~/.quisk_conf.py</li>
<li>Windows config file: My Documents/quisk_conf.py
<br>
</li>
</ul>
To help you get started,
there
are several configuration files included, such as
quisk_conf_model.py
for
sound card, quisk_conf_sdriq.py for SDR-IQ, and quisk_conf_fixed.py for
fixed
VFO such as SoftRock. Do not change any of the quisk_conf_*.py
files. Instead copy one of
these
files (but NOT quisk_conf_defaults.py) to your own config file.
Newer versions of Quisk will not overwrite your personal config file.
<br>
<br>
The file quisk_conf_defaults.py contains all Quisk's parameters, and you can read it to see what can be changed.
<br>
<br>
If you are controlling custom hardware, you will need to specify a
hardware
file in quisk_conf.py. The default is quisk_hardware_model.py. Look at
the
other quisk_hardware_*.py files. For example, quisk_hardware_fixed.py
is for
crystal controlled SoftRock. To use that hardware file, change your
quisk_conf.py to include:
<br>
<br>
<div style="margin-left: 40px;">import quisk_hardware_fixed as
quisk_hardware
<br>
</div>
<br>
There are comments in quisk_conf_model.py showing this change.
If none of the hardware files do exactly what you want, copy one of
them to
your own quisk_hardware.py, edit that file, and include this line in
quisk_conf.py:
<br>
<br>
<div style="margin-left: 40px;">import quisk_hardware
<br>
</div>
<br>
Newer versions of Quisk will not overwrite your
quisk_hardware.py. Your hardware file enables you to customize
Quisk without changing the Quisk program files.
<br>
<br>
Alternatively, you can define a class named "Hardware" in your config
file,
and that class will be used instead of a hardware file. This is
recommended
only for simple hardware needs. The class should start like this:
<br>
<br>
<pre>from quisk_hardware_model import Hardware as BaseHardware
class Hardware(BaseHardware):
def __init__(self, app, conf):
BaseHardware.__init__(self, app, conf)
# Start your hardware control here.
# For ideas, see one of the other hardware modules.
</pre>
<br>
Both the config file and your hardware file are written in the Python
language. Python is an easy to learn but powerful computer
language. Quisk can be adapted to different hardware because of
the power of Python.
<br>
<br>
<h2 id="SoundCards">Sound Cards </h2>
If you use a sound card for input, the quality of your sound card is
critical;
but you can start with the sound card you have. Check the Graph screen
with no input to see the noise floor. It should be as flat and as low
as
possible,
with no bump near zero Hertz. The 0dB line at the top of the Graph
screen
is the
maximum level, so if your noise floor is at -90 dB, you have that much
dynamic range. The IF (sound) input to the sound card should raise the
noise
floor only slightly to avoid losing dynamic range.
<br>
<br>
The sample rate determines how much of the band you can see on the
screen. My 96 kHz card shows a little over 80 kHz of bandwidth, from
-40 kHz to + 40 kHz centered at the VFO frequency. Generally you
would choose the
highest
rate available to get the most visible bandwidth. Be aware that a card
claiming to work at (say) 192 kHz may in fact play at that rate, but
only capture (record) audio at a lower rate. It is the capture rate
that matters.
Enter only the sample rate you know your raw hardware supports for
capture.
<br>
<br>
If you use the SDR-IQ or other hardware for input, you still need a
sound card for sound output. The quality of this card is not so
important, so try the one you have. Be aware that most sound
cards require the capture and playback rate to be the same when used
for both. Here are some sample configurations:
<br>
<ul>
<li>SoftRock Rx/Tx: Receive to card 1, Transmit to card 1 at the same
rate, radio sound to card 2 at 48 kHz, microphone input from card 2 or
3 at 48 kHz.</li>
<li>SoftRock Rx: Receive to card 1, radio sound to card1 at the same
rate; OR radio sound to card 2 at 48 kHz.</li>
<li>Other: Receive from SDR-IQ or other hardware, radio sound to card
1 at 48 kHz. Add a microphone to card1 at 48 kHz, or to card2 at
48 kHz.</li>
<li>Panadapter: There is no radio sound. Enter a null name ""
for the play device.
<br>
</li>
</ul>
If you buy a new sound card, make sure you know the
capture (recording) sample rates and the noise level. Sound cards
are usually specified over
the audio range up to 24 kHz or so. But we need low noise and
distortion
over the whole range.
<br>
<h3 id="g0.4.1">Linux Names</h3>
Quisk can use PulseAudio, PortAudio or ALSA to access your sound card.
Names can be a fragment of text from the device description. It is
better to use this text search rather than an index number, because the
index number can change if you plug and unplug USB sound cards.
<br>
<br>
The ALSA drivers use different names for the same sound card
to provide different access. The names "hw:0" and "hw:1" refer
to the raw hardware devices of the first and second sound card.
You should use the raw hardware if possible. If the raw devices don't
work,
use the "plughw" name. The ALSA name can also be a string
name. Here are some ALSA names:
<br>
<pre>"hw:0" # First sound card
"hw:1" # Second sound card, etc.
"plughw" # plug device
"default" # alsa default device
"alsa:NVidia" # Search for the name in the alsa device description
</pre>
Alsa names starting with "alsa:" are an extension to the normal alsa
names. They search for the text after the colon in the alsa
device
name. The alsa device names are shown on the config screen.
Or you
can start a terminal window and enter "aplay -l" for a list of play
devices, or "arecord -l" for a list of capture devices. See <a href="http://james.ahlstrom.name/alsa_names.html">alsa_names</a> for
more information.
<br>
<br>
The
PortAudio
interface is newer, may be easier to get working, and may be used to
connect Quisk to other programs (I have not tried this). But for
CW, ALSA
has
lower latency. Run "python portaudio.py" in a terminal window to
see a list of available names, or use
a different PortAudio tool. Here are some PortAudio names:
<br>
<pre>"portaudio:(hw:0,0)" First sound card.
"portaudio:(hw:1,0)" Second sound card, etc.
"portaudio:NVidia" Search for the name in the portaudio device description.
"portaudio#1" Directly specified index.
"portaudiodefault" May give poor performance on capture.
</pre>
<h3 id="g0.4.2">Linux Sound Servers </h3>
Newer Linux systems are now shipping with PulseAudio enabled.
PulseAudio is a sound server, a program that takes control of your
sound cards, and controls usage by applications. The idea is that
your applications talk to PulseAudio, and PulseAudio talks to the sound
cards. Another example of a sound server is JACK.
You can control the
sound routing with the pavucontrol program. Remarkably, this is
not included with PulseAudio, and you will need to install the
pavucontrol package first.
<br>
<br>
Thanks to Philip G. Lee and Eric Thornton, KM4DSJ, Quisk now has native support for PulseAudio.
For PulseAudio devices, use the name "pulse:name" and connect the streams
to your hardware devices using a PulseAudio control program like pavucontrol. The name "pulse"
alone refers to the "default" device. The PulseAudio names are quite long;
for example "alsa_output.pci-0000_00_1b.0.analog-stereo". Look on the screen
Config/Sound to see the device names. There is a description, a PulseAudio name,
and for ALSA devices, the ALSA name.
Instead of the long PulseAudio name, you can enter a substring of any of these three strings.
An example is:
<pre>
# As seen on the Config/Sound screen:
CM106 Like Sound Device Analog Stereo
alsa_output.usb-0d8c_USB_Sound_Device-00-Device.analog-stereo
USB Sound Device USB Audio (hw:1,0)
# Use the default pulse device for radio sound:
"pulse"
# Use a PulseAudio name for radio sound:
"pulse:alsa_output.usb-0d8c_USB_Sound_Device-00-Device.analog-stereo"
# Abbreviate the PulseAudio name:
"pulse:alsa_output.usb"
# Another abbreviation:
"pulse:CM106"
</pre>
The PulseAudio code should not cause problems, but I am not sure what happens if PulseAudio is not
installed, or if you replace it with JACK. This config file option will turn off all but directly
entered "pulse:" names:
<pre>show_pulse_audio_devices = False
</pre>
<br>
<br>
<h3 id="g0.4.3">Linux Problems </h3>
If Quisk appears to run but you get no sound input or output, you
may be having trouble
with your settings. Start Quisk and look at the graph. You should get a
moving
line display. Look at the Config screen. Interrupts should be
increasing and latencies
should fluctuate. If all this looks normal, but you get no sound
output, or you get only
white noise output, then you may need to change your settings with a
mixer program.
<br>
<br>
If you capture data with the sound card (no SDR-IQ) then you need
to set the "capture
device" to the line-in jack, and set the volume of the line-in to 100%.
To play sound,
you need to increase the volume of the playback device. Since a typical
sound card has
ten or twenty controls for all its analog and digital inputs and
outputs, it is a guessing
game to figure out which control to adjust.
<br>
<br>
Basically you start the alsamixer program (use "man alsamixer" first)
and adjust the volume
controls and capture device until Quisk works. It is wise to reduce or
mute unwanted inputs
to avoid adding extra noise.
Quisk does not do this for you. But once you have the controls set,
they will stay the same
and Quisk should keep working until you run another audio program that
changes them.
<br>
<br>
To make Quisk adjust the mixer controls when it starts, you need to
know the control id number.
Run the command "amixer -c 0 contents" (for card zero) and look at the
control ids, names
and values of all your controls. Figure out the control you need to
adjust. For a setable
option (on/off) the control value is one or zero. For a volume it is a
number from 0.0 to
1.0. Make a list of (device_name, numid, value) and add it to
mixer_settings in your
.quisk_conf.py file (see quisk_conf_defaults.py). I don't need to do
this on my computer
except for the microphone input on my second sound card.
<br>
<br>
If you really get stuck, try one of these commands (see the "man"
page):
<br>
<ul>
<li>alsamixer An ALSA mixer program with a curses interface. </li>
</ul>
<ul>
<li>amixer A character ALSA mixer. </li>
</ul>
<ul>
<li>aplay Play sound. </li>
</ul>
<ul>
<li>arecord Capture sound. </li>
</ul>
<ul>
<li>speaker-test Play sound to test your speakers. </li>
</ul>
And try to play an audio CD or run some other Linux audio program just
to see that you
have a working sound system.
If you can't get ALSA to work, you could try the PortAudio or PulseAudio interface by
just
changing the sound card names.
<br>
<br>
<h3 id="g0.4.4">Windows Names</h3>
To see what sound cards you have, use the Control Panel item Sound
Devices. There is a separate list for capture (recording) and
playback devices, and a specified default device for each. The
name of the default device is "Primary". To specify your sound
card name, use either "Primary" or a substring of the device
name. The search is case sensitive.
<br>
<br>
<h2 id="SDRIQ">SDR-IQ as Input </h2>
<p>
Quisk can use an SDR-IQ from RfSpace instead of a sound card as input.
Set up a radio of type SdrIQ. The SDR-IQ uses a serial port to connect to Quisk. When you plug it in,
it will create a USB serial port and connect to it.
</p>
<br>
<p>
On Linux the serial port has a name like /dev/ttyUSB0. Look in /dev or use "dmesg | tail" to figure out what port it is using.
Then enter that port as the "Serial port" on the Config/radio/Hardware screen. The serial ports are part of the "dialout" group.
Add yourself to the "dialout" group so you have permission to use the serial port. You also need a serial port USB
driver for the ft245 chip in the SDR-IQ, but Linux generally comes with a suitable driver.
</p>
<br>
<p>
On Windows the "Serial port" name is not used, and Quisk will search for the port in use.
On Windows 10, you should see a device "SDR-IQ" in Device Manager in the "View/Devices by Container" tab.
In earlier versions of Windows, port names are COM1, COM2 etc. and use the "USB Serial Converter" driver.
Windows should find this driver by itself.
</p>
<br>
Updated local repository to 4.1.54
2020-04-29 23:09:06 -04:00
<h2 id="Perseus">Perseus as Input </h2>
<p>
Quisk can use an Perseus HF receiver from Microtelecom instead of a sound card as input.
Set up a radio of type Perseus. The Perseus uses a native USB interface to connect to Quisk.
The Quisk perseuspkg extension relies on <a href="http://github.com/Microtelecom/libpserseus-sdr">libperseus-sdr</a>
open source library to manage Perseus hardware and receive the I/Q samples stream.
</p>
<br>
<p>
Follow the instruction into GitHub repository to compile and install the library.
On Suse distribution the library is available as binary package.
Next compile the perseuspkg using the command:
</p>
<br>
<pre>
make perseus3
</pre>
</br>
<p>
The several sample rates can be selected opening Config panel: in
the Config tab there is the Samples rates dropdown.
</p>
The input analog filter can be switched in using the button Wideband.<br>
The input attenuator is operate via the button RF, that allows to select
the four attenuator steps.<br>
The ADC commands for dithering and preamplifier are found on
left bottom corner as ADC Dither and ADC Preamp.<br>
</p>
<br>
Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
<h2 id="Timing">Timing </h2>
<br>
There are several configuration parameters devoted to tuning; read the
file quisk_conf_defaults.py for documentation. For most users, Quisk
should run fine with the default settings. But if you use Quisk as part
of a QSK CW transmitter, you should reduce latency_millisecs to as low
a
value as possible. This will reduce latency, but increase the
likelihood of clicks and pops due to sound buffer underruns.
<br>
<br>
<h2 id="USBControl">USB Control </h2>
Many radio devices are now controlled through a USB interface. In
many cases, the interface is actually a serial port, and an external or
internal USB to serial converter is used. In other cases, the USB
is native, but requires a custom device driver. In still other
cases, the USB device announces itself as a standard device such as a
sound device or human interface device, and uses a standard operating
system built-in driver.
<br>
<br>
<h3 id="g0.7.1">Linux</h3>
Default USB permissions do not allow a non-root user to write to the
bus. You may find that Quisk will complain about lack of
permission to access the USB. You could test this by running
Quisk as root and seeing if that works; but this is not acceptable
except for testing. To change USB permissions, add a rule to
/etc/udev/rules.d/local.rules (for SoftRock on Debian and Ubuntu) like
this:
<br>
<br>
SUBSYSTEM=="usb", ATTR{idVendor}=="16c0" ,
ATTR{idProduct}=="05dc", MODE="0666", GROUP="dialout"
<br>
<br>
This changes the USB device permissions to read/write for all users,
and changes the group to the "dialout" group. Default group
permissions are read/write, so if you are in the "dialout" group, you
don't need "MODE"; modify as appropriate. To load the new rule, you can either reboot or on Ubuntu use
<br>
<br>
sudo udevadm control --reload-rules
<br>
<br>
<h2 id="CustomHardware">Custom Hardware</h2>
<p>Quisk receives RF using your sound card or your SDR-IQ out of the
box. But if you have
custom hardware such as a VFO or
a transmitter, you need to describe your hardware to Quisk.</p>
First, Quisk has a transmit (Tx) frequency and a receive (Rx)
frequency. The transmit frequency is the one shown in the
frequency display, and shown by the tuning line on the graph and the
waterfall. The Rx frequency is always equal to the Tx frequency
except when the RIT (receiver incremental tuning) button is down or the
Split feature is in use.
The primary frequency in Quisk is the Tx frequency, even when you are
receiving.
<br>
<br>
Quisk has a "VFO" frequency. This is the RF frequency
corresponding to zero Hertz audio frequency, and is the frequency shown
at the center of the
graph display. For a SoftRock or a direct conversion receiver
(Tayloe detector, SDR1000-type hardware, etc.) this really is the VFO
frequency. But consider an AOR AR8600 receiver with a 10.7 MHz IF
output
to a pan adapter. For that case, the VFO is always 10.7 MHz since
that is the center point of the display, and signals at exactly 10.7
MHz are at zero Hertz audio. But to display the correct frequency
within Quisk, the VFO would be the tuning frequency of the AR8600.
<br>
<br>
When Quisk starts, it uses the hardware description in
quisk_hardware_model.py, but this file doesn't do much. It is
mostly useful as a model or starting point. To use a different
hardware
file, first create a custom file such as my_hardware.py. Look at
the various quisk_hardware_*.py for ideas. Then import your file
in your config file:
<br>
<br>
<pre> import my_hardware as quisk_hardware.</pre>
<br>
Suppose you have a crystal controlled SoftRock. A good model
hardware file is quisk_hardware_fixed.py. Copy
quisk_hardware_fixed.py to my_hardware.py, make any changes to
my_hardware.py, and import it in your config file.
<br>
<br>
At my shack, I control an AT-200PC antenna tuner, my SDR-IQ, my filter
boxes and my SSB transceiver (using Ethernet) all with Quisk. Take a
look at my n2adr subdirectory.
<br>
<br>
The quisk_hardware_model.py file shows the basics of hardware control.
There is an open() and close() function called once on startup and
shutdown. The ChangeMode() and ChangeBand() functions are called when
the user changes the mode or band with the corresponding buttons.
The HeartBeat() function is called at about 10 Hz by Quisk. You
can put code there to poll a serial port or to perform other
housekeeping functions (try to be efficient). The two remaining
functions deserve more documentation.
<br>
Updated local repository to 4.1.54
2020-04-29 23:09:06 -04:00
<br>
Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
<h3 id="g0.8.1">ChangeFrequency(self, tune, vfo, source='', band='', event=None)</h3>
Quisk calls the ChangeFrequency() function when the user changes the Tx
frequency with a mouse click on the graph or waterfall, with the entry
box, with the band Up/Down buttons, etc. The "source" is a string
giving the reason for the change:
<br>
<br>
<table style="text-align: left; width: 896px; height: 190px;" cellspacing="2" cellpadding="2" border="1">
<tbody>
<tr>
<td style="vertical-align: top;">BtnBand</td>
<td style="vertical-align: top;"> A band button was pressed (the
string band is in the band argument)</td>
</tr>
<tr>
<td style="vertical-align: top;">BtnUpDown</td>
<td style="vertical-align: top;">The band Up/Down buttons were
pressed</td>
</tr>
<tr>
<td style="vertical-align: top;">FreqEntry</td>
<td style="vertical-align: top;">The user entered a frequency in
the
box</td>
</tr>
<tr>
<td style="vertical-align: top;">MouseBtn1</td>
<td style="vertical-align: top;">Left mouse button was pressed
(for the mouse, "event" is the handler event)
<br>
</td>
</tr>
<tr>
<td style="vertical-align: top;">MouseBtn3</td>
<td style="vertical-align: top;">Right mouse button was pressed</td>
</tr>
<tr>
<td style="vertical-align: top;">MouseMotion</td>
<td style="vertical-align: top;">The user is dragging with the
left button</td>
</tr>
<tr>
<td style="vertical-align: top;">MouseWheel</td>
<td style="vertical-align: top;">The mouse wheel up/down was used</td>
</tr>
</tbody>
</table>
<br>
Most of the time you will not care about the "source". You just
need to react to the user's action, perhaps by changing the hardware
VFO frequency. It is not necessary to actually make the change
requested. Just
adjust your hardware as required, and return the actual (tune, vfo)
that you want. Quisk will ignore its requested values and use
your actual values instead.
<br>
<br>
For example, suppose you have a crystal controlled SoftRock. The
VFO frequency is fixed at (say) 7.025 MHz. Then when
ChangeFrequency() is called, return (tune, 7025000). This will
fix your VFO frequency to the only one available.
<br>
<br>
Suppose Quisk calls ChangeFrequency() with vfo=7050000 and
tune=7100000, so the tune is 50 kHz above the VFO. Suppose that
is unacceptable because of (say) bandwidth limitations, so you want the
VFO closer to the tune. Set your hardware VFO to 7090000 instead,
and return (tune, 7090000).
<br>
<br>
Suppose Quisk is just controlling a receiver and the audio is
demodulated by the receiver and not by Quisk. Then the center
frequency is always the tuning frequency, and you would set the
receiver frequency to tune, and return (tune,
tune).
<br>
<br>
<h3 id="g0.8.2">ReturnFrequency(self)</h3>
When Quisk starts, it calls ReturnFrequency() to get the initial tune
and VFO. To display an initial frequency, return (tune, vfo) on
the first call.
<br>
<br>
Thereafter, Quisk calls ReturnFrequency() at a 10 Hz rate to poll for
frequency changes. You should almost always return (None, None)
to indicate that the frequencies have not changed since the last time
ReturnFrequency() or ChangeFrequency() was called. Returning
(None, None) is slightly more efficient than returning the actual
frequencies, and thus forcing Quisk to see if its frequencies are out
of date.
<br>
<br>
The only reason to return something other than (None, None) is if your
hardware can change frequency by itself; that is, other than in
response to ChangeFrequency(). For example, if your hardware is a
receiver with a tuning knob, and the user turns the knob, you must
return the new frequencies from ReturnFrequency() or else Quisk will be
unaware of the change.
<br>
Updated local repository to 4.1.54
2020-04-29 23:09:06 -04:00
<br>
<h3 id="g0.8.3">Adding Custom Hardware to the Config/Radios Screen</h3>
Once you write your own hardware file for your custom hardware, you still need to add it to the
list of available radio types, and add its configuration options to its Config/radios/Hardware screen.
First create a subdirectory of the Quisk directory with a name ending in "pkg"; for example,
"myradiopkg". Then put your hardware file in this subdirectory with the name "quisk_hardware.py".
You will need at least one configuration option to specify the hardware file name.
Add this code (all comments) near the top of quisk_hardware.py:
<pre>
# Define the name of the hardware and the items on the hardware screen (see quisk_conf_defaults.py):
################ Receivers MyRadio, The special radio that I own
## hardware_file_name Hardware file path, rfile
# This is the file that contains the control logic for each radio.
#hardware_file_name = 'myradiopkg/quisk_hardware.py'
</pre>
Of course, change the names of the radio and subdirectory as appropriate. Your radio of general type "MyRadio"
will now appear in the list of radios on the Config/Radios screen, and its configuration items will appear
on the Config/radio/Hardware screen. You can add additional items. See quisk_conf_defaults.py and the *pkg
subdirectories for examples.
<br>
Initial commit of a local repository for Quisk.
2020-02-23 21:57:24 -05:00
<br>
<h2 id="ExtensionPackages">Extension Packages </h2>
Quisk comes with two extension packages. The freedvpkg package
supports FreeDV digital voice. The n2adr package
supports the hardware in my shack. There are other extension
packages available from third parties.
<br>
<br>
All extension packages are directories (folders) in the Quisk root;
that is, in the directory where quisk.py is located. This enables
Quisk to find extension modules, and extension modules to find each
other. You can install in a different place, but you will need to
know what you are doing.
<br>
<br>
Starting with Quisk 3.6 C-language extension modules are not linked
with _quisk.so. Certain symbols from _quisk.so are exported using
the Python CObject or Capsule interface. That simplifies linkage
and eliminates problems with module search paths. See the
documentation in import_quisk_api.c. This change was suggested by
Maitland Bottoms, AA4HS, and he also provided patches.
<br>
<br>
<h3 id="g0.9.1">Shared Libraries </h3>
The main Python extension module for Quisk is _quisk.so or _quisk.pyd.
It is a shared
library. To import it, it must be on the Python path. There are other
Python extension modules (shared libraries) for other hardware, for
example,
sdriq.so. Quisk works fine when all these modules are in package
subdirectories. If you want to put them somewhere else, be sure that the Python import mechanism can find them.
<br>
<br>
If you link your sub-packages against _quisk so you can use _quisk functions, be aware that your sub-package must be able
to find
_quisk.so at both compile and run time. You need to follow the Linux rules for searching
for
shared libraries. Try using the "ldd sdriq.so" command to see your
library
dependencies. Also try readelf -d sdriq.so.
<br>
<br>
For Quisk version 3.6 and newer, you should use the Python CObject or
Capsule mechanism instead of using the C linker to access _quisk
functions and data. Quisk will prepare an array of function and
data pointers and transfer them to your sub-module without using the C
linker. Only minimal changes to your sub-module are
required. The SDR-IQ module sdriq.so uses this method, and you
can use it as a model. See the file import_quisk_api.c for
documentation.
<br>
<h3 id="g0.9.2">New Packages </h3>
If you have more complex needs or want to distribute your code more
widely, you need to create a new Quisk package. That is easily
done by modeling your code after the existing packages. To create
a new package you need a subdirectory of the Quisk root to hold it,
perhaps "mypak". Then create these files in mypak:
<br>
<br>
<ul>
<li>__init__.py This file just consists of
the
character "#". Its existence identifies mypak as a Python package.
<br>
</li>
</ul>
<ul>
<li>makefile Only needed if you have C-language extensions.
<br>
</li>
</ul>
<ul>
<li>MANIFEST.in A list of files you want to
distribute in your package. This file often consists of just one
line: include *.c *.h *.py *.txt
*.html
*.so makefile
<br>
</li>
</ul>
<ul>
<li>README.txt This file is expected to
be
present.</li>
</ul>
<ul>
<li>setup.py This file
describes
your package. It contains the package name, author, C source
files and compiler options, etc. See <a href="http://docs.python.org/distutils/setupscript.html">http://docs.python.org/distutils/setupscript.html</a>
and use other packages as examples.
<br>
</li>
</ul>
<br>
To these files, you add all your Python files, C-language files and any
other files you need. If you have a hardware or widget file, they
should be named quisk_hardware.py and quisk_widgets.py. Longer
names are not needed because you are within a package. You should
include a sample quisk_conf.py too.
<br>
<br>
To compile C-language extensions (if you have any) enter "make".
To import your hardware and widgets files from other modules, use:
<br>
<br>
from mypak import quisk_hardware
<br>
from mypak import quisk_widgets
<br>
from mypak import myext as EXT
<br>
<br>
The setup.py file describes how to build your package. But it is
also used to distribute it. To create a mypak-1.0.tar.gz file in
the "dist" subdirectory, use:
<br>
<br>
python setup.py sdist
<br>
<br>
You can then put the file on your web page (for example). To make
your package available on PyPi.Python.org, first register with PyPi and
then use:
<br>
<br>
python setup.py register sdist upload
<br>
<br>
Python supports quite complicated packages; see the distutils
documentation.
<br>
<br>
<h3 id="g0.9.3">Installing Packages </h3>
Your package mypak will run on your machine as is. But when
another user gets mypak-1.0.tar.gz they need to install it.
Basically, they just put it in the Quisk root with the same name as on
your machine. Here is an INSTALL.txt:
<br>
<br>
Unzip and untar this archive at the root of the Quisk directory; that
is, where the file quisk.py is located. In this example, the
archive is named "mypak" and the path to quisk.py is
/home/jim/quisk/quisk.py.
<br>
<br>
mv mypak-1.0.tar.gz /home/jim/quisk
<br>
cd /home/jim/quisk
<br>
gunzip mypak-1.0.tar.gz
<br>
tar xf mypak-1.0.tar
<br>
# Make sure that directory mypak-1.0 exists before removing the
archive.
<br>
rm mypak-1.0.tar # tar file
is no longer needed
<br>
mv mypak-1.0 mypak # change to the correct name
<br>
<br>
<h2 id="Digital">Digital Modes </h2>
Quisk has a number of modes "DGT-" to receive and transmit digital
signals. The modes "DGT-U" and "DGT-L" decode the signal as upper
or lower sideband, and send the monophonic audio to the digital sound
device. The mode "DGT-IQ" does not decode the audio; the I/Q
samples are sent directly to the (stereo) digital sound device.
The bandwidth of the digital signals is set with the filter buttons as
usual, and the filter center is 1500 Hertz.
<br>
<br>
Digital modes require an external program such as Fldigi or wsjtx to decode the
received
audio and to generate transmit audio. There are two aspects, rig
control and audio transfer. Rig control is needed to synchronize
the transmit frequency between Quisk and Fldigi (or other program) and
to operate the PTT (push to talk). You can control Quisk using
either XML-RPC or Hamlib.
See <a href="#Hamlib">Rig Control and Logging</a> below.
<br>
<br>
Quisk has an additional audio input and output for digital
programs. They are named digital_input_name and
digital_output_name in the config file.
They are Digital Input and Digital Output on your radio's Sound configuration screen.
You need to set these names to a sound
device, and then set the Fldigi (or other program) sound card to the
same device. The sound device is not a real sound card; it is
some sort of loopback device, and is only needed because there is no
standard way of sending sound samples between two programs (yet).
The method to use for Quisk is the same as for other programs, and is
on the web. It works for any digital program, not just Fldigi.
<br>
<br>
If you use Windows, you need to purchase a Virtual Audio Cable
(VAC). Connect Quisk to one side, and your digital program to the
other. I haven't tried this, so I don't know the device names to
use, but it is straight forward.
<br>
<br>
If you use Linux, you can use the ALSA loopback device, or use
PortAudio, PulseAudio or Jack to route your audio. Using PulseAudio is the
easiest method because Quisk can set up the loopback devices when it starts.
Set Digital Input to
pulse:QuiskDigitalInput.monitor, and set Digital Output to pulse:QuiskDigitalOutput.
These names should be on the drop down list. If they are missing, make sure that
you didn't set "show_pulse_audio_devices" to False in your config file. Then restart Quisk.
In your digital program, connect the digital
input to QuiskDigitalOutput.monitor and the digital output to QuiskDigitalInput.
These names will be on the sound menu in wsjtx, and you should be receiving and transmitting digital data.
<br>
<br>
Fldigi only has a PulseAudio check box, and there is no way to set the proper device.
In this case, first install the program pavucontrol to control PulseAudio. This is a useful program to
control and understand PulseAudio even if you are not using digital. Set the Quisk devices as above.
Now start both Quisk and Fldigi, and then pavucontrol. The Playback and Recording screens in pavucontrol will
show the devices being used. Change the Fldigi playback to QuiskDigitalInput, and the Fldigi recording to
Monitor of QuiskDigitalOutput. Then everything should work. You do not need to use pavucontrol again because PulseAudio will
remember the settings.
<br>
<br>
If you don't have PulseAudio or don't want to use it, you can use the ALSA loopback device.
The ALSA loopback device works the same way as the Windows VAC. First
create the loopback device with the command "modprobe snd-aloop" (you
will need to be root). You can create the loopback device
when the system starts, but the way to do that depends on your version of
Linux. I added snd-aloop to /etc/modules. You could put the modprobe command in /etc/rc.local instead.
Restart Linux. Now you can enter "cat /proc/asound/cards" to
print out your sound cards, and you should see a "Loopback" card
listed. The cards are also shown on the Quisk config
screen. The Loopback card has one side that connects to Quisk and
another side that connects to your digital program. For the Quisk
side connect both Digital Input and Digital Output to Loopback,0.
Note that the Loopback card is full duplex, and handles both
input and output. There are actually eight loopbacks created at once,
but we are only using subdevice 0. For the digital program side, set the input and
output to "Loopback,1". For Fldigi this is in the Audio / Devices
/ PortAudio menu. Your audio is now connected and you
should be able to receive digital signals. Be sure to test your
transmit signal off the air. You may need to reduce power to
improve linearity.
<br>
<br>
The sample rate for Quisk Digital Input (transmit audio) is fixed at
48000 sps. The sample rate for Quisk Digital Output (received
audio) is the same as the rate sent to your speakers. The
Loopback device adopts the rate of the first program to use it.
So starting Quisk first and your digital program next should
work. Or you may need to set the appropriate rates. It is
probably best to set all sample rates to 48000 sps because the digital
signals are so narrow, and this make them easier to see.
<br>
<br>
<h2 id="Hamlib">Rig Control and Logging</h2>
Digital mode and logging programs need to control Quisk to read and set the frequency and mode and to operate PTT.
Quisk has three options for external control and they can all be used together to connect to multiple programs.
See the Config/radio/Remote screen.
See <a href="http://james.ahlstrom.name/hamlib.html">http://james.ahlstrom.name/hamlib.html</a> for more information.
<br><br>
To connect an external program to Quisk using Hamlib, configure your program to use "Hamlib NET rigctl" (rig 2).
Then go to the Quisk "Remote" config screen for your radio and set
"IP port for Hamlib" to 4532. This assumes you are not using the rigctld daemon program. If you are,
set the Quisk port to 4575 and tell rigctld to control quisk on port 4575.
Now changing the frequency on one program will change the other.
Keying Quisk to key down (however you do that with your hardware) will
set the external program to Transmit. Pressing the PTT control in the external program will
also press the PTT button in Quisk.
<br><br>
You can also control Quisk from another program by using the XML-RPC method if this is available
in your program. Fldigi can use this method.
<br><br>
If your program only uses a serial port (N1MM+) then
use Hamlib with the rig set to "Flex" and connect to the Quisk serial port set on the Remote screen.
For Linux, Quisk can set up these ports itself, and they have names like "/tmp/QuiskTTY0". On Windows
you need a "Virtual Serial Port" that is set up by an external program. This is like the "Virtual Audio Cable"
needed for samples. An Internet search will turn up HDD Software, Eltima Software and many others. Set up a port pair,
and enter one name on the Quisk Remote screen and the other name in the external program.
<br>
<br>
<h2 id="VNA">Vector Network Analyzer</h2>
If you have my transceiver hardware from 2010 QEX, or the newer HiQSDR
hardware, or the Hermes-Lite you can use it as a vector network analyzer by using a
special program. You must be using FPGA firmware version 1.3 or
newer. Run the VNA program with "python quisk_vna.py" or use a
shortcut. The VNA program will not work with SoftRock or other
hardware. The "Help" button explains how to use it, and should
get you started. This VNA program enables you to analyze your
antennas without additional expense.
<br>
<br>
A calibration run must be taken before any data can be obtained.
The calibrations request a scan of data points every 15 killohertz from
zero to 60 megahertz, or a little over 4000 points. These data
are saved so that the scan frequencies can be changed without a new
calibration. For any start and end scan frequency the user
chooses, these saved calibrations are used with linear interpolation.
<br>
<br>
<h3>HiQSDR Internals</h3>
When running in VNA mode the two control bytes [18:20] are the 16-bit
non-zero VNA count "vna_count", the number of data points to
send. This locks the transmit and receive frequency to the
same value. The phases are also equal except for a fixed time
delay, which causes a linear change of phase with frequency. The
starting frequency is the receive frequency (actually phase)
rx_phase. Subsequent points have the transmit phase tx_phase
added to create a frequency scan. Specifically, after each data
point, the tx_phase is added to create the RF output at the next
frequency; then there is a pause of 65 microseconds to allow the
external device under test to stabilize; then 4096 data points are
added together to create the sample; then the sample is added to the
block of data to send by UDP. A sample of zero is sent after the
last data point, and the process repeats. The receiving software
must look for the zero sample that marks the start of a new scan.
The total number of points in the scan is vna_count, and blocks
received with a different length should be rejected.
Since the transmit and receive frequency are the same, the data points
are I/Q values at DC; that is, a complex number representing a voltage
and phase.
If vna_count is zero, the firmware is operating normally, and not in VNA mode.
<br>
<br>
</div>
</body>
</html>
Reference in New Issue Copy Permalink