3. Considering that we only need 650ms, no matter how long we
send(like 10s or more). We guess there is a fixed size cache in the
usrp and it send the cached data at a precise-controlled time, but I
can not persuade myself.
Can anyone interpret the strange phenomenon? Any suggestion is
appreciated, thank you!!
The is buffering in the USRP2, about 1 MB. Give your sample rate and 4
bytes per >sample you can approximate the sleep time.
The more proper way to do this is to send an end-of-burst tag with the last
sample >and to wait on the async message queue for a burst ACK packet.
About the TX tags for the sink block:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n52
Also see the async message source:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_amsg_source.h
Dear josh,
Thanks for your help very much!
But I still have puzzles about the extra time such as 0.65s when
I set the bit rate to 1M. we set the program to send 4s, and use
wireshark and find the data through the network card continued for
4.65s, it indicates that the data be sent the last 0.65s is still in
PC, in GNU-Radio’s FIFO, not in USRP’s buffer. Is it?
If so, why we use half the time, that is the time changed from 0.65s
to 0.32s when we set the bitrate from 1M to 2M? the data proceed in
PC should be fixed and unrelated to the transmission rate, and much
lower than the transmission rate, so the time processing the same
amount data which stored in gnuradio’s FIFO must be still 0.65s, is
it?
Thanks very much again!
Best regards and good luck!
If so, why we use half the time, that is the time changed from 0.65s
to 0.32s when we set the bitrate from 1M to 2M? the data proceed in
PC should be fixed and unrelated to the transmission rate, and much
lower than the transmission rate, so the time processing the same
amount data which stored in gnuradio’s FIFO must be still 0.65s, is
it?
If I am understanding correctly:
- Gnuradio creates a fixed amount of buffering
- The data source produces data faster than USRP consumes
- The buffering in gnuradio becomes filled 100% with samples
- The USRP consumes samples from this buffer at a fixed rate
So I think it makes logical sense that when you increase sample rate
(USRP consumes faster), the time to drain the buffer decreases.
Also, I want to point out:
There is a hook to control the size of these buffers in gnuradio
(presumably to reduce flow graph latency). You may be interested in
modifying this number and experimenting:
void start(int max_noutput_items=100000);
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63
-Josh
On 04/25/2012 11:53 AM, [email protected] wrote:
Oooh, is there a configurable parameter for that in GRC yet?
Not yet. It would fit well in the options block. Pretty easy to add, but
it would be a little more change to get the parameter into the WX gui
top block class. Qtgui and nogui mode both directly call the flow graph
start/run method, so the code change is purely in the generator.
-josh
Oooh, is there a configurable parameter for that in GRC yet?
On
Wed, 25 Apr 2012 11:33:34 -0700, Josh B. wrote:
Also, I want to
point out:
There is a hook to control the size of these buffers in
gnuradio
(presumably to reduce flow graph latency). You may be
interested in
modifying this number and experimenting:
void
start(int max_noutput_items=100000);
http://gnuradio.org/cgit/gnuradio.git/tree/gnuradio-core/src/lib/runtime/gr_top_block.h#n63
[1]
-Josh
Links: