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

[Erik von Keyserlingk]

Thanks for both your answers! 

The solution proposed by Marcus where a block drops samples until it receive a message  

is definitely worth a try and I think that will solve my problem also in an easier way.

I think that Glens event detection block will come in handy sometime in the future!

Cheers

Erik

Den ons 30 jan. 2019 kl 18:49 skrev Glen I Langston <address@hidden>:

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
>