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
.arg(secs,0,'e',2)
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
QwtText(QString("").sprintf("%e",secs))
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" <garv...@gatech.edu>
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis
Message-ID:
<648612096.23852246.1413921615968.javamail.r...@mail.gatech.edu>
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!
PWG
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
