Oscilloscope/FFT layout, data source, etc

GNU Radio
1

I have been working on a wxWidget based oscilloscope/spectrum widget and
have a few questions:

First, let me cover my idea of an oscilloscope/FFT program:

  1. Data is provided from a source (USRP or file).
  2. Data is formatted to fit the plotting window (transform matrix).
  3. Data is sent to the plotting widget at specified intervals for
    display.

I am a little confused as to how this should be handled when converted
to Python. I could write 2 or 3 classes and let the main plotting widget
handle the entire show; or I could break this up and a small Python
module would combine these objects separately. To me, I view this as a
“sinking” object and a single widget would provide everything. But I
don’t want to continue without some sort of feedback. At this point, I
have a resizable window with ticks, a grid, and a few labels and have
plotted some test data and am happy with the performance so far.

A few more specific questions:

  1. Where/How do I access the USRP data stream (at the C++ level) and is
    the data buffered in a way (P/C model) that allows me to know which
    buffer is being filled and which one is ready to be read, overflows,
    underflows, etc…?

  2. Is there a standard data type (at the C++ level) that I should be
    using when loading/manipulating the data ( valarray, vector, pointers,
    gr_xxxxx, etc…)?

  3. Is wxWidgets pretty much the standard for GNURadio development? I
    have been looking around at other toolkits trying to find a good reason
    to move from QT (for various reasons) and it appears that FLTK is
    gaining momentum with other groups. Has anyone considered this? Or are
    there compatibility reasons for not going this route?

I am concerned with the C++ aspect of the USRP because I want to
integrate this card with my current system for use with radar (305-m
dish). I currently use another card (overpriced garbage IMHO) that dumps
blocks of data into shared memory (up to 40MBPS) and I can then run
multiple processes capable of processing, storing, viewing data in
real-time. I should be able to replace the current digital receiver card
with the USRP (assuming I modify the FPGA to provide a triggered mode)
and dump this data in a similar manner.

Thanks,
Ryan

2

Ryan Seal wrote:

I am a little confused as to how this should be handled when converted

have been looking around at other toolkits trying to find a good
card with the USRP (assuming I modify the FPGA to provide a triggered
mode) and dump this data in a similar manner.

Thanks,
Ryan

Some of the stuff in gr-radio-astronomy might be helpful to you, at
least in terms of your display widgets.

The Continuum display in usrp_ra_receiver.py receives data once per
second and displays it, by virtue of the
fact that the final IIR filter is arranged to always decimate down to
1Hz, with the parameters of the IIR filter
being user-settable.

Hey, when I was at the SARA meeting at Green Bank this summer, I met
Carmen Pantoja, who’s
been involved with science at Arecibo. Some day, I’ll take her up on
her offer of hospitality
in Puerto Rico, and demonstrate Gnu Radio/USRP/gr-radio-astronomy at
Arecibo.

3

On Thu, Nov 30, 2006 at 12:15:59PM -0400, Ryan Seal wrote:

I have been working on a wxWidget based oscilloscope/spectrum widget and
have a few questions:

First, let me cover my idea of an oscilloscope/FFT program:

  1. Data is provided from a source (USRP or file).
  1. Data is formatted to fit the plotting window (transform matrix).
  2. Data is sent to the plotting widget at specified intervals for display.

I am a little confused as to how this should be handled when converted
to Python. I could write 2 or 3 classes and let the main plotting widget
handle the entire show; or I could break this up and a small Python
module would combine these objects separately. To me, I view this as a
“sinking” object and a single widget would provide everything.

Seems reasonable to me. It’s a sink, it accepts “records” (vectors)
of data and plots them.

But I don’t want to continue without some sort of feedback. At this
point, I have a resizable window with ticks, a grid, and a few
labels and have plotted some test data and am happy with the
performance so far.

A few more specific questions:

  1. Where/How do I access the USRP data stream (at the C++ level) and is
    the data buffered in a way (P/C model) that allows me to know which
    buffer is being filled and which one is ready to be read, overflows,
    underflows, etc…?

Have you looked at
http://www.gnu.org/software/gnuradio/doc/howto-write-a-block.html

It spells out the basics of writing a new C++ block.

  1. Is there a standard data type (at the C++ level) that I should be
    using when loading/manipulating the data ( valarray, vector, pointers,
    gr_xxxxx, etc…)?

See howto-write-a-block.

  1. Is wxWidgets pretty much the standard for GNURadio development?

It is at this point, but there are folks talking about Qt and/or PyQt.
I have yet to see any code :wink:

I have been looking around at other toolkits trying to find a good reason
to move from QT (for various reasons) and it appears that FLTK is
gaining momentum with other groups. Has anyone considered this? Or are
there compatibility reasons for not going this route?

Independent of the conversation about a move to Qt or not, we do need
a faster plot widget for wxPython.

I am concerned with the C++ aspect of the USRP because I want to
integrate this card with my current system for use with radar (305-m
dish). I currently use another card (overpriced garbage IMHO) that dumps
blocks of data into shared memory (up to 40MBPS) and I can then run
multiple processes capable of processing, storing, viewing data in
real-time. I should be able to replace the current digital receiver card
with the USRP (assuming I modify the FPGA to provide a triggered mode)
and dump this data in a similar manner.

Sounds doable.

I’m not sure that I really answered your questions. If I missed the
mark, please ask again.

Eric