[USRP-users] UBX coherence between TX and RX

2019-03-23 Thread Michael R. Freedman via USRP-users 

Hello,


I have an issue where I tune both the TX and RX side of a UBX40 card in 
an X310 to the same frequency and find that the transmitted signal and 
what is received are not coherent.  I am using an external 10MHz 
reference and have tried the documented suggestions.


at 150MHz it is coherent.

at 155MHz it is NOT coherent.


I have tried setting the dboard_clock_rate to 20MHz.  This made the 
problem appear at 150MHz as well.  I've tried integer_n tuning.


I have verified that the ref_lock and lo_lock are both true.


Any suggestions?


Mike


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] What makes sense and what doesn't in the way carrier frequency is set for TwinRX currently?

2019-03-23 Thread Nate Temple via USRP-users 
Hi Piotr,

A quick update -- we have root caused the issue and will have an update
that fixes it on the 3.14.0.0 release.

Regards,
Nate Temple

On Sat, Mar 23, 2019 at 8:14 AM Piotr Krysik via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> Update to the previous post. Nate Temple on IRC pointed that what I
> observe might be a result of a bug in recent UHD's, where co-channel
> phase difference on TwinRX doesn't behave as expected.
> Nate's advice was to go back to UHD 3.13, which I did (I took the top
> from UHD-3.13 branch).
>
> I did tests with original twinrx_usrp_source.py (where on
> UHD_3.15.0.git-13-g52138314 I had problem with phase changes).
> With UHD 3.13 I didn't need additional call to set_time_unknown_pps. The
> co-channel phase differences were constant from one program running to
> another without it.
>
> So it seems the strange behavior of phase in signal coming from TwinRXes
> might be a result of a bug that Nate was informing about.
>
> --
> Best Regards,
> Piotr Krysik
>
> W dniu 13.03.2019 o 14:48, Piotr Krysik via USRP-users pisze:
> > Hello everyone,
> >
> > TwinRXes requires special treatment when setting frequency in order to
> > keep co-channel phase differences across multiple executions of a
> > program communicating with USRP.
> >
> > What exactly 'treatment' I mean can be seen for example here:
> >
> https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L100
> >
> > or here:
> >
> >
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/apps/uhd_app.py#L298
> >
> >
> > The procedure is following (correct configuration of LO export and LO
> > sources is assumed):
> >
> > 1. set the frequency for the channel exporting LOs, and store result,
> > 2. set the frequency for the rest of the channels using the result saved
> > previously and POLICY_MANUAL for rf and dsp,
> > 3. set the frequency again for all channels with use of timed commands.
> >
> > In uhd_app's constructor there is also call to set_time_unknown_pps
> > between points 2 and 3. In twinrx_usrp_source.py set_time_unknown_pps is
> > called before point 1. The placement of this function call after the
> > first setting of the carrier frequency seems to be crucial. Without it
> > there are random 180 degree changes of phase differences between
> > channels from one run to another. And this issue can be observed for
> > twinrx_usrp_source.py, because it calls set_time_unknown_pps before
> > setting the frequency (checked on UHD_3.15.0.git-13-g52138314).
> >
> > I also changed different settings to see what effects they have. I
> > didn't notice any effect of POLICY_MANUAL setting in point 2. Setting
> > the frequency in regular way seems to work just as well. Also removing
> > point 3 completely (setting freq. with use of timed commands) seems to
> > not have any effect for TwinRX (I checked this with use of sine wave as
> > the input signal, in case it is important).
> >
> > In the end what I did was configuring LO export/sources in GNU Radio and
> > adding usrp.set_time_unknown_pps(..) at the end of the of the
> > constructor. As a result co-channel phase differences were (~) constant
> > across multiple runs.
> >
> >
> > My question:
> > 1. What is the rationale for all of the steps of frequency setting for
> > TwinRX? Did I have luck that most of them didn't have any effect for me?
> > 2. Why is the call to set_time_unknown_pps required at all? And why when
> > it is called after the first setting of carrier frequency in all
> > channels, it fixes the issue with 180 degree phase shifts from one run
> > to another? If it's called before, it doesn't seem to have this positive
> > effect.
> >
>
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] What makes sense and what doesn't in the way carrier frequency is set for TwinRX currently?

2019-03-23 Thread Piotr Krysik via USRP-users 
Hi all,

Update to the previous post. Nate Temple on IRC pointed that what I
observe might be a result of a bug in recent UHD's, where co-channel
phase difference on TwinRX doesn't behave as expected.
Nate's advice was to go back to UHD 3.13, which I did (I took the top
from UHD-3.13 branch).

I did tests with original twinrx_usrp_source.py (where on
UHD_3.15.0.git-13-g52138314 I had problem with phase changes).
With UHD 3.13 I didn't need additional call to set_time_unknown_pps. The
co-channel phase differences were constant from one program running to
another without it.

So it seems the strange behavior of phase in signal coming from TwinRXes
might be a result of a bug that Nate was informing about.

--
Best Regards,
Piotr Krysik

W dniu 13.03.2019 o 14:48, Piotr Krysik via USRP-users pisze:
> Hello everyone,
>
> TwinRXes requires special treatment when setting frequency in order to
> keep co-channel phase differences across multiple executions of a
> program communicating with USRP.
>
> What exactly 'treatment' I mean can be seen for example here:
> https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L100
>
> or here:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/apps/uhd_app.py#L298
>
>
> The procedure is following (correct configuration of LO export and LO
> sources is assumed):
>
> 1. set the frequency for the channel exporting LOs, and store result,
> 2. set the frequency for the rest of the channels using the result saved
> previously and POLICY_MANUAL for rf and dsp,
> 3. set the frequency again for all channels with use of timed commands.
>
> In uhd_app's constructor there is also call to set_time_unknown_pps
> between points 2 and 3. In twinrx_usrp_source.py set_time_unknown_pps is
> called before point 1. The placement of this function call after the
> first setting of the carrier frequency seems to be crucial. Without it
> there are random 180 degree changes of phase differences between
> channels from one run to another. And this issue can be observed for
> twinrx_usrp_source.py, because it calls set_time_unknown_pps before
> setting the frequency (checked on UHD_3.15.0.git-13-g52138314).
>
> I also changed different settings to see what effects they have. I
> didn't notice any effect of POLICY_MANUAL setting in point 2. Setting
> the frequency in regular way seems to work just as well. Also removing
> point 3 completely (setting freq. with use of timed commands) seems to
> not have any effect for TwinRX (I checked this with use of sine wave as
> the input signal, in case it is important).
>
> In the end what I did was configuring LO export/sources in GNU Radio and
> adding usrp.set_time_unknown_pps(..) at the end of the of the
> constructor. As a result co-channel phase differences were (~) constant
> across multiple runs.
>
>
> My question:
> 1. What is the rationale for all of the steps of frequency setting for
> TwinRX? Did I have luck that most of them didn't have any effect for me?
> 2. Why is the call to set_time_unknown_pps required at all? And why when
> it is called after the first setting of carrier frequency in all
> channels, it fixes the issue with 180 degree phase shifts from one run
> to another? If it's called before, it doesn't seem to have this positive
> effect.
>


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] API for N310

2019-03-23 Thread Janos Buttgereit via USRP-users 
Hi,

phase synchronous operation of the N310 should not really be a matter of the 
API you choose but a matter of your configuration (which you can achieve with 
all the APIs available). If you look at the posts I made to the mailing list in 
the last few days, you will find some information regarding that topic, along 
with a GNU Radio flow graph that delivers the desired results when the changes 
Marcus suggested are applied (setting the Sync option to Unknown PPS). Maybe 
GNURadio is a good starting point in this regard and after having made yourself 
familiar with the hardware you should just choose the API that suits your 
application best.

> Am 22.03.2019 um 18:00 schrieb Diogo Botelho Ribeiro Marinho via USRP-users 
> :
> 
> Hi,
> 
> I need to develop one application that grantee the same phase in 4 TX 
> channels on USRP N310. What API is recommended for this equipment? GNURadio, 
> labview, Matlab?
> 
> Thanks in advanced
> Diogo Marinho
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com 
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com 
> 

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] E320 SD Image lacking libraries; cross-compile help

2019-03-23 Thread Chris Gobbett via USRP-users 
We’ve just purchase a shiny new E320 or three and are looking to translate some 
gnuradio-generated python code from an E310 across, but I’m having problems 
which weren’t apparent during development for the E310.

Some differences which took me by surprise:
- The Python2.7 libraries are severely lacking; some of the standard libraries 
(e.g. decimal, numbers, runpy) aren’t present?!
- No gnuradio present at all? No binaries, nor the python 2.7 modules

I thought the lack of python2.7 modules may just be a side effect of Gnuradio 
heading towards Python 3, but given that UHD still defaults to Python 2.7 I’m 
wondering if I’ve missed something more obvious??
- Do I need to manually cross-compile and install Python2.7 in addition to 
installing gnuradio on the target? 
- Will rebuilding my GRC to use Python3 rather than Python2.7 solve my problems?

(longer background + steps taken...)

Over the last few days I’ve tried combinations of cross-compiling uhd and 
gnuradio, though given the reliance of my code on python2.7 this in turn leads 
to extra dependencies which aren’t there; e.g. uhd_swig is now after a newer 
libboost than what is on the card. I’ve tried copying the missing python2.7 
modules (above) from my e310 image as a stopgap measure, but while it works on 
the surface I think this is just adding more pain rather than helping.

The guides I used for the cross-compiling are included below. I’ve successfully 
built and run uhd and gnuradio by themselves on the E320 (e.g. 
gnuradio-config-info and uhd_usrp_probe run fine in isolation), but when it 
comes time to ‘from gnuradio import uhd’ is when the wheels fall off.

First guides were used to  build UHD on the host; to download the sdcard image, 
and to get the toolchain:
https://kb.ettus.com/E320_Getting_Started_Guide (Feb19)
http://files.ettus.com/manual/page_build_guide.html 

The steps regarding ldconfig linking the libraries on target aren’t included in 
the other guides; are they necessary? I’ve mainly followed these steps:
https://wiki.gnuradio.org/index.php/Cross_compile_an_OOT_and_install_on_target 
(Mar17)
https://wiki.gnuradio.org/index.php/Cross_compile_GNU_Radio_and_install_on_target
 (Mar17)
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
 (Sep17)

Short of building the code, this page doesn’t help much (e310-focussed):
https://files.ettus.com/manual/page_usrp_e3x0.html

Apologies for the large ramble... this has been several days coming, and I seem 
to be only going in circles... :(

Host running Ubuntu 18.04
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com