[USRP-users] b205mini and gpsdo

[carry chen via USRP-users]

hi list，

I plan to buy a gps module ，the gps module have 1pps pin and uart pin. I will 
connect the 1pps pin to b205mini “REF” sma port to Disciplin The local clock. 
And connect uart pin to gpio to read time info.
That is ok?

Thanks!

Best Regards,
Charlies

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

Re: [USRP-users] UHD 3.14.0.0 Late Packet Anomalies (N310)

[Ali Dormiani via USRP-users]

Never-mind. I found the issue.

I forgot to set the 'PC Clock' setting in the sink block. We are back to
perfect packet delivery on low sample rates and near perfect packet
delivery on high sampling rates.

On Wed, Apr 3, 2019 at 3:07 PM Freedman, Michael - 1008 - MITLL <
mfreed...@ll.mit.edu> wrote:

> I’ve seen a similar lessening of performance with 3.14.
>
> Mike
>
> Sent from my iPhone
>
> On Apr 3, 2019, at 5:56 PM, Ali Dormiani via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hello everyone,
>
> I recently upgraded two of our N310's and our host server from 3.13.1.0 to
> 3.14.0.0.
>
> UHD, GNU Radio (host), FPGA, SDIMG, were all uninstalled, compiled again,
> and updated/flashed/imaged appropriately.
>
> Additionally, nothing in our set up has changed other than the version of
> UHD. (same kernel, distro, networking gear, IP configuration, cables, and
> so on).
>
> I am getting strange results when running a simple flow-graph that sends
> out a sine (sampled at 1.25M) from one N310 and uses the second N310 as a
> receiver. It appears that all of the packets are late.
>
> My terminal is just a wall of 'L'. This leads to a hard lock up that
> forces me to kill GNU Radio and power cycle both N310's.
>
> Any help with this late packet problem would be greatly appreciated. With
> UHD 3.13.1.0, we could run complex flow-graphs at much higher sample rates
> with only an occasional dropped packet. Zero late packets.
>
> Thanks,
>
> Ali
> ___
> 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] UHD 3.14.0.0 Late Packet Anomalies (N310)

[Ali Dormiani via USRP-users]

Hello everyone,

I recently upgraded two of our N310's and our host server from 3.13.1.0 to
3.14.0.0.

UHD, GNU Radio (host), FPGA, SDIMG, were all uninstalled, compiled again,
and updated/flashed/imaged appropriately.

Additionally, nothing in our set up has changed other than the version of
UHD. (same kernel, distro, networking gear, IP configuration, cables, and
so on).

I am getting strange results when running a simple flow-graph that sends
out a sine (sampled at 1.25M) from one N310 and uses the second N310 as a
receiver. It appears that all of the packets are late.

My terminal is just a wall of 'L'. This leads to a hard lock up that forces
me to kill GNU Radio and power cycle both N310's.

Any help with this late packet problem would be greatly appreciated. With
UHD 3.13.1.0, we could run complex flow-graphs at much higher sample rates
with only an occasional dropped packet. Zero late packets.

Thanks,

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

[USRP-users] What is the best way to trigger rfnoc receiver radio?

[Xingjian Chen via USRP-users]

Dear all,
I have some questions about how to trigger RFNOC receiver. I have a module 
detecting the rising edge of a fixed clock. I used that clock to trigger Tx and 
Rx modules. Now the transmit RFNOC module is working properly but the receive 
module gives me non-deterministic m_axis_data_tvalid such that I cannot 
determine when the Rx radio started recording. I am wondering if anyone know 
how to use a clock or any trigger to let RFNOC Rx radio starting to record 
signal? The USRP I am using now is E312. Thank you!

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

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Piotr Krysik via USRP-users]

Hi,

After disconnecting LO cables signal on the daughter-board that imports
LOs disappears. So GNU Radio correctly configures distribution of LOs.
Also the +/- 90 degree changes happen completely deterministically in
given ranges of carrier frequencies.

So the question remains open: what is causing the issue described in the
first post of this thread?

--
Best Regards,
Piotr Krysik

W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
> Hi,
>
> yes, the result for multiple measurements (start ups of the system) at
> a single frequency was different by multiples of 90°.
> We did not investigated the problem any further, but I am quite sure
> that gnuradio was not synchronizing the channels using the LO-sharing,
> although it was selected. So do the test I described. If you see that
> he is not using the LO-sharing, you know where to look further.
> Keep in mind that it is not necessary to use LO-sharing to get a well
> defined phase relation between the channels. Depending on your
> frequency and bandwidth settings, it is possible to also achive this,
> as all LOs are driven from a common 200 MHz reference clock.
>
> Best regards,
> Fabian
>
> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>> Hi Fabian,
>>
>> W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
>>> Hi Piotr,
>>>
>>> we once had a very similar issue. But we also saw this on the same
>>> frequency when switching between frequencies. Can you try this as
>>> well? Just switch forth and back between two frequencies and just plot
>>> one of them?
>>
>> I'm not sure I understand correctly what you mean. You mean that the
>> result for a given frequency was not stable in your case across many
>> measurements? In our case this situation was repeating, but the
>> application doing the recording was restarted for each measurement.
>>
>>> As far as I remember the issue was because we were not using the
>>> LO-Sharing. We were able to get everything running by using a C++
>>> application and not gnuradio (I can see you are using python - which
>>> is basically the same). There was a bug in gnuradio/python causing
>>> this issue.
>>> You can try to remove one of the LO-sharing cables while doing a
>>> measurement and see if the phase suddenly starts to do crazy things
>>> (the signal should also be lost). If that is not the case, you are not
>>> actually using LO-sharing.
>>>
>> Do you know what this bug was exactly? GNU Radio didn't configure
>> LO-Sharing the way it was specified?
>>
>> -- 
>> Best Regards,
>> Piotr Krysik
>>
>>

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

[USRP-users] E310 environment

[Martin K via USRP-users]

I am trying to follow the instructions at
https://files.ettus.com/manual/page_usrp_e3x0.html

I have a fresh installation of Ubuntu (either 16.04 or 18.04)

When I get to the point of setting up the cross compilation
environment, I get a fatal error. This is some sort of Python issue,
for which I am not a Python developer, I have no idea what I should be
doing to fix this.

My goal is to compile my custom C++ code against UHD for the E310. If
there is a better solution please let me know. Thank you.

$ . e3xx/environment-setup-armv7ahf-vfp-neon-oe-linux-gnueabi
$ CC
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

Current thread 0x7f05861ce740 (most recent call first):
Aborted (core dumped)

-- 
Martin K.

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

Re: [USRP-users] not getting phase coherence between channels

[Marcus D. Leech via USRP-users]

On 04/03/2019 05:55 AM, Koyel Das (Vehere) wrote:


Hi Marcus,


Thank you very much for your reply. I have few doubts. Please clarify:


In the link that you sent there are total 8 sma ports for A slot and B 
slot



  LO Sharing with Neighbour TwinRXs

TwinRX (A Slot) TwinRX (B Slot)
J1 LO2 Export   J2 LO2 Input
J2 LO2 InputJ1 LO2 Export
J3 LO1 Export   J4 LO1 Input
J4 LO1 InputJ3 LO1 Export

But in USRP 2955R only 4 ports are exposed out, so the configuration 
what is given in your link is totally different than what is available 
in the back side of 2955 R. Do you mean to open up the box and then 
the 8 ports will be visible?


We are using following commands on the software side:



usrp->set_rx_lo_freq(frequncy+(sampleRate/2),"LO1",2);
std::coutset_rx_lo_source("internal",usrp->ALL_LOS,2);
usrp->set_rx_lo_export_enabled(true,usrp->ALL_LOS,2);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",3);
usrp->set_rx_lo_source("companion",usrp->ALL_LOS,3);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",0);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,0);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",1);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,1);


Also you mentioned using "set_time_unknown_pps()" command so is this 
command along with the above commands enough in the software side or 
some more commands are there for LO sharing? If so what are those?





That *should* be enough.

I'm going to recommend that you look at this document, and the related code:

https://kb.ettus.com/Direction_Finding_with_the_USRP%E2%84%A2_X-Series_and_TwinRX%E2%84%A2

Which uses TwinRx with LO sharing in a coherent receiver setup.


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

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Fabian Schwartau via USRP-users]

Hi,
I don't know what this patch does, but there is not software required 
under certain circumstances. The reference clock is 200 MHz and there 
are a few PLLs which are used to generate your LOs. When the PLLs run in 
interger-N mode (which can be defined in the API, when explicitly 
setting the frequencies), and they do not divide the clock, all LOs will 
have the same phase. So in multiples of 200 MHz this should be the case. 
For multiples of 50 MHz you will get 90° random phase jumps after the 
PLLs are locked again.


Best regards,
Fabian

Am 03.04.2019 um 12:36 schrieb Piotr Krysik via USRP-users:

To answer my own question:
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L226

it seems the answer is yes.

--
Piotr Krysik
W dniu 03.04.2019 o 12:34, Piotr Krysik via USRP-users pisze:

Hi,

W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:

(...)
Keep in mind that it is not necessary to use LO-sharing to get a well
defined phase relation between the channels. Depending on your
frequency and bandwidth settings, it is possible to also achive this,
as all LOs are driven from a common 200 MHz reference clock.


Do you mean TwinRXes might have similar initial phase reset capability
that UBXes and SBXes have?

--
Best Regards,
Piotr Krysik



Best regards,
Fabian

Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:

Hi Fabian,

W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:

Hi Piotr,

we once had a very similar issue. But we also saw this on the same
frequency when switching between frequencies. Can you try this as
well? Just switch forth and back between two frequencies and just plot
one of them?

I'm not sure I understand correctly what you mean. You mean that the
result for a given frequency was not stable in your case across many
measurements? In our case this situation was repeating, but the
application doing the recording was restarted for each measurement.


As far as I remember the issue was because we were not using the
LO-Sharing. We were able to get everything running by using a C++
application and not gnuradio (I can see you are using python - which
is basically the same). There was a bug in gnuradio/python causing
this issue.
You can try to remove one of the LO-sharing cables while doing a
measurement and see if the phase suddenly starts to do crazy things
(the signal should also be lost). If that is not the case, you are not
actually using LO-sharing.


Do you know what this bug was exactly? GNU Radio didn't configure
LO-Sharing the way it was specified?

--
Best Regards,
Piotr Krysik



___
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] Burst detection, DRAM buffering and streaming to PC

[Emil Bjelski via USRP-users]

Hello everyone,

I am implementing the system on USRP X310  where the maximum sampling rate
needs to be used on both Rx channels, so in total ( 2 (IQ) x 2 (RF cards) x
200 MSPs).
After doing tests of throughput between USRP and PC, I experience that
there will be bottleneck related to writing samples in memory of PC (I am
using SSD).
This is also confirmed by numerous previous post on the usrp mailing list.

Before I describe what is my question and idea, I will shortly describe
system requirements.
My system needs to sample data periodically as I am sending bursts of data
from time to time.
One burst sent from Tx can have a duration of 6-10ms, then there is a gap
of 10 ms, after which I am again sending a burst of data (signal).
So in short, I would have at maximum 10 ms of data then gap of 10ms (or
more if needed) sampled at highest X310 sampling rate 800MSPs.

My idea is to develop RFNoC CE for burst detection (the burst contains
preamble with good correlation properties).
This RFNoC CE would indicate when there are valuable samples available for
streaming to PC.
Therefore, my idea would be to stream only samples that correspond to a
valuable signal to PC.
In the worst case, I would have ~16MB of data to transfer every 10ms (this
would result in throughput of ~1.6GB/s).

Saving 16MB of data in BRAM might not be a good approach.
Therefore I would like to save 16MB in DRAM (DDR3) memory, and from DDR3
Stream data to PC.
However, after reading several posts on the mailing list I am confused if
there are already available block which
could support me in the development of DRAM FIFO controlled by the burst
detector.
I am aware of RFNoC reply functionality for Tx side, however, I am not
aware if there is an example where samples are
streamed from DRAM to PC.

Summarizing my goal in the logical diagram:

|Radio Block| > |Burst Detector|
   ||
   | YES/NO |
   /<--
   |->|DRAM
FIFO|--->|PCIe|

My questions would:
1. What is the maximum writing speed to DRAM on X310?
2. Are they already available RFNoC block which would support the
development of controlled DRAM FIFO?
3. In general, if you have any useful comments, guidelines please let me
know.

Thanks a lot,

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

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Piotr Krysik via USRP-users]

To answer my own question:
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L226

it seems the answer is yes.

--
Piotr Krysik
W dniu 03.04.2019 o 12:34, Piotr Krysik via USRP-users pisze:
> Hi,
>
> W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
>> (...)
>> Keep in mind that it is not necessary to use LO-sharing to get a well
>> defined phase relation between the channels. Depending on your
>> frequency and bandwidth settings, it is possible to also achive this,
>> as all LOs are driven from a common 200 MHz reference clock.
>>
> Do you mean TwinRXes might have similar initial phase reset capability
> that UBXes and SBXes have?
>
> --
> Best Regards,
> Piotr Krysik
>
>
>> Best regards,
>> Fabian
>>
>> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>>> Hi Fabian,
>>>
>>> W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
 Hi Piotr,

 we once had a very similar issue. But we also saw this on the same
 frequency when switching between frequencies. Can you try this as
 well? Just switch forth and back between two frequencies and just plot
 one of them?
>>> I'm not sure I understand correctly what you mean. You mean that the
>>> result for a given frequency was not stable in your case across many
>>> measurements? In our case this situation was repeating, but the
>>> application doing the recording was restarted for each measurement.
>>>
 As far as I remember the issue was because we were not using the
 LO-Sharing. We were able to get everything running by using a C++
 application and not gnuradio (I can see you are using python - which
 is basically the same). There was a bug in gnuradio/python causing
 this issue.
 You can try to remove one of the LO-sharing cables while doing a
 measurement and see if the phase suddenly starts to do crazy things
 (the signal should also be lost). If that is not the case, you are not
 actually using LO-sharing.

>>> Do you know what this bug was exactly? GNU Radio didn't configure
>>> LO-Sharing the way it was specified?
>>>
>>> -- 
>>> Best Regards,
>>> Piotr Krysik


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

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Piotr Krysik via USRP-users]

Hi,

W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
> (...)
> Keep in mind that it is not necessary to use LO-sharing to get a well
> defined phase relation between the channels. Depending on your
> frequency and bandwidth settings, it is possible to also achive this,
> as all LOs are driven from a common 200 MHz reference clock.
>
Do you mean TwinRXes might have similar initial phase reset capability
that UBXes and SBXes have?

--
Best Regards,
Piotr Krysik


> Best regards,
> Fabian
>
> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>> Hi Fabian,
>>
>> W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
>>> Hi Piotr,
>>>
>>> we once had a very similar issue. But we also saw this on the same
>>> frequency when switching between frequencies. Can you try this as
>>> well? Just switch forth and back between two frequencies and just plot
>>> one of them?
>>
>> I'm not sure I understand correctly what you mean. You mean that the
>> result for a given frequency was not stable in your case across many
>> measurements? In our case this situation was repeating, but the
>> application doing the recording was restarted for each measurement.
>>
>>> As far as I remember the issue was because we were not using the
>>> LO-Sharing. We were able to get everything running by using a C++
>>> application and not gnuradio (I can see you are using python - which
>>> is basically the same). There was a bug in gnuradio/python causing
>>> this issue.
>>> You can try to remove one of the LO-sharing cables while doing a
>>> measurement and see if the phase suddenly starts to do crazy things
>>> (the signal should also be lost). If that is not the case, you are not
>>> actually using LO-sharing.
>>>
>> Do you know what this bug was exactly? GNU Radio didn't configure
>> LO-Sharing the way it was specified?
>>
>> -- 
>> Best Regards,
>> Piotr Krysik


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

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Fabian Schwartau via USRP-users]

Hi,

yes, the result for multiple measurements (start ups of the system) at a 
single frequency was different by multiples of 90°.
We did not investigated the problem any further, but I am quite sure 
that gnuradio was not synchronizing the channels using the LO-sharing, 
although it was selected. So do the test I described. If you see that he 
is not using the LO-sharing, you know where to look further.
Keep in mind that it is not necessary to use LO-sharing to get a well 
defined phase relation between the channels. Depending on your frequency 
and bandwidth settings, it is possible to also achive this, as all LOs 
are driven from a common 200 MHz reference clock.


Best regards,
Fabian

Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:

Hi Fabian,

W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:

Hi Piotr,

we once had a very similar issue. But we also saw this on the same
frequency when switching between frequencies. Can you try this as
well? Just switch forth and back between two frequencies and just plot
one of them?


I'm not sure I understand correctly what you mean. You mean that the
result for a given frequency was not stable in your case across many
measurements? In our case this situation was repeating, but the
application doing the recording was restarted for each measurement.


As far as I remember the issue was because we were not using the
LO-Sharing. We were able to get everything running by using a C++
application and not gnuradio (I can see you are using python - which
is basically the same). There was a bug in gnuradio/python causing
this issue.
You can try to remove one of the LO-sharing cables while doing a
measurement and see if the phase suddenly starts to do crazy things
(the signal should also be lost). If that is not the case, you are not
actually using LO-sharing.


Do you know what this bug was exactly? GNU Radio didn't configure
LO-Sharing the way it was specified?

--
Best Regards,
Piotr Krysik


___
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] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Piotr Krysik via USRP-users]

Hi Fabian,

W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
> Hi Piotr,
>
> we once had a very similar issue. But we also saw this on the same
> frequency when switching between frequencies. Can you try this as
> well? Just switch forth and back between two frequencies and just plot
> one of them?

I'm not sure I understand correctly what you mean. You mean that the
result for a given frequency was not stable in your case across many
measurements? In our case this situation was repeating, but the
application doing the recording was restarted for each measurement.

> As far as I remember the issue was because we were not using the
> LO-Sharing. We were able to get everything running by using a C++
> application and not gnuradio (I can see you are using python - which
> is basically the same). There was a bug in gnuradio/python causing
> this issue.
> You can try to remove one of the LO-sharing cables while doing a
> measurement and see if the phase suddenly starts to do crazy things
> (the signal should also be lost). If that is not the case, you are not
> actually using LO-sharing.
>
Do you know what this bug was exactly? GNU Radio didn't configure
LO-Sharing the way it was specified?

--
Best Regards,
Piotr Krysik


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

Re: [USRP-users] not getting phase coherence between channels

[Koyel Das (Vehere) via USRP-users]

Hi Marcus,


Thank you very much for your reply. I have few doubts. Please clarify:


In the link that you sent there are total 8 sma ports for A slot and B slot

LO Sharing with Neighbour TwinRXs
TwinRX (A Slot) TwinRX (B Slot)
J1 LO2 Export   J2 LO2 Input
J2 LO2 InputJ1 LO2 Export
J3 LO1 Export   J4 LO1 Input
J4 LO1 InputJ3 LO1 Export


But in USRP 2955R only 4 ports are exposed out, so the configuration what is 
given in your link is totally different than what is available in the back side 
of 2955 R. Do you mean to open up the box and then the 8 ports will be visible?

We are using following commands on the software side:


