Hi Peter,

GNU Radio is based very much on the idea of a data stream, so it might
not actually be the tool of choice for static analysis.
However, there is quite a lot which can be done with on-board tools, so
let me comment in-text.
On 16.07.2014 16:52, Peter A. Bigot wrote:
> GNU Radio is a great tool for applications and dynamic
> experimentation, but it doesn't have a lot of support for
> static/offline analysis of time-series data.  I.e. I've captured some
> signal data and I want to explore its properties interactively so I
> can figure out what I want to do with it in GNU Radio.
>
> The sort of capabilities I'm looking for include: 

> Read time-series data from files of different formats (some too large
> to fit in physical memory). 
So far, only raw samples in machine float format are supported, and the
GNU Radio-specific metadata/samples interleaved format along with the
Wav audio file format. As far as I know, all of the sources/sinks for
these file formats don't need to store data in RAM but read/write it
sequentially.

If you feel like there is something obviously missing in this list, you
could just use the awesome powers of python and/or C++ to read your
favourite file format, write a database adapter or a twitter source; the
reason we don't have things like native CSV or HDF support is that I
guess noone cared to implement a source for these formats, because they
don't lend themselves to streaming very well, and not because it's hard.

Anyway, there's a series of small tools for sample files, called
gr_{plot,plot_fft,spectrogram}_<type>, that at least allow you to
visualize recorded data easily, included in GNU Radio.

> Display the data, optionally applying linear transformations.
Well the problem here is that our visual sinks usually want to
periodically update the display, and that GNU Radio flow graphs usually
terminate when sources have finished producing items (e.g. when the
source file has been read completely). Many of these issues can be
worked around be setting your file source to repeat and "pausing" the
graphical sink when you see something interesting, after throttling your
item flow enough to make the signal observable by the naked eye.

The linear transformation thing is something you'd have to implement in
a DSPish manner, and most probably can be done.
> Interactively pan and zoom. 
Most of the graphical sinks can do that
> Jump forwards and backwards among time-registered events.
Nope, I'm afraid that won't work with the stream-oriented architecture
of GNU Radio.
>   Enable/disable/time-shift data overlays.
Again, if you feed a graphical sink with a signal and a time-shifted
version, you get a DSPified method of doing your visualization
> Export selected data to new files.  
not really available (yet?).
> Calculate and display statistics and other non-linear transformations
> of selected data.
Depends. Again, if you can translate your statistics to a signal
processing algorithm, then it's almost certainly already been done or is
"easy" to do.
>
> Ideally I'd like an open-source analysis framework that I can extend
> in Python or C++; something like the Midas DSP tool family. 
Not aware of these, sorry, and google turned up some defense program
along with large audio mixers. Do you have a URL to refer to?
> I'm aware of some Qt widgets like QtCustomPlot, and generic frameworks
> like matplotlib and octave, but not of any ready-to-use applications
> or frameworks that already provide the basic functionality described
> above.
I think you should take a look at things like R, GNUplot etc.
Anyway, this is a very interesting topic, and I would really enjoy
hearing from cool software that does what you describes in a manner that
could e.g. be explained to EE first-semester students or so.
> The keywords I've tossed at Google haven't produced any obvious
> solutions, and discussions I find in the archives here are a couple
> years old and seem to summarize as "use maplotlib/octave".
I'm afraid my 2014 reply will disappoint you a little... it's "if you
know what characteristics you're looking for, go for a few lines of
python; if you don't know, go for python and some additional lines".
Actually, I've grown so used to numpy/scipy/matplotlib/pyqtgraph that I
wouldn't trade it for Matlab (I have access to that and rarely use it),
especially because python is something I would consider a real language
whereas the matlab syntax and the matlab interpreter performance...
well, matlab has fantastic documentation.

>
> Is any such framework available now or in development?  If not, is
> anybody interested in joining me offline to discuss the requirements
> and design for such a thing?
Count me in, as this is relevant to my work.

Greetings,
Marcus
>
> Thanks.
>
> Peter
>
> _______________________________________________
> 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

Reply via email to