Wednesday, May 14, 2014

Tiny Python Panadapter (QST 4/2014)

[This posting refers to my QST magazine article, "A Tiny Python Panadapter", April, 2014, pp 33-38.  For latest information, see my website. The code repository and a support mailing list are available at SourceForge.net.]

Message from Gary KM5TY:

I'm interesting in putting together my own panadapter, however am not gelling with the idea of the low bandwidth around a signal / amount of spectrum visible with just a sound card. I am thinking that a dedicated sampling board taking in 500kHz to 1.5MHz possibly more would be much more interesting. What do you think of adding such a piece of hardware to a Raspi or Beaglebone? Would the python code be a bottle neck for the data?
Of course, more bandwidth would be very nice.  Unfortunately, to go beyond the simple soundcards for the Tiny Python Panadapter would require considerable new work or expense.  You'd have to consider the following
  • Limited CPU power of the tiny cards.  The RPi is already marginal with a 48 kHz sample rate (equivalent to 192 kBytes/sec). [Note added: We've recently made a big improvement for the Pi by downgrading to USB1.1.  The default USB 2.0 can't handle our continuous stream.] You could get to higher rates by starting over with hand-tailored C/C++ code, but there would still be a limit.
  • Cost.  The USB soundcards and the RPi/BBB are commodity items that let us do interesting things in the sub-$100 range.  Fast ADC boards are going to be more expensive, if they are available for small platforms -- or you can design & build your own out of chips.
  • Proportionality.  The systems you're suggesting are on the market already - like the QS1R and the Flex 6000 line.  These are great products, but expensive.  They are built with high performance FPGA and/or PC-level computing power.  It would be interesting to develop and open-source a free alternative project.  (Some are already out there, like openHPSDR.) But that's well beyond TPP's scope.
On the one hand, it's fun to try to squeeze all the performance you can from a $35 or $45 computer board.  On the other hand, be realistic!  It's so much easier to work with a modern full-size PC.  They are incredibly fast, even the budget models.  How many hours of programming time is it worth to cram the functionality into a tiny board, while saving only a few hundred dollars?  (My time is worth something, isn't yours? :)  In the end, cheap hardware and miniaturization are good, but they're not everything.

It's economic thinking like this that led me to see what could be done with Python on the tiny boards.  At least for me, Python is much "cheaper" to develop with than the C/C++ alternatives.  The added benefit was that it should be easier for "newbies" to pick up and modify.