Thanks Marcus for the prompt response. Can you please help me with an example showing DSP tuning. I have gone through Piotr’s implementation, but was not able to understand how he was maintaining the time synchronization based on GNURadio work function.
Regards Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Marcus Müller via USRP-users<mailto:usrp-users@lists.ettus.com> Sent: 06 March 2021 23:00 To: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> Subject: Re: [USRP-users] Phase synchronization after hopping Hi Snehasish, you're not actually using timed commands, so there's no exact timing involved. Your usleep doesn't make much sense either, you shouldn't let your PC sleep while the analog chain tune, but instead already issue the next timed command. In this situation, I also would *not* tune the RF frontend *at all*, but only use DSP tuning (maybe you're doing that, no idea where your "rf_freq" and "dsp_freq" come from). Piotr Krysik solved your exact problem (X310, following GSM hopping) before. I remember the talk he held at an OsmoDevCon some years ago, maybe look for that. Best regards, Marcus On 06.03.21 17:31, Snehasish Kar via USRP-users wrote: > > Hello everyone > > > > I am trying to achieve frequency hopping in GSM using twinrx with usrp x310. > Here I am > using timed command for tuning a single port across a given frequency list. > During > hopping it stays in each frequency for 4msecs and till the time frequency > hopping > continues, I am able to identify FCCH using phase difference. But as soon as > the hopping > is over and it tunes back to the actual frequency containing the broadcast > channel, I am > not getting phase difference greater than 0 and thus not able to demodulate > the GSM > burst. Can anyone please help where I am going wrong below is the snippet of > the code, > responsible for hopping. > > > > Function handling hopping: > > > > uhd::tune_request_t tune_request(rf_freq); > > tune_request.rf_freq_policy = > uhd::tune_request_t::POLICY_MANUAL; > > tune_request.dsp_freq_policy = > uhd::tune_request_t::POLICY_MANUAL; > > tune_request.rf_freq = rf_freq; > > tune_request.dsp_freq = dsp_freq; > > uhd_src->set_rx_freq(tune_request, chan_num); > > { > > If(verbose_lvl==3){ > > char msg[100]={0x00}; > > sprintf(msg,"info: DSP freq: changed > to channel > %d: %fMHz offset %fMHz", chan_num, uhd_src->get_rx_freq(chan_num)/1e6, > dsp_freq); > > vipl_printf(msg,error_lvl, __FILE__, > __LINE__); > > } > > } > > //uhd_src->clear_command_time(); > > usleep(110000); // allow LOs to lock > > > > > > > > Module for setting back to original frequency with broadcast: > > > > uhd_src->clear_command_time(); > > uhd::tune_request_t tune_request(rf_freq, 0x00); //considering > LO-Offset > to be zero > > tune_request.rf_freq_policy = uhd::tune_request_t::POLICY_AUTO; > > tune_request.dsp_freq_policy = uhd::tune_request_t::POLICY_AUTO; > > tune_request.rf_freq = rf_freq; > > //tune_request.dsp_freq = -dsp_freq; > > uhd_src->set_rx_freq(tune_request, channel); > > { > > char msg[100]={0x00}; > > sprintf(msg,"info: freq: set to channel %d: %fMHz > requested > freq %fMHz", channel, uhd_src->get_rx_freq(channel)/1e6, rf_freq/1e6); > > vipl_printf(msg,error_lvl, __FILE__, __LINE__); > > } > > usleep(110000); > > > > My UHD version is 3.14.0.0 > > USRP: X310 > > Daughter board: 2 sets of Twinrx > > OS: Debian 10 > > Interface: 10gig sfp+ ethernet > > > > Thanks!! > > > > > > Regards > > Snehasish Kar > > > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com _______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
