Hello Oğuzhan,
so, what radios are these?
Generally, this *very* much sounds like you need to use timed commands, which trigger the
tuning at a specific sample time, instead of "yeah, whenever the connection between PC and
the USRP has delivered the command".
You can send these commands to the "command" message port on the USRP Sink[1]; the set of
things you can set (depending on the actual hardware model) are documented in [2]. Note
that you'll want to sent in a PMT dictionary. Such a dictionary can nicely be created
using the pmt.pmt_to_python.python_to_pmt function, e.g.
command_dictionary = pmt.pmt_to_python.python_to_pmt(
{ "time": (full_seconds, fractional_seconds),
"tune": (target_frequency, dsp_offset) })
Also note that especially if you're doing this tuning within a range smaller than your
USRP's master clock rate, you can use DSP-only tuning, and achieve "instant" tuning at the
specified time stamp.
Note that the time the USRP gets initialized is "0" from the device's perspective. You can
see the current time of the device in the rx_time tags on the USRP Source's stream.
Best regards,
Marcus
[1] https://wiki.gnuradio.org/index.php?title=USRP_Sink
[2] https://www.gnuradio.org/doc/doxygen/page_uhd.html#uhd_command_syntax_cmds
On 04.01.24 15:43, Oğuzhan Gedikli wrote:
Hello,
I have a system I set up with 2 different SDRs. One of the SDRs works as a transmitter and
the other works as a receiver. When I want to change the center frequency of both of them,
I use the code below.
usrp_sink.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset,
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)
usrp_source.set_center_freq(uhd.tune_request(freq, rf_freq=freq - lo_offset,
rf_freq_policy=uhd.tune_request.POLICY_MANUAL), 0)
I measured how long each one took. One of them (of course, I know it changes depending on
the hopping frequency. I applied all the tests I mentioned at the same frequencies) takes
180ms, and the other one takes 50ms.
50ms is of great importance to me because it repeats this process thousands of times
during a measurement. For this reason, I wanted to run the 2 lines of code you see in
parallel and I noticed that there was no change in the time. I tested the code I wrote to
parallelize it; the code works. It starts both functions at the same time. Later, when I
debugged the parts containing 'set_center_freq', I saw that the 'wait' command took up
most of the time spent. I have not examined the contents of your library. I'm saying what
I see on the debug screen. I did not write any 'wait' command myself. But I don't
understand why one SDR keeps threading and prevents applying commands to the other.
footnote: There is no situation due to GIL. I tested this too.