usrp->set_rx_lo_freq(frequncy+(sampleRate/2),"LO1",2);
std::coutset_rx_lo_source("internal",usrp->ALL_LOS,2);
usrp->set_rx_lo_export_enabled(true,usrp->ALL_LOS,2);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",3);
usrp->set_rx_lo_source("companion",usrp->ALL_LOS,3);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",0);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,0);

usrp->set_rx_lo_freq(usrp->get_rx_lo_freq("LO1",2),"LO1",1);
usrp->set_rx_lo_source("external",usrp->ALL_LOS,1);

Also you mentioned using "set_time_unknown_pps()" command so is this command 
along with the above commands enough in the software side or some more commands 
are there for LO sharing? If so what are those?


Regards,

Koyel Das
Senior – Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence
M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
www.vehere.com

[unnamed] [unnamed 
(1)]   [unnamed (2)] 


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!

The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company accepts no liability 
for any damage caused by any virus transmitted by this email.



From: USRP-users  on behalf of Marcus D. 
Leech via USRP-users 
Sent: Tuesday, April 2, 2019 7:07 PM
To: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] not getting phase coherence between channels

On 04/02/2019 01:34 AM, Koyel Das (Vehere) via USRP-users wrote:

Hi,


I am using the given code for data receiving from two channels. I need to do LO 
sharing for phase coherent application, which is done as shown in the code and 
externally as shown in the image attached but I am not getting constant phase 
difference.


We have connected one antenna to input of a power splitter and then connected 
two output ports of the splitter to two ports of USRP. We are receiving signals 
(say noise) from these two ports of USRP. We are dividing the whole chunk 
(5*10^6 samples) of data into 5000 chunks each having 1000 continuous samples. 
Then we are doing FFT of each of the chunk of 1000 samples and multiplying the 
results from the two channels. Then averaging 1000 chunks of the multiplication 
(cross-power) together so we are left with 5 averaged chunks each of 1000 
samples of cross-power.  The phase of the cross power is omega(td1-td2), where 
omega is 2*pi*frequency and td1 is the time delay of channel1, td2:time delay 
of channel2. so omega(td1-td2) is the phase difference. Since we are doing 
averaging the noise effect should reduce to 0 and we should get phase 
difference due to time delays due to internal circuitry. Now since frequencies 
are in the range of 2.4*10^9 to 2.401*10^9 for 1 MHz bandwidth and td1-td2 is 
also expected to be very small so omega(td1-td2) for this frequency range would 
be almost identical, which is not happening.


In short I am not getting constant phase 

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Fabian Schwartau via USRP-users]

Hi Piotr,

we once had a very similar issue. But we also saw this on the same 
frequency when switching between frequencies. Can you try this as well? 
Just switch forth and back between two frequencies and just plot one of 
them?
As far as I remember the issue was because we were not using the 
LO-Sharing. We were able to get everything running by using a C++ 
application and not gnuradio (I can see you are using python - which is 
basically the same). There was a bug in gnuradio/python causing this issue.
You can try to remove one of the LO-sharing cables while doing a 
measurement and see if the phase suddenly starts to do crazy things (the 
signal should also be lost). If that is not the case, you are not 
actually using LO-sharing.


Best regards,
Fabian


Am 03.04.2019 um 10:40 schrieb Piotr Krysik via USRP-users:

W dniu 03.04.2019 o 10:34, Piotr Krysik via USRP-users pisze:

Hi all,

I'm trying to do calibration of phase offsets between TwinRX channels.

Configuration of X310 is following: two TwinRX'es, all sharing LOs from
fist channel of the second TwinRX.

The same signal is fed to all TwinRX channels through a RF splitter.

What is expected is some additional group delay for TwinRX that gets LO
signal through a cable from the other TwinRX.
This group delay was compensated by using longer RF cables between
splitter and RF inputs of TwinRX1 that uses external LOs from TwinRX2.

