discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: Marcus Leech
Subject: Re: [Discuss-gnuradio] Oscilloscope/FFT layout, data source, etc...
Date: Thu, 30 Nov 2006 11:28:57 -0500
User-agent: Thunderbird 1.5.0.8 (X11/20061025)

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).
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


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.






reply via email to

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