[USRP-users] X310 set_timed_command and get_gpio_attr

Michael R. Freedman mfreedman at ll.mit.edu
Tue Mar 19 20:54:11 EDT 2019


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" );


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" );
     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?


More information about the USRP-users mailing list