On 02/14/2017 09:22 AM, Glen I Langston wrote:
Hi Marcus,
Thanks again for pointing me at your spectro_radiometer.grc, a very amazing
creation.
(https://github.com/ccera-astro)
Your example is a valuable in showing the many different ways GNURadio blocks
can be connected
by named Variables and Parameters.
It appears that much of the magic is in the use of your Variable called
“fft_log_status”,
which enables a complex call to your spectro_helper.py code, passing all your
sampled
vectors.
One question: Does this scheme create a separate thread that does the writing
of the
sampled data (or does this run under thread doing other functions)?
It seems that my humble goal of writing Astronomical format FITS files could be
achieved
by writing code that performs a similar function to fft_log_status.
Best regards,
Glen
Every "function probe" runs in its own thread.
If you look at the helper code, there's a function called "fft_log",
where the logging happens. This is where you'd write out a FITs file.
I take ruthless advantage of the dependency evaluator in GRC to allow my
own functions to get called on a regular basis, for various things,
including low-rate data-logging in text format.
The way it works is that the FFT vector is connected both to a
probe-vector block and a Qt Vector Display block, so the logger is "seeing"
what the vector display is seeing, more-or-less. The total power is
calculated from the FFT vector, after applying an RFI mask.
On Feb 7, 2017, at 7:13 PM, Marcus D. Leech <mle...@ripnet.com> wrote:
On 02/07/2017 05:40 PM, Glen I Langston wrote:
Hi Marcus,
I just found the problem. My device only has one channel. I deleted
all the 2nd channel stuff and the spectro_radiometer is working great.
I’ve got to find where the data is going, but I like the many features you’ve
added.
Cheers
Glen
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
