On Wed, Oct 29, 2014 at 1:23 PM, Garver, Paul W <garv...@gatech.edu> wrote:
> 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.
>
Thanks for the feedback. Comments below.
> 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.
>
That sounds fair. The update time is set to zero so it plots immediately.
As for the autofill, are you using the file metadata format for this or
your own? I've been wanting to make versions of these programs that read
this data from our metadata files for just this reason. And if nothing is
provided for the sample (the -r sets this on the command line) it defaults
to 1.0, which should still operate well with what you are suggesting here,
possibly with just meaningless numbers.
> 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)
>
I'd like to see what that really looks like, but I'm not opposed to it.
> 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))
>
Same again.
> Additional tasks:
>
> Problem: In gr_spectrogram_plot, the spectrogram is hardcoded to 200 FFTs.
> Make this a configurable parameter.
>
Yep, that seems wrong.
> Problem: In gr_spectrogram_plot, the timescale does not update properly
> with the file seek widget.
>
Ah, interesting. That might be a bit more difficult fix.
Can you put this work together into a git branch, probably on github forked
off gnuradio/gnuradio.git so we can see what the commits would look like? I
think these off-line analysis tools are useful, but they definitely need
work. Glad someone's interested in it!
Tom
> ------------------------------
>
> 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
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
