Hello, Setting the LO source does not tune the synthesizers so the actual command duration should be very short. How are you measuring the durations?
I looked at why the twinrx_freq_hopping demo is not built by default on Windows and it is because of an optional feature which requires a library which Windows does not include, Curses. By removing the ascii_art_dft.hpp include and the write_fft_to_file function the example should compile and run with no other changes on Windows. Doing this would be a good test as it would help isolate if there is a performance issue or an issue with how the API is being used in your current test program. The example is very carefully constructed so that there are minimal delays and so commands are already queued on the FPGA before their scheduled execution time. If you have a custom C program could you share the code? It would be useful to see the order of operations. Regards, Derek On Tue, Feb 27, 2018 at 3:08 PM, Андрей 1 via USRP-users < usrp-users@lists.ettus.com> wrote: > > Hello > > <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-February/027782.html> > > In the previous post(twinrx_freq_hopping example > <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-February/027782.html>), > I wrote that I could not get time in 5 ms for example twinrx_freq_hopping. > I measure the commands execute time in the recieve loop and found with > surprise that the set_rx_lo_source function for the first time worked 0 ms > and the next time more than 40 ms. > It is because of this that a large tuning time in the frequency range is > obtained. > Can someone explain to me why this can happen? > > > Thank you > > > _______________________________________________ > 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