However, there is also unexpected effect: there are +/-90 degree phase
difference changes between channels of one TwinRX1 and TwinRX2 in
function of frequency.

Measurements were performed between 100MHz and 500MHz, and here are the
results:

1. 128MHz: +90 degrees
2. 172MHz: -90 degrees
3. 245MHz: +90 degrees
4. 260MHz: -90 degrees
5. 340MHz: +90 degrees

Here is example plot of phase difference fom channel 1 (TwinRX1) to
channels 2 and 3 (TwinRX2): https://imgur.com/4C09MSf
What I would expect (after compensation of LO cable length) was
something (~) flat, but there are these phase jumps by +/-90 degrees.

This effect can be included in calibration. But it would be best to
know: where these phase jumps for different frequencies come from?

Best Regards,
Piotr Krysik


The frequencies here are carrier frequencies that are being set for each
channel. On each carrier frequency measurement is performed - with use
of sine wave or noise signal. Sample rate was 2MS/s.

___
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] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Piotr Krysik via USRP-users]

W dniu 03.04.2019 o 10:34, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I'm trying to do calibration of phase offsets between TwinRX channels.
>
> Configuration of X310 is following: two TwinRX'es, all sharing LOs from
> fist channel of the second TwinRX.
>
> The same signal is fed to all TwinRX channels through a RF splitter.
>
> What is expected is some additional group delay for TwinRX that gets LO
> signal through a cable from the other TwinRX.
> This group delay was compensated by using longer RF cables between
> splitter and RF inputs of TwinRX1 that uses external LOs from TwinRX2.
>
> However, there is also unexpected effect: there are +/-90 degree phase
> difference changes between channels of one TwinRX1 and TwinRX2 in
> function of frequency.
>
> Measurements were performed between 100MHz and 500MHz, and here are the
> results:
>
> 1. 128MHz: +90 degrees
> 2. 172MHz: -90 degrees
> 3. 245MHz: +90 degrees
> 4. 260MHz: -90 degrees
> 5. 340MHz: +90 degrees
>
> Here is example plot of phase difference fom channel 1 (TwinRX1) to
> channels 2 and 3 (TwinRX2): https://imgur.com/4C09MSf
> What I would expect (after compensation of LO cable length) was
> something (~) flat, but there are these phase jumps by +/-90 degrees.
>
> This effect can be included in calibration. But it would be best to
> know: where these phase jumps for different frequencies come from?
>
> Best Regards,
> Piotr Krysik
>
The frequencies here are carrier frequencies that are being set for each
channel. On each carrier frequency measurement is performed - with use
of sine wave or noise signal. Sample rate was 2MS/s.

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

[USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

[Piotr Krysik via USRP-users]

Hi all,

I'm trying to do calibration of phase offsets between TwinRX channels.

Configuration of X310 is following: two TwinRX'es, all sharing LOs from
fist channel of the second TwinRX.

The same signal is fed to all TwinRX channels through a RF splitter.

What is expected is some additional group delay for TwinRX that gets LO
signal through a cable from the other TwinRX.
This group delay was compensated by using longer RF cables between
splitter and RF inputs of TwinRX1 that uses external LOs from TwinRX2.

However, there is also unexpected effect: there are +/-90 degree phase
difference changes between channels of one TwinRX1 and TwinRX2 in
function of frequency.

Measurements were performed between 100MHz and 500MHz, and here are the
results:

1. 128MHz: +90 degrees
2. 172MHz: -90 degrees
3. 245MHz: +90 degrees
4. 260MHz: -90 degrees
5. 340MHz: +90 degrees

Here is example plot of phase difference fom channel 1 (TwinRX1) to
channels 2 and 3 (TwinRX2): https://imgur.com/4C09MSf
What I would expect (after compensation of LO cable length) was
something (~) flat, but there are these phase jumps by +/-90 degrees.

This effect can be included in calibration. But it would be best to
know: where these phase jumps for different frequencies come from?

Best Regards,
Piotr Krysik


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