At https://github.com/jmfriedt/active_radar/ you will find the solution I have been using for Synthetic Aperture RADAR using GNU Radio. In this application I wish to collect coherent measurements from both reference (transmitted pattern) and surveillance (reflected signal) channels when the antenna location is stable. The GNU Radio part is https://github.com/jmfriedt/active_radar/blob/master/zeromq_demo_rev1.py is continuously streaming data using a UDP-like datagram flow based on 0MQ Publish. I selected this approach to make sure any desynchronization between channels (e.g. using RTL-SDR dongles) remains constant during the whole measurement and not restarting acquisition with a random delay for each antenna position. The antenna position is driven by an external piece of software -- I like GNU Octave but feel free to use Python -- where event are triggered in the GNU Radio flowgraph, e.g. moving the antenna, then a 0MQ socket is opened, the processing software fetches the number of samples needed (here correlation), and then continue to the next position https://github.com/jmfriedt/active_radar/blob/master/zeromq_demo_rev1.m
Closing/opening the 0MQ socket is not elegant but is the only way I found to make sure I fetch the latest data from the new antenna position and not some leftover data from a previous position. Best, JM > 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. > > > -- JM Friedt, FEMTO-ST Time & Frequency, 26 rue de l'Epitaphe, 25000 Besancon, France
