Hi Xavier,
I'm currently using 3.13.1.0-4 but was going to give 3.14 a try this
morning.
Mike
On 03/20/2019 07:42 AM, Xavier Arteaga wrote:
Hi Mike,
I saw some similar issue setting timed commands for changing the
sampling rate in 3.14.
What UHD version are you using?
Did you try 3.9.7 LTS? And 3.10.3?
Thanks,
Xavier
On Wed, 20 Mar 2019 at 01:56, Michael R. Freedman via USRP-users
<[email protected] <mailto:[email protected]>> wrote:
Hello,
I have multi_usrp setup with many USRPs that are all doing timed
sampling. The sampling intervals need to be as fast as 1ms
sampling for
999us. In addition, at the start of the sample window, I need to
grab
the state of the GPIO pins on the front panel. I have tried the
following :
Single rx_streamer for all channels (as many as 10):
streamCmd.num_samps = numGates;
streamCmd.stream_now = true;
streamCmd.time_spec = 0.0;
usrp_->set_command_time( startTime );
rxStream_->issue_stream_cmd( streamCmd );
gpio = usrp_->get_gpio_attr( "FP0", "READBACK" );
usrp_->clear_command_time();
This works for one channel fairly well, but when multiple channels
are
used the channels fail to time align. I then created a separate
rx_streamer for each channel with the same block of code as above for
each channel. In this scenario, the lowest number channel would
timeout
as much or more than 50% of the time.
Next I tried individual streamers as follows :
streamCmd.num_samps = numGates;
streamCmd.stream_now = false;
streamCmd.time_spec = startTime;
rxStream_->issue_stream_cmd( streamCmd );
I only allow 10 stream commands to be queued to the usrp for each
channel and then only issue another stream command
after a successful receive. In another thread I do the following
figuring I can merge the gpio data with the sampled data after:
usrp_->set_command_time( startTime );
gpio = usrp_->get_gpio_attr( "FP0", "READBACK" );
usrp_->clear_command_time();
uhd::time_spec_t response_time = usrp_->get_time_now();
I see between 50us and 250us latency between startTime and
response_time
assuming that the bits were actually read
at the startTime.
Unfortunately in this scenario, I see channels timing out and not
recovering on occasion.
CPU Utilization is fairly low as is network bandwidth.
Does anyone have any suggestions?
Thanks,
Mike
_______________________________________________
USRP-users mailing list
[email protected] <mailto:[email protected]>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
