I’ve been puzzling over how to selectively capture data also
and how to feed info back to gnuradio graphs, based on the detected data.
I will try Marcus’s message-to-variable and variable-to-message blocks.
We did create general purpose data-capture blocks for radio astronomy, that identify events
based on the significance of the input samples compared to the RMS of the
data stream. The python code uses a circular buffer, and the output, captured, data stream
has the event centered in the middle of the buffer, so we can look at the intensities
before and after the _identified event_. The writing is separated from
detection, so that not much astronomy info is needed to detect an event. The
astronomy info is contained in the _event sink_ block.
A counter-based capture could easily be implemented as well, based on our blocks.
We use variable tags to send the peak, rms and event time downstream. This is all
done in python. The computers I’m using can only deal with about 1MHz
bandwidth. I’m working on a port to C++, to allow increased sample rates.
One note, our graphs did not work properly unless the data stream continuued
after the event was detected. i.e. our (perhaps simple minded) implementation
would hang up all data flow unless we provided the output vector continually.
So our block repeatedly provides the _captured_ sample output stream,
until the next event is detected.
Our event capture blocks are obtained with
git clone http://www.github.com/gr-nsf/
And the “examples" directory has eventdetect.grc and eventwrite.grc
that use simulated data, and require no source blocks.
Best regards,
Glen
On Jan 30, 2019, at 11:26 AM, Müller, Marcus (CEL) <address@hidden> wrote:
Hi Erik,
I'm not sure I'd do it the way you do; wouldn't something that simply
only lets through N samples each time after you send a message or call
a function be better? There's nothing "forcing" a block to "forward"
input to an output. On the contrary, you can just consume from the
input without producing on the output of your block.
That makes things quite a bit easier. Write a block that drops all
samples, unless it gets a message (via a message port: see [1]), then
it passes N samples.
How to send that message? Basically, you could write your own block
which has a <callback> attribute that gets called when a value changes,
and use one of the Qt GUI widgets' IDs as variable in there.
Or you can basically use my variable to message source [2]. I haven't
tested it in ages, and I wrote it as a debugging tool, because I don't
consider it architecturally wise in the long run¹, but it might just be
useful for this very specific use case.
[1]
https://wiki.gnuradio.org/index.php/Guided_Tutorial_Programming_Topics
[2]
https://github.com/marcusmueller/gr-msgtools/blob/master/python/variable_to_msg.py
¹ The future is bright and RPC-y; I'd love GRC to migrate from sharing
state between blocks via random Python objects to communicating via
messages in general, but we're clearly not there yet.
On Wed, 2019-01-30 at 17:06 +0100, Erik von Keyserlingk wrote:Hi,_______________________________________________
I am developing a program with GRC where I want to take N samples. (The hardware is a HackRF-one). I want to take N samples because I want to measure at certain points with a H-field probe.
The way I have thought to solve it is to develop a custom block, "sampling counter" (in python), to count the number of samples that have passed and after N samples it changes its value from 1 to 0 and a "selector" block is directing other samples to /dev/null. This works with a "check box" where a user can set/unset and change where the stream goes, either into a file or to /dev/null. See attached flowgraph.png.
TLDR:
Q: How to implement the ID of a custom block so that it can be used as a variable as from a checkbox, slider etc. Both in python an xml, that is what is needed to be added in the .xml file and in the .py file to use the ID as a variable?
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio