Saving raw data after correct frame reception

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,

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?

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

On Tue, Apr 22, 2014 at 4:20 PM, Nemanja S. [email protected]
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”.

On Thu, May 8, 2014 at 11:29 PM, Nemanja S. [email protected]
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.

On Thu, May 15, 2014 at 3:09 PM, Marcus Müller
[email protected]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.

On Mon, May 12, 2014 at 2:45 AM, Mostafa A.
[email protected]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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs