[USRP-users] Mechanism to determine phase offset of two nearly equal pieces of coax

Derek Kozel derek.kozel at ettus.com
Wed Jul 5 10:41:14 EDT 2017


As an extension to Marcus' answer, there is no built in support for timed
tuning in the USRP blocks, but we do include an example which shows tuning
using messages and the control port.
https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/examples/grc/uhd_msg_tune.grc

It is also possible to write a custom block to generate command messages.
This can be done using the embedded python block within GRC.

Regards,
Derek

On Wed, Jul 5, 2017 at 2:58 PM, Marcus D. Leech via USRP-users <
usrp-users at lists.ettus.com> wrote:

> On 07/05/2017 04:35 AM, John Shields via USRP-users wrote:
>
> I have a couple of N200 with a MIMO cable (and one has a GPSDO but I don’t
> think I need to worry about that for this setup) and propose feeding both
> cables to RX port on an SBX in each N200. The other end of the coax will be
> connected to a splitter and the ‘sum’ port will be connected to TX port on
> SBX (of which only the TX portion works) on a USRP1 through 30dB attenuator.
>
> The phase imbalance spec of this splitter is less than 1 degree but if I
> wanted, I could calibrate that out and I could live with it anyway.
>
> In order for this setup to allow me to determine the relative phase offset
> ( whose length can be calculated from the Velocity Factor of the RG 213) I
> need to start up the SBXs on the N200 with zero differential phase offset.
>
> I have seen the section for SBX where I need to execute :
>
> //we will tune the frontends in 100ms from now
> uhd::time_spec_t cmd_time = usrp->get_time_now() + uhd::time_spec_t(0.1);
> //sets command time on all devices
> //the next commands are all timed
> usrp->set_command_time(cmd_time);
> //tune channel 0 and channel 1
> usrp->set_rx_freq(1.03e9, 0); // Channel 0
> usrp->set_rx_freq(1.03e9, 1); // Channel 1
> //end timed commands
> usrp->clear_command_time();
>
> So three questions:
> 1) am I missing something obvious?
>
> 2) is there a clever way in GRC to cause this code to be executed – rather
> than in a .py file?
>
> 3) what is the most effective phase comparator to use? I expect to use 400
> Mhz to start with to minimise the chance of nx2*pi ambiguity.
>
>            Kind Regards,
>
>                      John
>
>
>
>
> So, in GRC you'd have to select "Unknown PPS" in the SYNC field, and
> select MIMO for the clock and time sources for one of the devices.
>
> Once that is done, you'll have to edit the generated code and wrap the
> timed-commands around the tuning commands emitted by GRC--there is
>   currently no support for timed tuning in GRC itself.
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170705/fccc4462/attachment-0002.html>


More information about the USRP-users mailing list