discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Oscilloscope/FFT layout, data source, etc...


From: Ryan Seal
Subject: [Discuss-gnuradio] Oscilloscope/FFT layout, data source, etc...
Date: Thu, 30 Nov 2006 12:15:59 -0400
User-agent: Thunderbird 1.5.0.7 (X11/20060909)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]