[USRP-users] timed commands not tuning the device at the desired time

Josh Blum josh at ettus.com
Thu Feb 28 12:53:55 EST 2013



On 02/28/2013 12:48 AM, Birhane Alemayoh wrote:
> Dear all
> 
> I have written a piece of code to test timed-commands.
> 
> My application implements two threads the first thread to tune USRP
> periodically every 1.5 seconds from now and the second thread to display
> the overall receiving chain frequency that is to observe whether the tuning
> takes place in the desired time. below is the implementation of
> timed-command for timed tuning of the USRP
> 

Not sure if this is the problem. I have one suggestion, put a mutex lock
around the usrp->set/clear_command_time(tune_time); block, and around
control commands on the other thread. I am worried that the listening
thread may be using commands when the command time is set.

Also, what does this mean:
> Actual RX Freq after hopping: 935.600000 Mhz... at time: 1.50258
>
> Actual RX Freq after hopping: 936.400000 Mhz... at time: 1.50298 ->unexpected
>
> Actual RX Freq after hopping: 936.400000 Mhz... at time: 3.00306

Is the unexpected time supposed to be at 3 seconds?
How are you reading the time? Is it from the RX samples metadata
How are you measuring the frequency? Are you parsing RX samples, reading
a spectrum analyzer.

Another warning, done use get_rx_freq to readback the actual frequency,
because you are scheduling the tune for the future, this call cannot
accurately reflect the frequency at any given time, it just holds the
last frequency set.

-josh

> 
> usrp->set_time_now(uhd::time_spec_t(0.0));
> 
> MAList=[3, 7,33, 45, 80, 85, 94,103]
> 
> usrp->set_rx_freq(936.4e6); //setting beacon channel
> 
> 
>  while(i<8)
> 
> {
> 
>  int MAIO =(i%8);
> 
> arfcn=MAList[MAIO];
> 
> if(arfcn>=1 && arfcn<=124)
> 
> {
> 
>  hope_freq=(935+ .2*arfcn)*1e6 ;
> 
> }
> 
>  //hopping from cord
> 
>  uhd::tune_request_t tune_req(hope_freq); //retune USRP
> 
> tune_req.rf_freq_policy=uhd::tune_request_t::POLICY_NONE;
> 
> const uhd::time_spec_t tune_time = usrp->get_time_now() +
> uhd::time_spec_t(1.5);
> 
> 
>  usrp->set_command_time(tune_time);
> 
> tune_res = usrp->set_rx_freq(tune_req);
> 
> usrp->clear_command_time();
> 
>  while(usrp->get_time_now()<tune_time)
> 
> {
> 
> cout<<"do nothing and wait to prevent premature tuning"<<endl;
> 
> }
> 
> 
>  i++;
> 
> }
> 
> 
>  now my expectation when I run this program was, to get @ least 1.5 second
> time difference between successive tune requests, unfortunately the result
> shows some early tuning
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  Actual RX Freq after hopping: 935.600000 Mhz... at time: 1.50161
> 
> Actual RX Freq after hopping: 935.600000 Mhz... at time: 1.50222
> 
> Actual RX Freq after hopping: 935.600000 Mhz... at time: 1.50258
> 
> Actual RX Freq after hopping: 936.400000 Mhz... at time: 1.50298 ->unexpected
> 
> Actual RX Freq after hopping: 936.400000 Mhz... at time: 3.00306
> 
> Actual RX Freq after hopping: 936.400000 Mhz... at time: 3.00352
> 
> Actual RX Freq after hopping: 941.600000 Mhz... at time: 3.00409 ->unexpected
> 
> Actual RX Freq after hopping: 941.600000 Mhz... at time: 4.50418
> 
> Actual RX Freq after hopping: 941.600000 Mhz... at time: 4.50488
> 
> Actual RX Freq after hopping: 941.600000 Mhz... at time: 4.50526
> 
> Actual RX Freq after hopping: 944.000000 Mhz... at time: 6.00517
> 
> Actual RX Freq after hopping: 944.000000 Mhz... at time: 6.00578
> 
> Actual RX Freq after hopping: 944.000000 Mhz... at time: 6.00615
> 
> Actual RX Freq after hopping: 951.000000 Mhz... at time: 6.00655 ->unexpected
> 
> Actual RX Freq after hopping: 951.000000 Mhz... at time: 7.50661
> 
> Actual RX Freq after hopping: 951.000000 Mhz... at time: 7.5071
> 
> Actual RX Freq after hopping: 951.000000 Mhz... at time: 7.50769
> 
> Actual RX Freq after hopping: 952.000000 Mhz... at time: 9.00758
> 
> Actual RX Freq after hopping: 952.000000 Mhz... at time: 9.00821
> 
> Actual RX Freq after hopping: 952.000000 Mhz... at time: 9.00858
> 
> Actual RX Freq after hopping: 953.800000 Mhz... at time: 9.00897 ->unexpected
> 
> Actual RX Freq after hopping: 953.800000 Mhz... at time: 10.5088
> 
> Actual RX Freq after hopping: 953.800000 Mhz... at time: 10.5093
> 
> Actual RX Freq after hopping: 953.800000 Mhz... at time: 10.5097
> 
> Actual RX Freq after hopping: 953.800000 Mhz... at time: 10.5101
> 
> Actual RX Freq after hopping: 955.600000 Mhz... at time: 10.5105 ->unexpected
> 
> Actual RX Freq after hopping: 955.600000 Mhz... at time: 12.0105
> 
> Actual RX Freq after hopping: 955.600000 Mhz... at time: 12.011
> 
> 
> 
>  what do you think is the problem?
> 
> Please help me here cause in real-time hopping such kind of premature
> tuning result in synchronization problem with BTS
> 
> 
>  Thanks in advance!
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> 
> 
> 
> 
> 
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 




More information about the USRP-users mailing list