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.
On Tue, Feb 27, 2018 at 3:08 PM, Андрей 1 via USRP-users <
> In the previous post(twinrx_freq_hopping example
> 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
> Can someone explain to me why this can happen?
> Thank you
> USRP-users mailing list
USRP-users mailing list