Re: [Discuss-gnuradio] Custom Block ID as variable

[Glen I Langston]

The actual GitHub command is

git clone http://GitHub.com/glangsto/gr-nsf

sorry for any confusion.

Glen

> On Jan 30, 2019, at 12:37 PM, Glen I Langston <address@hidden> wrote:
> 
> Thanks for both the question and the answer!  
> 
> 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
> <eventwrite-simulation.png>
> <eventwrite-screenshot.png>
> 
> 
>> 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
>