Quisk/Charleston SDR Update

[Terry Fox]

I've spent the last week (when time allowed) fixing some of the bugs in 
my mods to Quisk for the Charleston Receiver.  As a reminder, Quisk is 
an SDR program written by James Ahlstrom, N2ADR.  It runs under Linux, 
has a decent GUI, and most importantly does not require the use of jack 
to move samples from the hardware to the dsp code, which is not DttSP.  
Quisk is a combination of C and Python.  I combined/transmorgified John 
Schwacke's Charleston code for GNU Radio and Jim's Quisk SDR-IQ code, 
which also uses USB connectivity to the host computer.

There were some issues with buffer underruns for the output audio, which 
I thought was due to CPU loading because of the graphics.  That turned 
out to be a red herring, as the problem was that I had not matched 
buffer sizes between two code pieces.  I knew they did not match early 
on, but forgot that in the excitement of seeing Quisk work with the 
Charleston board.  That's been fixed.  The software also now supports 
all the hardware controls on the Charleston board (PGA control, LNA/BPF 
bypassing, LNA High/low, and LNA gain adjustment).

Once I got the software working in a basic form, I contacted Jim 
Ahlstrom about a few minor things.  He has been most helpful, and has 
provided a better long-term framework for adding the Charleston support 
to Quisk.  He's been great to work with, especially since I'm not 
familiar with Python.

Now that I've had the Charleston Receiver working for about a week under 
Quisk, I've been able to spot some issues.  (the old GNU Radio code did 
not allow you to easily see all 192k, while tuning and hearing one 
signal very well, plus the screen updates were slow and too averaged)  
First of all, the Charleston board is more susceptible to front-end 
overload.  Having a 12-bit A/D front-end makes its dynamic range 
somewhat limited, not a surprise to us.  I've begun to use a Brainerd 
band-pass filter board in front of the receiver, which helps a lot.  I 
plan to add commands to allow the host computer to control a Brainerd 
BPF, through the Nexys2 FPGA card.  Proper PGA and preamp adjustment 
helps mitigate overload as well.  (alliteration anyone?)  Other BPFs 
could also be defined and driven from the host software.  If I put the 
BPF control totally inside the FPGA, a new FPGA bit file would need to 
be made for each different BPF, so I am choosing to put that 
intelligence in the host instead (for now).

It would be nice to create a loop where the various PGA and preamp 
controls were automatically adjusted to reduce/prevent front-end 
overload.  Unfortunately, the TI AFEDRI8201 downconverter chip does not 
have an "ADC-overload" flag/bit.  I'm thinking that I could look at the 
actual samples, and that would tell me (within a limited amount) if 
overload is occurring, such as many samples hitting the 12-bit limits.  
Unfortunately, that is not the whole story.  For example, a signal 
outside of the 192k bandwidth could be overloading the A/D itself (since 
it's sampling the total 30MHz input), but that overload is not 
necessarily within the 192k band being delivered to the host computer.  
The BPF solves some of that, but I've had a VERY STRONG SW broadcast 
signal at about 6.985 MHz get through the 40M BPF, and swamp the 
receiver, even though I am LOOKING at 7.1-7.3MHz.  Maybe if I looked at 
an average of the "noise-floor" samples, and see them unexpectedly rise 
(which happens during overload), that is an indication.  But, electrical 
storms can also cause that symptom.  Ideas anyone?

The Charleston board is decimating to a 192k output sample rate, lower 
than we had been using.  If I try to go to 384k or 480k in Quisk, I 
start getting significant audio glitching and buffer underruns again.  I 
am looking into this.  It appears to me that most of the Quisk graphics 
work is being done in Python, even though Jim says the critical graphics 
is done in C.  We have used 384k and 480k with GNU Radio, although that 
exhibited some occasional audio glitching on my older Toshiba laptop as 
well.

I plan to use Jim's new framework, and clean up my kludged code mess 
over the next week.  After that, I will release my version of Quisk with 
the Charleston mods, probably via the AMRAD web site.  If anyone wants 
to see this interim code, I can send a tarball (except to Louisiana, 
which has enough of them already).  Keep in mind that this temporary 
code will be changed drastically in the next week, but it does make the 
Charleston receiver more useful.

I'm wondering if the Quisk code can be modified to work under Windows?  
I'm not a Python expert, or even a beginner, so I'm not sure how hard it 
would be to convert it to Windows.  I feel comfortable that I can handle 
the hardware/USB conversion part.

Another Windows option for SDR usage of the Charleston receiver is the 
HPSDR Kiss Konsole.  It is written in Microsoft Visual Studio C# 2008 
(free).  It is designed to be used with the openHPSDR hardware, but uses 
libusb for USB interfacing, very similar to Quisk.  I have an openHPSDR 
boardset, and have played a little with Kiss Konsole.  Rather than use 
the Digilent driver for the Nexsys2 FPGA board, we may be able to use 
the generic libusb, which I have working in Linux.  Of course Linux's 
libusb apple does not necessarily match Microsoft's libusb orange, 
especially with USB.  I've heard that Microsoft has really screwed up 
USB implementations in Windows, and each variant of Windows has a 
different "hosing".

That's a long update on where I am for now.  More details to follow.

73s
Terry