[Top][All Lists]

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

Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis

From: Garver, Paul W
Subject: Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis
Date: Wed, 29 Oct 2014 13:23:49 -0400 (EDT)

I've solved this and wanted to share my solutions, as well as improvements (to 
me, anyways) to GR's off-line plotting tools (gr_spectrogram_plot). My overall 
goal here is to be able to do some analysis on wideband (25MSPS) data using GR 
since MATLAB isn't really efficient for that.

I've seen some interesting updates regarding gr-qtgui on the git commit log -- 
I'd be very interested in comments from those folks so I know what's in the 
pipeline and perhaps what you would want to pull into the baseline.

Below is a list of issues I've encountered and what I've done to fix them.

Problem:In gr_spectrogram_plot_c, the time scale always reads 0.

Solution: In waterfalldisplayform.cc, d_update_time is passed as the timePerFFT 
argument to plotNewData (WaterfallDisplayPlot object). This happens in 
WaterfallDisplayForm::newData(). However, gr_spectrogram_plot sets this to zero 
by calling set_update_time(0) on the waterfall_sink_c_impl object. In 
waterfall_sink_c_impl.cc it calls the postEvent() function with d_last_time, 
which is a variable representing the time between waterfall updates. 
Ultimately, this is regulated by d_update_time, which is set to zero by the 
set_update_time(0) call. The net result is that timePerFFT is always zero, 
resulting in an improperly set timescale. The proper thing to do here is to set 
timePerFFT based on the FFT size and sample rate in off-line mode. Obviously, 
this assumes you know the sample rate, but since I've modified 
gr_spectrogram_plot to read files with headers and autofill stuff (sample rate, 
frequency, data type, etc) appropriately, it always does.  It appears that you 
won't be necessarily processing every sample if you don't set d_update_time=0, 
which you want to when running off-line.

Problem:In gr_spectrogram_plot, the cursor pointer only gives readings to a 
100th of a second. For analysis, it would be more useful to have scientific 
notation which scales with higher sample rates.  

Solution: In WaterfallDisplayPlot.cc, change .arg(secs,0,'f',2) to 

Problem: In gr_spectrogram_plot, the time scale is in in hundreds of a second. 
It may be more useful to have the plot in scientific notation.

Solution: In WaterfallDisplayPlot.cc, change 
QwtText(QString("").sprintf("%.1f",secs)) to 

Additional tasks:

Problem: In gr_spectrogram_plot, the spectrogram is hardcoded to 200 FFTs. Make 
this a configurable parameter.

Problem: In gr_spectrogram_plot, the timescale does not update properly with 
the file seek widget.


Message: 12
Date: Tue, 21 Oct 2014 16:00:15 -0400 (EDT)
From: "Garver, Paul W" <address@hidden>
To: address@hidden
Subject: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis
Content-Type: text/plain; charset=utf-8

I have some large spectrum records and I would like to use GR for analysis in a 
a sort of "off-line" mode.  I want to visualize the data using the spectrogram 
and then identify subsets of interesting features (e.g. WiFi Packets in 2.4 
GHz) by frequency and time coordinates.  Essentially, I want to know what index 
in the file certain features correspond with so I can save them as separate 
files.  To this end, I've found gr_spectrogram_plot very handy, but it doesn't 
quite do what I want because the y-axis which displays time isn't showing up 
correctly.  My y-axis is always 0.0, and the cursor highlight also reads 0.0 
(although the frequency is correct).  However, the qt spectrogram appears to 
have correct time information when I make a simple file source -> qt 
spectrogram sink.  

I'd like to fix this issue so I've been pouring over the code in gr-qtgui.  I 
don't have much experience with QWT or Python GUIs in general.  From what I can 
tell, there are methods for frequency axis and intensity scaling, but not time. 
 Is this true or am I missing something in the API?  The historyExtent 
parameter in the WaterfallData constructor appears to get hardcoded to 200 in 
WaterfallDisplayPlot.cc (gr-qtgui/lib).  It would also be nice to toggle 
between the time and sample number.

I'm happy to do the work to implement this.  Could someone point me in the 
right direction here?  Thanks!


reply via email to

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