I am trying to make 2 TX 1Rx tagged stream block(OOT). For 1Tx 1Rx, it was working fine. I am trying to extend it. Now the problem is, I am not being able to configure the send() function.Is there a particular reason you're creating your own block? Is there a feature missing on the USRP sink and source that come with gr-uhd?
If I try make test, it does not show any problem.Since you wrote those tests: what are they covering?
your send() function looks a bit strange; what you're doing is transmitting two things on a single channel after each other. Also, what you should be doing (from a programming style point of view) is pass the buffers you want to send as references or something, but not save them to class properties and then call send().
To send two buffers to two different channels, you will need to use a vector containing the two buffers -- have a look at rx_multi_samples; that of course recv()s rather than sends(), but the semantics are the same.
noutput_items = ninput_items[0]=ninput_items[1];That's wrong.
noutput_items is given to you to let your work now how much it may produce, that's why it's a parameter. overwriting that with the number of input items in the 1st input stream doesn't make much sense, and setting ninput_items[0]=ninput_items[1] makes even less!
d_thread_send = gr::thread::thread(boost::bind(&usrp_echotimer_cc_impl::send, this));Uh-oh. This is where things will definitely go wrong. You break every multithreading rule there is, by not restricting access to your internal state, especially d_send_*! There's no reason GNU Radio couldn't already call your work function again while usrp_echotimer_cc_impl::send() hasn't even started to transmit samples. Then, your d_send variables will be overwritten. I really doubt this will work reliably, even in a 1TX 1RX configuration, but multithreading makes it really hard to notice such mistakes.
I think what you're trying to do is most probably already implemented in the USRP sink and source blocks:
Since a single X310 is inherently coherent and has the same time, you can simply use a USRP sink and a source, use set_start_time(...) on both with the same time spec, and have your flow graph consume and produce samples in different threads, coherently.
Best regards,
Marcus
Hi all,
I am trying to make 2 TX 1Rx tagged stream block(OOT). For 1Tx 1Rx, it was working fine. I am trying to extend it. Now the problem is, I am not being able to configure the send() function.
If I try make test, it does not show any problem. However, when I check after reception I find that 1 transmitter is transmitting, and another is not. I checked the every port of my USRP X310, it is working fine.
Here's the code. I putting a short part where I have problem. Please let me if you need the header and grc file as well, to correct the code.
- - -
void
usrp_echotimer_cc_impl::send()
{
// Data to USRP
num_tx_samps = d_tx_stream->send(d_in_send1, total_num_samps, d_metadata_tx, total_num_samps/(float)d_samp_rate+d_timeout_tx);
num_tx_samps = d_tx_stream->send(d_in_send0, total_num_samps, d_metadata_tx, total_num_samps/(float)d_samp_rate+d_timeout_tx);
}
int
usrp_echotimer_cc_impl::work (int noutput_items,
gr_vector_int &ninput_items,
gr_vector_const_void_star &input_items,
gr_vector_void_star &output_items)
{
gr_complex *in0 = (gr_complex *) input_items[0];
gr_complex *in1 = (gr_complex *) input_items[1];
gr_complex *out = (gr_complex *) output_items[0];
// Set output items on packet length
noutput_items = ninput_items[0]=ninput_items[1];
// Resize output buffer
if(d_out_buffer.size()!=noutput_items) d_out_buffer.resize(noutput_items);
// Send thread
d_in_send0 = in0;
d_in_send1 = in1;
d_noutput_items_send = noutput_items;
d_thread_send = gr::thread::thread(boost::bind(&usrp_echotimer_cc_impl::send, this));
// Receive thread
d_out_recv = &d_out_buffer[0];
d_noutput_items_recv = noutput_items;
d_thread_recv = gr::thread::thread(boost::bind(&usrp_echotimer_cc_impl::receive, this));
-----
My system config is X310, daughterboard SBX-120 and I am using UHD-3.9
I checked the subdev specification, gain and frequency assignment. Those are fine.
Please let me know how to correct and thanks in advance.
best regards
Sanjoy
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment