Have anybody tried that using USRP2 to received bursts of data rather
than
countinous?
I have tried doing this as the the sampling rate is very high and I have
a
several blocks (that are calculation intensive) in my flow graphs. I am
not
really interested in receiveing all the samples. reading a 1000 samples
each
1 second is fine. I tried doing this y modifying the MIMO sourse
already
implemented. by doing this:
What happens is that it reads the first 1000 samples and this stops,
displaying a message that the block doen’t produce any output.
The return values from the work function are important here. First, you
get the 1000 samples. After that, a call to recv returns 0 samples and a
timeout. A return value of zero to gnuradio means: stop the flowgraph
and complain. However, if you return -1, the flowgraph will properly
shutdown. So, you may want to maintain a count of received samples and
return -1 after that amount has been accumulated.
Also, if you want to receive multiple 1000 sample bursts, you will have
to issue multiple commands. If those busts are non-contiguous, you
should use STREAM_MODE_NUM_SAMPS_AND_DONE
Yes, I am interested in multiple bursts so Iam using the
NUM_SAMP_AND_DONE
repeatedly.
If I understood what you’ve said correctly, hte following code may be
working. I havent tried it because I’m at home but would be grateful if
you
tell me what you think of the modified code below.
Regards.
int work( int noutput_items, gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items ){
set_streaming(true);
uhd::rx_metadata_t metadata; //not passed out of this block
int size = _dev->get_device()->recv(output_items, noutput_items,
metadata, type,
On Thu, Aug 05, 2010 at 06:09:43AM -0700, Zohair wrote:
gr_complex temp_in[vec_len];
repeated 1000 times then a new value repeated 1000 times and so on. What I
was expecting as you know is to see 1000 differnt samples then a pause then
1000 samples and so on. I wonder if this is the real output or it’s
scheduler issue between the two blocks, though the printing block is such a
conceptual copy of the howtosquare.
I have tried the code above and used a printing block with the following
work function and vec_len=1 to see the output of one of the MIMO source
output ports:
for (int i = 0; i <noutput_items; i++){
memcpy(&temp_in[0],in,vec_len*sizeof(gr_complex));
for (int k=0; k<vec_len; k++) std::cout<<temp_in[k]<<std::endl;
}
return noutput_items;
}
However, if the size variable is 1000 the output printed is a value
repeated 1000 times then a new value repeated 1000 times and so on. What
I
was expecting as you know is to see 1000 differnt samples then a pause
then
1000 samples and so on. I wonder if this is the real output or it’s
scheduler issue between the two blocks, though the printing block is
such a
conceptual copy of the howtosquare.
If you continually request bursts of 1000 samples, you will get 3
packets for each burst of the following sizes max_len, max_len,
1000-2*max_len. You can verify this behavior in wireshark or in the
examples/rx_timed_samples.cpp
So, when you issue a command for 1000 samples:
What happens when you give recv a buffer larger than 1000 in
full-buff-mode?
recv will fill the buffer until it times out
What happens when you give recv a buffer smaller than 1000 in
full-buff-mode?
recv will return when the buffer is full, the next call to recv
will fill in your buffer starting at the remaining fragment
I hope that explains what you are seeing. Ignore the notes about the
timeout (that went away when I added the timeout parameter). Note to
self: fix docs.
-Josh
BTW, you can pipeline the stream commands, you can issue several at
once, and then issue a new command every 1000 samples.
however, the size is not accurately 1000 as I requested in the
_set_streaming function. sometimes it’s much higher and sometimes much
lower.
1- Is there any hazards in this modification?
2- I have no interpretation for the in accuracy of getting 1000
samples,
any clue about this? here’s a sample of what I get;
This seems to be cumbersome
Anyway, It may be easier to drop packets rather than samples, ,let’s say
I
want to drop 9 packets from each ten and only make use of one! Do you
think
this is really easier??
Josh B.-2 wrote:
recv will fill the buffer until it times out
self: fix docs.
    int size =  _dev->get_device()->recv(output_items, noutput_items
        printf(“size after: %i\n”,size);
any clue about this? here’s a sample of what I get;
size before: 1585
Waiting for your response.
On 09/08/2010 11:33 AM, Zohair M. Abu Shaban wrote:
2- I used UHD but slightly dealt with VRT.
And, I cannot make a clear comparison between them, any brief about
this, please?
VRT is a protocol, which is the data packet format which we send over
ethernet. UHD is the driver which sends data via VRT and also does all
of the control of the hardware as well.
I’m going towards the end of my MSc project and I need help with
references for the report. I have seen the list of academic material on gnuradio.org but it seems quite old (USRP). I am using USRP2 and UHD and
have the following questions:
1 -Does anybody know an updated list of academic resources: books,
theses, reports …etc.
2- I used UHD but slightly dealt with VRT. And, I cannot make a clear
comparison between them, any brief about this, please?
3- How can I give reference to this forum without having to add every
single thread I used or asked?
IF you give me some help with these issues, I would be most grateful.
Best regards to all those who helped me thought my project and special
thanks to Eric and Josh.
Thanks Matt for the information.
Actually, I meant to ask a wider question about the difference between
the
UHD branch and VRT branch. In other words, “what’s new”
Regards,
Zohair
From: “Matt E.” [email protected]
Sent: Thursday, September 09, 2010 12:08 AM
To: “Zohair M. Abu Shaban” [email protected]
Cc: [email protected]
Subject: Re: [Discuss-gnuradio] references: USRP2, GNURadio, UHD and VRT
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.