I think you might have misunderstood what I intended with the "Head" block. The Head's block job is just shutting down everything finally after all the measurements have been done. Wouldn't that work?

Best,

Marcus

On 14.08.23 08:47, Henry Powell wrote:
Hello again, Marcus.

I can collect the data using Vector Sink, but it always collects the data because there are no open and close commands. I can never stop Vector Sink.

On the other hand, I tried considering the scheme you suggested. The problem is that even if I reset the head block with the "tb.blocks_head_0.reset()" command, it doesn't work again. The receiver turns itself off and I cannot have the process repeated.

I am sharing all the links with you below.


self.connect((self.analog_sig_source_x_0, 0), (self.uhd_usrp_sink_0, 0))


self.connect((self.uhd_usrp_source_0, 0), (self.blocks_stream_to_vector_0_0_0, 
0))

self.connect((self.blocks_stream_to_vector_0_0_0, 0), (self.fft_vxx_0, 0))

self.connect((self.fft_vxx_0, 0), (self.blocks_head_0, 0))

self.connect((self.blocks_head_0, 0), (self.blocks_vector_to_stream_0, 0))

self.connect((self.blocks_vector_to_stream_0, 0), 
(self.blocks_multiply_const_xx_0, 0))

self.connect((self.blocks_multiply_const_xx_0, 0), (self.blocks_skiphead_0, 0))

self.connect((self.blocks_skiphead_0, 0), (self.blocks_keep_one_in_n_0, 0))

self.connect((self.blocks_keep_one_in_n_0, 0), 
(self.blocks_complex_to_mag_squared_0, 0))

self.connect((self.blocks_complex_to_mag_squared_0, 0), 
(self.blocks_nlog10_ff_0, 0))

self.connect((self.blocks_nlog10_ff_0, 0), (self.blocks_max_xx_0, 0))

self.connect((self.blocks_max_xx_0, 0), (self.blocks_file_sink_0, 0))

# self.connect((self.blocks_nlog10_ff_0, 0), (self.blocks_vector_sink_x_0, 0))


What do I need to perform the transaction without the head block receiver ever shutting down?

On the other hand, can I keep Vector Sink on or off whenever I want with the connect and disconnect commands?


Marcus Müller <mmuel...@gnuradio.org>, 9 Ağu 2023 Çar, 12:40 tarihinde şunu 
yazdı:

    Hey Henry,
    I'm forwarding this to the mailing list, so that others can have a look at 
it as well!
    Let me quickly address a few things:

    On 08.08.23 21:32, Henry Powell wrote:
    > The flow graph starts. I collect data and save it to a file with 
file_sink. I read
    the
    > file and get the maximum value from the file (differently, I can do this 
with keep
    1 in n,
    > but I would be happy if we proceed through the current situation), then I 
am
    saving the
    > maximum value in a list from the data I have saved in the file. I reset 
the file
    with the
    > file_sink open and close commands.

    Interesting! How do you know when to open / close? I ask because this 
sounds a bit
    difficult, as, depending on the blocks with which you capture and process 
your data,
    there
    might still be samples "in flight" after your collection finishes.

    > I repeat this maybe 2000 times, varying from
    > measurement to measurement. After recording all the maximum values in a 
list, the
    flow
    > graph terminates itself.
    >
    > Writing data to a file and reading from there makes me lose speed. I am 
looking
    for an
    > alternative solution to it.

    Ah, what about this concept:

                                        ┌───────────┐
       ┌────────────┐    ┌──────────┐   │Make Chunks│ ┌─────────┐    ┌──────┐   
 ┌─────────┐
       │            │    │          │   │of constant│    │Find max-│    │ Head 
│    │   
         │
       │Data Capture│───►│Processing│──►│ "single-  │───►│imum per │───►│     
    │───►│File Sink│
       │            │    │          │   │experiment"│    │  chunk │    │N=2000│ 
   │   
         │
       └────────────┘    └──────────┘   │   size    │ └─────────┘    └──────┘   
 └─────────┘
                                        └───────────┘


    Instead of "taking the data out of GNU Radio" in an asynchronous manner, 
you could look
    for the maximum within the framework of GNU Radio itself. That solves all 
the file
    handling overhead.

    You can also still save all your experimental data to a file for later 
analysis
    (just add
    *another* File Sink, after "Processing" in parallel with "Make Chunks…").

    > If you're saying that I can do it with a vector sink block, I'm trying it 
right
    now. I
    > will let you know the results tomorrow.

    Well, the Vector Sink would be easier than the File Sink, but as sketched 
above I
    think a
    different solution might be preferable.

    > Thank you for your reply. Have a nice day.
    You have good days, as well!

    Marcus

    > Marcus Müller <mmuel...@gnuradio.org <mailto:mmuel...@gnuradio.org>>, 8 
Ağu 2023 Sal,
    > 11:55 tarihinde şunu yazdı:
    >
    >     Hi Henry,
    >
    >     that sounds like the description of the Vector Sink block!
    >
    >     But in all honesty, maybe you want to take a different approach 
altogether; really
    >     depends
    >     on when during the life cycle of a flow graph you need that data. 
Could you maybe
    >     describe
    >     how often and when you want to get data from your GNU Radio flowgraph?
    >
    >     Best regards,
    >     Marcus
    >
    >     On 08.08.23 07:26, Henry Powell wrote:
    >      > Hello, at the end of my grc I use file sink and then, I read the 
data from
    the file. I
    >      > repeat this process so many times. My problem is that writing to 
files and
    reading
    >     from
    >      > them takes too much time, approximately 120ms. I know this does 
not seem
    too much but
    >      > for my application it's too much. So, I want to append data to a 
list and
    get from
    >     there.
    >      >
    >      > I tried writing an embedded python block via this link:
    >      > https://wiki.gnuradio.org/index.php/Embedded_Python_Block
    >     <https://wiki.gnuradio.org/index.php/Embedded_Python_Block> but i 
failed.
    >      >  Is there any example embedded python block you wrote about 
before? Or a
    different
    >     solution?
    >      >
    >      > If you can help me, I would really appreciate it.
    >

Reply via email to