On Wed, Nov 5, 2014 at 10:24 PM, Garver, Paul W <garv...@gatech.edu> wrote:
> Hey Tom,
>
> I'll pull together the git branch and let you know when it's ready. As
> for gr_spectrogram_plot, we do use the standard GR header format, with some
> "extras" such as center frequency. I think it would be useful in the
> metadata format to have center frequency, seconds/sample, and file length
> in seconds for the next metadata version. I should also mention I have
> some simple scripts to make headers for header-less data with command line
> args. I'm working on expanding them so they can do data type conversion
> and modification of headers as well.
>
Does that mean you've changed the format of the header? These things are
really only useful if we're all using the same structure. The "extras" part
of the header is designed to hold stuff like that, too, or is that what you
meant? As for the extra parameters, you have samples/second, so why would
you need seconds/sample? And with the samples/second and item count in the
headers, you can calculate the length in seconds easily.
> The time axis scaling is next on my list to do. Any suggestions on where
> to begin? I was thinking of adding some functions to the spectrogram plot
> to do this. Then in the plot reset function, manually set the scale
> properly. There are probably more elegant ways to do this, but I don't
> want to break existing functionality with the on-line mode. I think the
> Y-Axis zero point is based on the timestamp, which makes total sense in
> "on-line" mode. I suppose we could keep that convention and generate fake
> timestamps for off-line mode. That would also work well when we have real
> timestamps in the headers. I also think it would be good to have a key
> toggle to switch between time and sample number. I want to identify
> interesting features in the spectrogram and then be able to cut out a
> section of a much larger file for analysis.
>
> PWG
>
It doesn't get the time info from a time tag, just from the system's timer
itself using the gr::high_res_timer_type. So we'd have to pass this
information through to the plotting widget.
Tom
> ------------------------------
> *From: *"Tom Rondeau" <t...@trondeau.com>
> *To: *"Paul W Garver" <garv...@gatech.edu>
> *Cc: *"GNURadio Discussion List" <discuss-gnuradio@gnu.org>
> *Sent: *Monday, November 3, 2014 6:16:38 PM
> *Subject: *Re: [Discuss-gnuradio] gr-qtgui Waterfall Time Axis
>
>
> 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
