# Saving raw data after correct frame reception **URL:** \ **Category:** GNU Radio\ **Created:** [April 22, 2014, 10:22am UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592 "2014-04-22T10:22:16Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Detlef\_R](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/58f4c7/32.png) [@Detlef\_R](https://www.ruby-forum.com/u/Detlef_R)\ **Post date:** [April 22, 2014, 10:22am UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592/1 "2014-04-22T10:22:16Z")
hi all guys, I would like to be able to store raw data into file after correct frame reception. For this reason I suppose there should be a block that buffers raw data and wait for the trigger to store into file. The trigger can only be sent from packet deframer after checking validity. So my questions are how could I synchronize those two blocks and what should be the minimum length of the buffer, and what would be the optimal way to do this, cause my processor is already under 90% of load. Best and thank you, ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 8, 2014, 5:22pm UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592/2 "2014-05-08T17:22:48Z")
Hi all again, regarding my previous email, I would like to ask you is there any more efficient way to buffer data in gnuradio except makind a block that just copies samples and waits for the signal to store them into file? ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 8, 2014, 5:30pm UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592/3 "2014-05-08T17:30:12Z")
Ah, it has just came to my mind the following idea: a block with history value of few miliseconds connected directly to usrp source. The history can provide me previous data, but I would like to hear if something like this has sense? best ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 9, 2014, 3:32am UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592/4 "2014-05-09T03:32:50Z")
On Tue, Apr 22, 2014 at 4:20 PM, Nemanja S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > hi all guys, > > I would like to be able to store raw data into file after correct frame > reception. For this reason I suppose there should be a block that buffers > raw data and wait for the trigger to store into file. > The trigger can only be sent from packet deframer after checking validity. > So my questions are how could I synchronize those two blocks and what > should be the minimum length of the buffer, and what would be the optimal > way to do this, cause my processor is already under 90% of load. The built-in File Sink block comes with option of “unbuffered” or “buffered”, but not any trigger as what you described above. If workable, most likely you will need to create custom blocks for this. Big buffer may seem to reduce CPU utilization, but it increases RAM usage and latency. You may want to consider also your memory usage and latency, in addition to the “90% of load”. ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 9, 2014, 3:45am UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592/5 "2014-05-09T03:45:07Z")
On Thu, May 8, 2014 at 11:29 PM, Nemanja S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Ah, it has just came to my mind the following idea: > a block with history value of few miliseconds connected directly to usrp > source. The history can provide me previous data, but I would like to hear > if something like this has sense? This doesn’t make sense. Historical data means the input elements are repeated even after they have been consumed previously. Unnecessary historical value increases CPU utilization. More importantly you don’t need historical value because you just need to save the data into a file. ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 16, 2014, 3:07am UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592/6 "2014-05-16T03:07:02Z")
On Thu, May 15, 2014 at 3:09 PM, Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > If, on the other hand, you try to get a history of several thousand > samples, this might exceed the actual buffer size or reduce the free space > for the source so that efficient “large sample chunks at once” behaviour is > no longer possible, and that might hit your CPU in the end. > > Greetings, > Marcus Thank you for highlighting this to me. ---
**Author:** ![Nemanja\_S](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/7bcc69/32.png) [@Nemanja\_S](https://www.ruby-forum.com/u/Nemanja_S)\ **Post date:** [May 15, 2014, 8:16am UTC](https://www.ruby-forum.com/t/saving-raw-data-after-correct-frame-reception/240592/7 "2014-05-15T08:16:24Z")
On Mon, May 12, 2014 at 2:45 AM, Mostafa A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > Hi Nemanja, > > I think the best possible way is to connect the trigger to the block as a > message. To to that, you need to write a file\_sink block for yourself > again, for instance named my\_file\_sink. The main drawback to the message passing system is that is works asynchronously, i.e. there is no guarantee when a message may arrive relative to the data stream. So probably stream tags are more suitable for Nemanja’s case. But since I don’t understand his requirement, I better don’t comment any further. [http://gnuradio.org/doc/doxygen/page\_stream\_tags.html](http://gnuradio.org/doc/doxygen/page_stream_tags.html)