Forum: GNU Radio "Continuous Stream Reading" off of the usrp_rx_cfile.py capture possible?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Bishal T. (Guest)
on 2009-05-27 23:31
(Received via mailing list)
Dear list,
  I have one question regarding the samples captured using
usrp_rx_cfile.py
at the receiver. Is there anyway that I let the usrp_rx_cfile.py run
forever, and it will keep on capturing samples through USRP forever,
while I
keep on taking out 10K samples (lets say) at a time from that
"continuous
capture", and process them for xyz(..). Then next time I take out the
NEXT
10K samples and process them for xyz(..). Meanwhile, the
usrp_rx_cfile.py
continuously keeps on capturing the samples off of the air using USRP
uninterrupted?

One naive way, I can think of is, saving each 10K samples in a different
file one after another, but I fear i might miss some samples or some
other
disaster may occur that I am not being able to foresee. I wanted to hear
your thoughts/suggestion/anger?

-Sincerely,
Jason U. (Guest)
on 2009-05-28 00:36
(Received via mailing list)
>   I have one question regarding the samples captured using usrp_rx_cfile.py
> at the receiver. Is there anyway that I let the usrp_rx_cfile.py run
> forever, and it will keep on capturing samples through USRP forever, while I
> keep on taking out 10K samples (lets say) at a time from that "continuous
> capture", and process them for xyz(..). Then next time I take out the NEXT
> 10K samples and process them for xyz(..). Meanwhile, the usrp_rx_cfile.py
> continuously keeps on capturing the samples off of the air using USRP
> uninterrupted?

The easiest way I think to do this would be just pipe the output of
the gnuradio data into your handler program.  Of course this limits
you to the maximum buffer size in the pipe (64KB on linux I think?).

If that's no good, you would probably be better off simply writing
your own gnuradio block to handle the processing and produce whatever
output you require
(http://www.gnu.org/software/gnuradio/doc/howto-wri...).

Finally, If you absolutely need to process the data outside of
gnuradio for some reason and the tcp_sink/pipe method doesn't work you
could make a 'rotating sink' by following the same directions, but
using the gr_file_sink as a baseline.  You could write n samples to a
file, then write n to a second file, then switch back to the first.  I
think it would pretty simple to re-write gr_file_sink to do this; just
remember that if have more than one of these sinks active they may not
be exactly in sync.

If none of these are ideal you could let us know your motivation
behind wanting this scheme to work and we might able to present you
with a better way to go about it.

Jason
This topic is locked and can not be replied to.