Terry Fox, WB4JFI quick-notes on Quisk for Charleston SDR Receiver.  (written in gedit)	August 1, 2010

Here are a few additional notes on this early release of Quisk 3.4.7 as modified by Terry Fox, WB4JFI, for the Charleston RX1 SDR Receiver board.  The Charleston SDR receiver consists of a Digilent Nexys2 FPGA board, with an auxillary board, designed by Dr. John Schwacke, plugged into two PMOD connectors.  The default connectors are PMOD JA and JB.  For more information on this setup, see the DSP/SDR section of the AMRAD website (www.amrad.org), or John Schwacke's website (http://sdrtrack.drupalcafe.com).

Quisk is written for *nix systems by James Ahlstrom (N2ADR)(http://james.ahlstrom.name), in a mixture of Python and C.  You will need C development tools and Python to build the code.  The Charleston software uses standard USB library functions, so you will also need to add the libusb library.  Details depend on what version of Linux you are running.

This code should still run on any of Jim's Quisk-supported hardware, including an SDR-IQ, in addition to the Charleston Receiver.

As mentioned in Jim's documentation, you should move a hardware-specific configuration file into your home directory.  For convenience, I have included a version of my file here, called sample_chas_quisk_conf.py.  Copy this file into your home directory, with the name .quisk_conf.py (note the leading period), using something like: "cp -p sample_chas_quisk_conf.py ~/.quisk_conf.py(return)".  There are several variables set up in that file that you can change to adjust how Quisk operates.

To use this code with an SDR-IQ, just comment out the line in your (home)/.quisk_config.py file that says Charleston = 1, or change it to: Charleston = 0.  I have an SDR-IQ in addition to the Charleston Receiver, and can use either radio by simply commenting or uncommenting that one line (or changing the value to zero).

The Charleston Rx1 Receiver can support larger decimation factors than this code defaults to, which is 192k.  (Take 76.8MHz, and divide by the decimation number, and you get the sample rate sent from the Charleston Receiver to the host computer.  Therefore, 76.8MHz / 400 = 192ks/s.  The AFEDRI8201 has internal dividers of four, which means the CIC's actual divide is 400 / 4, or 100).  There are notes in the config file to set the decimation for other rates.  Decimation must be evenly divisible by four.  Feel free to experiment.

I am seeing more buffer underuns and FFT errors if I run above about 240ks/s.  Jim says that he can run Quisk with his hardware at upwards of 900ks/s, so something is still off.  Maybe it's just my laptops (I regularly use two, both at least two years old).

I have adjusted the coefficients for the two FIR filters inside the 8201 for 192k samples.  There are still a few more optimizations here before I declare complete success.

One thing that I have noticed is that you can hear an "image" of stronger signals about 48kHz above and below the actual signal.  Those artifacts do NOT show up of the graphic display, but can be heard in the demodulated audio.  This may be related to FIR filter issues, or sample size issues, i'mnot sure yet.  Jim says that he has also heard some of these images with his SD-IQ, but I cannot seem to reproduce them with my SDR-IQ.

This version of Quisk uses a slightly different architecture than previous versions.  Jim moved the SDR-IQ hardware-specific code out of quisk.py, quisk.h, and quisk.c, and put that code in sdriq.py, sdriq.h, and sdriq.c.  This allowed me to make equivalent files for the Charleston Receiver hardware, called chas_rx1.py, chas_rx1.h, and chas_rx1.c.  I did NOT write all this new code, it was a cut-and-paste transmorgification of Jim's SDR-IQ code and John Schwacke's Charleston Receiver support code for GNU Radio.

I added a small window on the lower-right of the display to show CPU loading, but the hooks between the code sections have not been completed yet, so it's disabled remporarily.  I'm not sure this is useful, especially with dual-core and multiple CPU computers.  You can run the System Monitor to see CPU loading (Ubuntu: on top GUI menu, select: System/Administration/Sysem Monitor).

Jim has added the ability to change decimation rate on-the-fly with a GUI button (in CONFIG), which can be real handy for things like "zooming into" a signal.  I've added the necessary code to implement this with the Charleston board.  I recently adjusted the code to properly calculate the optimal CIC shift and scale factors for the 8201 when changing decimation rate.  There is almost no change in the FIR filter coefficients for altering the decimation rate, so I will use a common table for now.

Jim's code runs in two separate threads: a sound/sampling thread, and a GUI thread.  John's original Charleston Receiver GNU Radio code also had two threads, but split in a slightly different manner.  If you see some commented out code in the chas_rx1.c/h files related to threading, that was an attempt to work John's threading into Quisk.  I gave up on that fairly quickly when I saw that Jim's Quisk already had two threads.  So, ignore those comments for now, they will be deleted.

Failures of this code to function are mine and mine alone.  Do NOT blame Jim if the Charleston code fails to work, instead let me know via email at: wb4jfi@knology.net.

I have a variation of Jim's quisk.py code that also displays a filter-bandwidth shadow on the screen, that changes with the modulation, bandwidth, and frequency.  It is still in the experimental phase, as it is somewhat sluggish in moving around the screen.  If interested, contact me for how to add this.

I am not a Linux or Python expert by any means, I am a simple code-hacker with C.  There are probably much better ways to do some of the stuff included here.  If so, please let me know, as I am always willing to learn more.  I've not messed with Python at all before this, and a little GNU Radio coding.

In order to compile the Charleston code for Quisk, you need to first compile the main Quisk files.  Go to the quisk file (cd ~/quisk3.4.7), then compile the code with make (make).  Notes here are based on Ubuntu 10.04LTS.

(add here about any quisk dependencies)

The Charleston software uses libusb for the USB interface to the Digilent board.  Before compiling the Charleston suport software, make sure you have installed "libusb"(libusb-0.1-4) and "libusb-dev" (libusb-dev).  For Ubuntu, I usually use the Synoptics Package Manager and search for libusb.  Both files should be listed.

Make sure the Charleston files are in a subdirectory of quisk named "charleston", move them there if necessary, otherwise the Python links won't work right.  Then cd to that directory and do a "make in that directory to compile the Charleston code.

If after compiling, you get an error saying something like: 
AttributeError: 'module' object has no attribute 'BitmapFromBuffer'
You need to copy a wx gtk file, as follows:
cd /usr/lib/python2.6/dist-packages(return)
sudo cp wx-2.8-gtk2-unicode.pth wx-2.6-gtk2-unicode.pth(return)


Good luck, and enjoy!
73s
Terry, WB4JFI


