Hi Marcus,
Gesendet: Montag, 09. Dezember 2019 um 15:58 Uhr
On 12/09/2019 03:35 PM, Lukas Haase wrote:
Hi Marcus,
Von: "Marcus D. Leech" <[email protected]>
On 12/09/2019 03:11 PM, Lukas Haase wrote:
No, I only have one RX channel at the moment.
--> One TX @ f and one RX @ 2f.
The phase relation between this TX+RX should stay constant/coherent once both
TX+RX tune to a different f and back.
Let me know if the setup is clear, otherwise I'll try to draw a block
diagram/equations or I can also send the GRC screenshots.
Thanks,
Luke
You code shows two RX channels:
now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 0)
self.uhd_usrp_source_0.set_center_freq(2*self.fcenter, 1)
self.uhd_usrp_sink_0.set_center_freq(self.fcenter, 0)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
Sorry for the confusion.
You are right, there are 2 RX channels but I only use one of them.
So, you're measuring the phase-offset between the TX side and the RX
side at the 2nd harmonic, and expecting that phase relationship to be
the same across re-tunes?
Yes, this is exactly what I want.
I'm not sure that's possible.
Why not?
Conceptually it must be possible: The phase offset is only defined by the
*relative* phase between RX/TX-LO.
Let's assume that both RX + TX mixer are driven by the *same* LO but the RX
side has an additional frequency doubler.
Then the phase relationship is ALWAYS constant. By construction.
But, that's not the situation we find ourselves in with the hardware
(including FPGA) in front of us.
The USRP just makes things complicated because RX and TX are driven by
different PLLs and allow their LO to be retuned separately. But ultimately both
PLLs are driven by the same reference (to which phase they lock) so there must
be a way to have a constant phase relationship.
Did you look at the reference I posted about Fractional-N vs Integer-N
synthesis? They behave very differently in this regard--the "phase reset"
feature helps, but in this case, the UBX was never designed to
maintain constant phase offsets between RX/TX (because this is a very very
unusual case), PARTICULARLY ACROSS RETUNES.
Yes, I reviewed it. Thanks for the reference, I did not know this about
fractional-N PLLs.
Do you know by any chance if the phase reset feature is implemented by the USRP
or not (initially you suggest it has, above you suggest it may not).
Quite apart from what the PLL synthesizers are doing, there's the
DDC/DUC within the FPGA, and they are driven by what amounts to a
digital oscillator, and THOSE digital oscillators aren't shared,
either. Sharing phase constancy across TX/RX was never a design goal
of the hardware.
That makes sense too. I am still wondering why phase constancy betwene TX/RX would be
such a "weird" goal.
Yes, in many cases this phase rotation is readily divided out but in particular
for fast frequency hopping systems it becomes hard. Or for phase based ranging
systems. I mean, they exist, right?
I see that the DDC/DUC are not shared. At least in principle it should be easy
to synchronize them ... the beauty of a digital system (their digital clocks
are shared).
While I have worked with such systems in the past I am unfortunately new to
gnuradio and USRP. Gnuradio is a steep learning curve on its own, these small
details add significantly to my confusion.
Now, having said all that, it may be the case that there are specific
configurations in which this can be made to work, and I'm in discussions
with R&D about that. Details like what the management policy is for
the phase-accumulators in the DDC/DUC digital oscillators matters,
along with hardware details like whether the RX and TX synthesizers
shared a control bus or whether it's in parallel really matter, for example.
Any possible help is greatly appreciated!
Something that MAY help here is to use integer_n tuning:
treq=uhd.tune_request(my_frequency)
treq.args=uhd.device_addr("mode_n=integer")
...
...set_center_freq(treq, 0)
I translated this to gnuradio:
def set_fcenter(self, fcenter):
self.fcenter = fcenter
tune_resp_tx = self.uhd_usrp_sink_0.set_center_freq(fcenter, 0)
tune_resp_rx = self.uhd_usrp_source_0.set_center_freq(2*fcenter, 0)
tune_req_tx = uhd.tune_request(rf_freq=fcenter,
rf_freq_policy=uhd.tune_request.POLICY_MANUAL,
dsp_freq=tune_resp_tx.actual_dsp_freq,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
tune_req_rx = uhd.tune_request(rf_freq=2*fcenter,
rf_freq_policy=uhd.tune_request.POLICY_MANUAL,
dsp_freq=tune_resp_rx.actual_dsp_freq,
dsp_freq_policy=uhd.tune_request.POLICY_MANUAL)
tune_req_tx.args = uhd.device_addr("mode_n=integer")
tune_req_rx.args = uhd.device_addr("mode_n=integer")
now = self.uhd_usrp_sink_0.get_time_now()
self.uhd_usrp_sink_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_source_0.set_command_time(now + uhd.time_spec(1))
self.uhd_usrp_sink_0.set_center_freq(tune_req_tx, 0)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 0)
self.uhd_usrp_source_0.set_center_freq(tune_req_rx, 1)
self.uhd_usrp_source_0.clear_command_time()
self.uhd_usrp_sink_0.clear_command_time()
Unfortunately with these lines I loose the frequency altogether when retuning
(without changing tune_req_tx.args/tune_req_rx.args things work): What I mean,
I receive noise only. I do not physically have access to my testbench at the
moment to verify where the frequency is tuned to, I just know that instead of
receiving my signal I only receive noise.
Thanks,
Luke
