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" <patchvonbr...@gmail.com>
> >>
> >> 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
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
