Re: [USRP-users] RFNoC questions - standalone system, docs

[Julius Baxter via USRP-users]

This was super enlightening, thanks! Pointers to any other posts like this
would be useful.

Cheers,
Jules

On Tue, 26 Mar 2019 at 03:35, Nick Foster  wrote:

> I wrote a blog post a while back describing a RX->TX RFNoC loopback
> application. It should still apply to the latest UHD:
>
> https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/
>
> Nick
>
> On Sun, Mar 24, 2019 at 5:33 PM Julius Baxter via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all,
>>
>> I have a couple of quick questions.
>>
>> I have an N310 and intend to build a system which doesn't involve passing
>> the stream through a host - ie. I want to add a CE or two which will handle
>> Rx and generate samples for Tx. Has anyone done this, are there any
>> pointers? I presume the host will still be involved to configure the blocks
>> (radio, ddc, duc, etc.). Can I still use the Python USRP API to do this
>> config?
>>
>> Is there anything complementing the Ettus KB on the RFNoC internals? I've
>> seen some posts referencing what parameters on various blocks do, and other
>> nuggets of knowledge regarding building CEs for RFNoC. Is there a
>> centralised place for details on how RFNoC works, or is reading the RTL and
>> this ml the best source of info?
>>
>> Thanks,
>> Jules
>>
>>
>> ___
>> 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] UBX coherence between TX and RX

[Michael R. Freedman via USRP-users]

Marcus,

   190Hz is what we calculated.  I have attached a text file with the 
data we used.  This is a single UBX40 tuned to 155MHz sampling at 2MHz.



Mike


On 03/25/2019 12:34 PM, Nick Foster wrote:
Well, according to your description, you could transmit a carrier from 
TX to RX (through an attenuator) with both sides set to the same 
frequency. Your received signal should look like a sine wave at the 
frequency of the offset.


On Mon, Mar 25, 2019 at 9:16 AM Michael R. Freedman via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hello,

Do you have any suggestions as to how to measure the frequency
delta between the transmit channel and the receive channel?

As I sat down to do this, I realized I have no real way to do that.


Mike





On 03/24/2019 03:23 PM, Marcus D. Leech via USRP-users wrote:

On 03/24/2019 02:39 PM, Freedman, Michael - 1008 - MITLL via
USRP-users wrote:

It is not just a phase offset. It is a frequency offset. The phase drifts 
between the two. I can tolerate a phase offset at startup. A freq offset 
however is causing problems.

Mike

Sent from my iPhone

On Mar 24, 2019, at 4:28 AM, Marcus Müller 
  wrote:

Can you elaborate on what "not coherent" means to you – the relative
phase should be constant after each tune, but if you don't tune
simultaneously, i.e. with timed commands, random at each tune.

Best regards,
Marcus

Also, what version of UHD?  What hardware rev of UBX cards?



On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
wrote:

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



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



6848,-1701
-7115,1735
6829,-1635
-6906,1657
6578,-1640
-6690,1660
6385,-1683
-6514,1807
6275,-1790
-6434,1835
6220,-1824
-6413,1852
6205,-1827
-6395,1893
6192,-1863
-6400,1904
6177,-1899
-6367,1962
6164,-1901
-6378,1945
6172,-1889
-6367,1950
6172,-1913
-6380,1916
6184,-1870
-6389,1896
6189,-1844
-6373,1934
6168,-1914
-6365,1975
6171,-1903
-6363,1983
6148,-1961
-6360,1989
6156,-1897
-6384,1903
6182,-1850
-6375,1901
6172,-1891
-6356,1969
6170,-1917
-6370,1945
6171,-1918
-6350,1977
6157,-1944
-6359,1985
6172,-1885
-6361,1954
6183,-1860
-6377,1912
6166,-1908
-6373,1926
6168,-1866
-6379,1901
6170,-1871
-6363,1949
6163,-1941
-6358,1944
6151,-1955
-6338,2013
6151,-1928
-6364,1941
6170,-1888
-6375,1898
6168,-1891
-6362,1912
6169,-1856
-6370,1924
6163,-1882
-6370,1906
6177,-1862
-6367,1905
6176,-1866
-6360,1939
6145,-1938
-6355,1973
6141,-1950
-6356,1968
6156,-1919
-6367,1926
6159,-1927
-6340,1967
6140,-1983
-6321,2044
6145,-1955
-6356,1956
6151,-1944
-6362,1965
6157,-1935
-6344,1988
6159,-1924
-6356,1950
6162,-1913
-6361,1947
6157,-1936
-6340,1987
6152,-1935
-6357,1953
6152,-1925
-6346,1980
6155,-1914
-6356,1953
6152,-1925
-6346,1967
6144,-1948
-6359,1970
6163,-1909
-6355,1969
6158,-1913
-6350,1975
6130,-1993
-6326,2041
6145,-1951
-6333,2008
6139,-1965
-6354,1962
6161,-1892
-6357,1940
6153,-1939
-6338,1995
6137,-1966
-6325,2026
6132,-1976
-6338,1998
6130,-1994
-6324,2047
6132,-1983
-6337,2021
6134,-1967
-6340,1983
6159,-1906
-6364,1923
6167,-1849
-6370,1893
6173,-1866
-6352,1932
6156,-1922
-6335,1980
6143,-1935
-6357,1946
6143,-1927
-6331,1983
6154,-1899
-6342,1962
6162,-1894
-6335,1975
6143,-1930
-6346,1949
6158,-1904
-6343,1984
6135,-1960
-6347,1979
6149,-1916
-6344,1978
6152,-1899
-6334,1989
6146,-1939
-6351,1938
6165,-1884
-6349,1959
6154,-1897
-6343,1948
6143,-1934
-6367,1897
6172,-1829
-6380,1847
6164,-1899
-6348,1968
6145,-1929
-6352,1

Re: [USRP-users] A few questions about RFNoC streaming

[Nick Foster via USRP-users]

I can tell you the answer to #3 off the top of my head: the two streams
will be sample-aligned, and if you use timed start commands, they will be
time-aligned.

The other two are probably best answered by trying it out. Maybe someone
from Ettus can chime in.

Nick

On Fri, Mar 22, 2019 at 7:09 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Any suggestions?
>
> On Wed, Mar 20, 2019 at 9:49 PM Rob Kossler  wrote:
>
>> Yes, the example was for illustration only.  You can throw a couple of
>> DDCs in between the radio and add/sub block to slow the rate down.  But,
>> the questions are still the same.
>>
>> On Wed, Mar 20, 2019 at 7:49 PM Nick Foster  wrote:
>>
>>> First things first. The flow graph you're describing don't work because
>>> the two radio blocks will saturate the bus going into the addsub block. You
>>> will need to decimate the streams going into the addsub block.
>>>
>>> I don't have a ready answer to your question about the streamers, but
>>> I'd suggest using timed commands to align the two radio streams, if UHD
>>> isn't smart enough to recognize the two radios and propagate the stream
>>> command accordingly.
>>>
>>> Nick
>>>
>>> On Thu, Mar 21, 2019, 6:46 AM Rob Kossler via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi,
 I am starting to develop more complicated RFNoC graphs and several
 questions occurred to me. I am using my own C++ application with the UHD
 RFNoC-enabled library.

 Consider a receive-only RFNoC graph with 2 radio blocks feeding a
 2-input, 2-output Add/Sub block.  Also, assume there are two rx_streamers
 connected to the 2 output ports of the Add/Sub block.  Note that these
 streams are no longer independent or one-to-one matched with the radio
 channels.

 1) How does an "issue_stream_cmd()" to one of the Add/Sub block ports
 propagate back to the radio block?  Actually, it would need to propagate
 back to both Radio blocks no matter which rx_streamer I used since they are
 no longer independent streams.  Does this make sense?
 2) What happens if I only call "issue_stream_cmd()" for one of the
 rx_streamers instead of both? Perhaps since the other streamer isn't
 running, it backpressures the streaming such that it eventually quits and
 thus quits for the other port as well?
 3) Do I have to do anything in the Add/Sub block to sync up the streams
 or can I rely on the first sample from Radio 0 being time-aligned with the
 first sample from Radio 1 (assuming I issued timed start commands)?

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

Re: [USRP-users] RFNoC questions - standalone system, docs

[Nick Foster via USRP-users]

I wrote a blog post a while back describing a RX->TX RFNoC loopback
application. It should still apply to the latest UHD:

https://corvid.io/2017/04/22/stupid-rfnoc-tricks-loopback/

Nick

On Sun, Mar 24, 2019 at 5:33 PM Julius Baxter via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I have a couple of quick questions.
>
> I have an N310 and intend to build a system which doesn't involve passing
> the stream through a host - ie. I want to add a CE or two which will handle
> Rx and generate samples for Tx. Has anyone done this, are there any
> pointers? I presume the host will still be involved to configure the blocks
> (radio, ddc, duc, etc.). Can I still use the Python USRP API to do this
> config?
>
> Is there anything complementing the Ettus KB on the RFNoC internals? I've
> seen some posts referencing what parameters on various blocks do, and other
> nuggets of knowledge regarding building CEs for RFNoC. Is there a
> centralised place for details on how RFNoC works, or is reading the RTL and
> this ml the best source of info?
>
> Thanks,
> Jules
>
>
> ___
> 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] UBX coherence between TX and RX

[Nick Foster via USRP-users]

Well, according to your description, you could transmit a carrier from TX
to RX (through an attenuator) with both sides set to the same frequency.
Your received signal should look like a sine wave at the frequency of the
offset.

On Mon, Mar 25, 2019 at 9:16 AM Michael R. Freedman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> Do you have any suggestions as to how to measure the frequency delta
> between the transmit channel and the receive channel?
>
> As I sat down to do this, I realized I have no real way to do that.
>
>
> Mike
>
>
>
>
>
> On 03/24/2019 03:23 PM, Marcus D. Leech via USRP-users wrote:
>
> On 03/24/2019 02:39 PM, Freedman, Michael - 1008 - MITLL via USRP-users
> wrote:
>
> It is not just a phase offset. It is a frequency offset. The phase drifts 
> between the two. I can tolerate a phase offset at startup. A freq offset 
> however is causing problems.
>
> Mike
>
> Sent from my iPhone
>
> On Mar 24, 2019, at 4:28 AM, Marcus Müller  
>  wrote:
>
> Can you elaborate on what "not coherent" means to you – the relative
> phase should be constant after each tune, but if you don't tune
> simultaneously, i.e. with timed commands, random at each tune.
>
> Best regards,
> Marcus
>
> Also, what version of UHD?  What hardware rev of UBX cards?
>
>
> On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
> wrote:
>
> 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 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] UBX coherence between TX and RX

[Michael R. Freedman via USRP-users]

Hello,

Do you have any suggestions as to how to measure the frequency delta 
between the transmit channel and the receive channel?


As I sat down to do this, I realized I have no real way to do that.

Mike





On 03/24/2019 03:23 PM, Marcus D. Leech via USRP-users wrote:
On 03/24/2019 02:39 PM, Freedman, Michael - 1008 - MITLL via 
USRP-users wrote:

It is not just a phase offset. It is a frequency offset. The phase drifts 
between the two. I can tolerate a phase offset at startup. A freq offset 
however is causing problems.

Mike

Sent from my iPhone

On Mar 24, 2019, at 4:28 AM, Marcus Müller  wrote:

Can you elaborate on what "not coherent" means to you – the relative
phase should be constant after each tune, but if you don't tune
simultaneously, i.e. with timed commands, random at each tune.

Best regards,
Marcus

Also, what version of UHD?  What hardware rev of UBX cards?



On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
wrote:

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



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

Re: [USRP-users] X310 unable to connect after recovery procedure

[Joe Martin via USRP-users]

Thanks, Nicolas.  I am interested to hear how you eventually clear the problem 
as I also have an X310 and so far all works fine but someday I may face the 
same issue as you are experiencing so please when you find a solution please 
post it.  I am not experienced enough yet with mine to be able to suggest a 
solution for you unfortunately.  Maybe someone else can. 

 I (like you) am eager to hear any suggestion(s) to resolve your issue.

Regards, 

Joe

> On Mar 25, 2019, at 9:28 AM, Nicolas GALLAND  wrote:
> 
> Hi,
> 
> it is indeed a typo here. I did ping 192.168.10.2 first, and then I tried on 
> 192.168.10.3 to see if the error message was the same. In any case (even 
> using ping broadcast on all the sub network my computer is connected to) i 
> have this message. It looks like there is a connection between the computer 
> and the device, since my computer says there is no more network when I switch 
> off the USRP.
> 
> Kind regards
> 
> Nicolas
> Le 22/03/2019 à 18:52, Joe Martin a écrit :
>> Nicolas,
>> 
>> It appears you were pinging 192.168.10.3, not 192.168.10.2.  Maybe this 
>> particular example was simply a typo and you used the correct IP address to 
>> ping during your other tests?
>> 
>> Regards,
>> 
>> Joe
>> 
>>> On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users 
>>>  wrote:
>>> 
>>> Hello everyone,
>>> 
>>> I had some trouble with my X310 and I needed to upload my UHD installation 
>>> and consequently to update the FPGA image on the board. After doing it 
>>> through eternet port, I lost connection so I decide to follow the recovery 
>>> procedure to upload the FPGA image using the JTAG port (following 
>>> https://kb.ettus.com/X300/X310_Device_Recovery).
>>> 
>>> The upload is fine, and the computer recognises the network with IP address 
>>> 192.168.10.1, but when I try to ping 192.168.10.2 (as explained in the 
>>> procedure) I have
>>> 
>>> PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
>>> From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
>>> From 192.168.10.1 icmp_seq=5 Destination Host Unreachable
>>> 
>>> until I stop it. I have two x310 in the same situation, and I tried on two 
>>> different computers with different ethernet cables.
>>> 
>>> Could the hardware be broken ? (If so, isn't it strange that the computer 
>>> still sees the network ?)
>>> 
>>> Thanks a lot, and nice week end !
>>> 
>>> Kind regards,
>>> 
>>> Nicolas
>>> 
> 


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

Re: [USRP-users] X310 unable to connect after recovery procedure

[Nicolas GALLAND via USRP-users]

Hi,

it is indeed a typo here. I did ping 192.168.10.2 first, and then I 
tried on 192.168.10.3 to see if the error message was the same. In any 
case (even using ping broadcast on all the sub network my computer is 
connected to) i have this message. It looks like there is a connection 
between the computer and the device, since my computer says there is no 
more network when I switch off the USRP.


Kind regards

Nicolas
Le 22/03/2019 à 18:52, Joe Martin a écrit :

Nicolas,

It appears you were pinging 192.168.10.3, not 192.168.10.2.  Maybe this 
particular example was simply a typo and you used the correct IP address to 
ping during your other tests?

Regards,

Joe


On Mar 22, 2019, at 11:05 AM, Nicolas GALLAND via USRP-users 
 wrote:

Hello everyone,

I had some trouble with my X310 and I needed to upload my UHD installation and 
consequently to update the FPGA image on the board. After doing it through 
eternet port, I lost connection so I decide to follow the recovery procedure to 
upload the FPGA image using the JTAG port (following 
https://kb.ettus.com/X300/X310_Device_Recovery).

The upload is fine, and the computer recognises the network with IP address 
192.168.10.1, but when I try to ping 192.168.10.2 (as explained in the 
procedure) I have

PING 192.168.10.3 (192.168.10.3) 56(84) bytes of data.
 From 192.168.10.1 icmp_seq=1 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=2 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=3 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=4 Destination Host Unreachable
 From 192.168.10.1 icmp_seq=5 Destination Host Unreachable

until I stop it. I have two x310 in the same situation, and I tried on two 
different computers with different ethernet cables.

Could the hardware be broken ? (If so, isn't it strange that the computer still 
sees the network ?)

Thanks a lot, and nice week end !

Kind regards,

 Nicolas



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

Re: [USRP-users] Problem receiving two signals simultaneously usinig two different daughterboards

[Marcus D. Leech via USRP-users]

On 03/25/2019 04:37 AM, Julian Ilinca via USRP-users wrote:

Hello all,

I'm relatively new to world of USRP, and having some problems with 
configuring
two USRP N210 devices to receive simultaneously. I am just trying to 
do a proof

of concept type of experiment.

In my setup one of the N210.s is equipped with a WBX daughterboard and 
the other
with a TVRX2 daughterboard, as my frequency of interest lies within 
the FM-radio
region. The devices are connected to each other via a MIMO cable. One 
port on each
device is connected to an antenna (Port RX2 on the master device 
equipped with the
WBX and port RX1 on the slave device equipped with the TVRX2). So far 
I think I
have gotten my setup to run smoothly, except for when I am receiving a 
signal only
one of the two ports in which I have my antennas connected is showing 
a signal.


I'm using the UHD C++ API to configure the system. I think my problem 
lies within
my inability set the channel configuration settings correctly. The 
configuration
settings are displayed in the code below. Another possible reason for 
this situation

could be that there is some problem with how I have setup the buffering.

The code:

int UHD_SAFE_MAIN(int argc, char *argv[]){

std::string ant_ch0("RX2");
std::string ant_ch1("RX1");
std::string ref("mimo");
std::string time("mimo");

//Master device address
std::string master_args("192.168.10.2");

// Slave device address
std::string slave_args("192.168.10.3");

// sub_dev parameters for channel mapping
std::string subdev0("A:0");
std::string subdev1("A:RX1");

// Numbers taken by using command uhd_find_devices in terminal
//int master_index = 1;
//int slave_index = 0;

// Common variables
double freq(105e6);
double gain(10);
double bw(1.7e6);
double rate2(1e7); // for data transmission rate from USRP to host

// Channel numbers
size_t ch1 = size_t(~0);
size_t ch0 = size_t(~0);
ch1 = 1;
ch0 = 0;

// Motherboard indices for setting sources
const size_t mb1 = 1;
const size_t mb0 = 0;


// --- CONFIGURATION 
---


// Addressing and defining the usrp devices
uhd::device_addr_t addresses("addr0=192.168.10.2, 
addr1=192.168.10.3");
uhd::usrp::multi_usrp::sptr usrp 
=uhd::usrp::multi_usrp::make(addresses);


// Setup Subdevice specification:
// The subdev spec maps a physical part of the daughter board to a 
channel number
// Here we create two channels on two separate mboards on two 
separate usrp devices

usrp->set_rx_subdev_spec(subdev0,ch0);
usrp->set_rx_subdev_spec(subdev1,ch1);

// Set rx rate (rate at which the data is
//transferred between the host and the device)
usrp->set_rx_rate(rate2); // sets across all channels


// Throw error if exactly two mother boards aren't connected
UHD_ASSERT_THROW(usrp->get_num_mboards() == 2);

// configuring the slave over mimo cable
// make m_board 1 slave over mimo cable
usrp->set_clock_source(ref, mb1);
usrp->set_time_source(ref, mb1);

// Set time on master mboard  \should have master mboard number
usrp->set_time_now(uhd::time_spec_t(0,0),mb0);

//Set master clock rate (this affects the digitization speed)
//usrp->set_master_clock_rate(rate, ch1);
//usrp->set_master_clock_rate(rate, ch2);


// Sleep a while so time can be properly locked
boost::this_thread::sleep(boost::posix_time::milliseconds(100));


// Set Gain
usrp->set_rx_gain(gain,ch1);
usrp->set_rx_gain(gain,ch0);

// Set center frequncy
uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request,ch1);
usrp->set_rx_freq(tune_request,ch0);

// Set Bandwidth
usrp->set_rx_bandwidth(bw,ch1);
usrp->set_rx_bandwidth(bw,ch0);


// Set antenna to recieve only
usrp->set_rx_antenna(ant_ch1,ch1);
usrp->set_rx_antenna(ant_ch0,ch0);

//-- GET AND WRITE DATA STREAM TO FILE 

// SETUP STREAMING PARAMETERS
uhd::stream_args_t stream_args("fc32","sc16");

// channels to use
int c1 =0;
int c2 =1;
std::vector  channel_nums(2);
channel_nums[1] = c1;
channel_nums[2] = c2;


uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

double seconds_in_future = 1.5;
double total_num_samps = 1;
// the first call to recieve will later on block this many seconds 
before recieving

double timeout = seconds_in_future +0.1;
size_t num_acc_samps = 0; //number of accumulated samples


uhd::stream_cmd_t 
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);

stream_cmd.num_samps = total_num_samps;
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(seconds_in_future);
rx_stream->issue_stream_cmd(stream_cmd);

//std::cout << "H2" << std::endl;

// CREATE BUFFERS
uhd::rx_metadata_t md; // will b

Re: [USRP-users] UBX coherence between TX and RX

[Michael R. Freedman via USRP-users]

Marcus,


Thanks for engaging in this.  I will have frequency deltas for you first 
thing this afternoon.



Mike


On 03/24/2019 03:07 PM, Marcus Müller wrote:

I can fully understand that! You don't happen to have an estimate for
that frequency offset's magnitude? Is it always the same drift? I'm
trying to narrow down analog vs numerical accuracy issues here.

Best regards,
Marcus
On Sun, 2019-03-24 at 18:39 +, Freedman, Michael - 1008 - MITLL
wrote:

It is not just a phase offset. It is a frequency offset. The phase
drifts between the two. I can tolerate a phase offset at startup. A
freq offset however is causing problems.

Mike

Sent from my iPhone

On Mar 24, 2019, at 4:28 AM, Marcus Müller 
wrote:

Can you elaborate on what "not coherent" means to you – the relative
phase should be constant after each tune, but if you don't tune
simultaneously, i.e. with timed commands, random at each tune.

Best regards,
Marcus
On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
wrote:

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



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

Re: [USRP-users] UBX coherence between TX and RX

[Michael R. Freedman via USRP-users]

Marcus,


In this setup I have 6 UBX-160 v2 and 6 UBX-40 v2.    The USRPs are all 
X310 Rev 11, Rev_compat 7.   I have tried 3.13.1 as well as 3.14-rc3.



Thanks!

   Mike


On 03/24/2019 03:23 PM, Marcus D. Leech via USRP-users wrote:
On 03/24/2019 02:39 PM, Freedman, Michael - 1008 - MITLL via 
USRP-users wrote:

It is not just a phase offset. It is a frequency offset. The phase drifts 
between the two. I can tolerate a phase offset at startup. A freq offset 
however is causing problems.

Mike

Sent from my iPhone

On Mar 24, 2019, at 4:28 AM, Marcus Müller  wrote:

Can you elaborate on what "not coherent" means to you – the relative
phase should be constant after each tune, but if you don't tune
simultaneously, i.e. with timed commands, random at each tune.

Best regards,
Marcus

Also, what version of UHD?  What hardware rev of UBX cards?



On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
wrote:

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



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

Re: [USRP-users] Gnuradio loopback TX and RX example

[Varban Metodiev via USRP-users]

Hi Marcus,

Great... thank you very much for your help!

Regards,
Varban

On Monday, March 25, 2019, Marcus Müller  wrote:

> Hi Varban,
>
> GNU Radio ships with examples; typically, these get installed to
> /usr/[local/]share/gnuradio/examples on Linux and similar systems.
>
> You're looking for
> examples/digital/packet/packet_{rx,tx,loopback_hier}.grc
>
> Best regards,
> Marcus
>
> On Mon, 2019-03-25 at 10:20 +0200, Varban Metodiev via USRP-users
> wrote:
> > Dear all,
> >
> > For quite some time I have been trying to transmit a single byte in a
> > loopback scenario. I have the following questions:
> > 1) Could anyone help me with an example about this?
> > 2) Right now I am sending the digital data directly to the USRP Sink
> > block. Is this fine, or a one should send a digital description of an
> > analog signal to it?
> >
> > Thanks in advance,
> > Varban
> >
> >
> > ___
> > 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] Gnuradio loopback TX and RX example

[Marcus Müller via USRP-users]

Hi Varban,

GNU Radio ships with examples; typically, these get installed to
/usr/[local/]share/gnuradio/examples on Linux and similar systems.

You're looking for
examples/digital/packet/packet_{rx,tx,loopback_hier}.grc

Best regards,
Marcus

On Mon, 2019-03-25 at 10:20 +0200, Varban Metodiev via USRP-users
wrote:
> Dear all,
> 
> For quite some time I have been trying to transmit a single byte in a
> loopback scenario. I have the following questions:
> 1) Could anyone help me with an example about this?
> 2) Right now I am sending the digital data directly to the USRP Sink
> block. Is this fine, or a one should send a digital description of an
> analog signal to it?
> 
> Thanks in advance,
> Varban
> 
> 
> ___
> 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] Problem receiving two signals simultaneously usinig two different daughterboards

[Julian Ilinca via USRP-users]

Hello all,

I'm relatively new to world of USRP, and having some problems with
configuring
two USRP N210 devices to receive simultaneously. I am just trying to do a
proof
of concept type of experiment.

In my setup one of the N210.s is equipped with a WBX daughterboard and the
other
with a TVRX2 daughterboard, as my frequency of interest lies within the
FM-radio
region. The devices are connected to each other via a MIMO cable. One port
on each
device is connected to an antenna (Port RX2 on the master device equipped
with the
WBX and port RX1 on the slave device equipped with the TVRX2). So far I
think I
have gotten my setup to run smoothly, except for when I am receiving a
signal only
one of the two ports in which I have my antennas connected is showing a
signal.

I'm using the UHD C++ API to configure the system. I think my problem lies
within
my inability set the channel configuration settings correctly. The
configuration
settings are displayed in the code below. Another possible reason for this
situation
could be that there is some problem with how I have setup the buffering.

The code:

int UHD_SAFE_MAIN(int argc, char *argv[]){

std::string ant_ch0("RX2");
std::string ant_ch1("RX1");
std::string ref("mimo");
std::string time("mimo");

//Master device address
std::string master_args("192.168.10.2");

// Slave device address
std::string slave_args("192.168.10.3");

// sub_dev parameters for channel mapping
std::string subdev0("A:0");
std::string subdev1("A:RX1");

// Numbers taken by using command uhd_find_devices in terminal
//int master_index = 1;
//int slave_index = 0;

// Common variables
double freq(105e6);
double gain(10);
double bw(1.7e6);
double rate2(1e7); // for data transmission rate from USRP to host

// Channel numbers
size_t ch1 = size_t(~0);
size_t ch0 = size_t(~0);
ch1 = 1;
ch0 = 0;

// Motherboard indices for setting sources
const size_t mb1 = 1;
const size_t mb0 = 0;


// --- CONFIGURATION
---

// Addressing and defining the usrp devices
uhd::device_addr_t addresses("addr0=192.168.10.2, addr1=192.168.10.3");
uhd::usrp::multi_usrp::sptr usrp
=uhd::usrp::multi_usrp::make(addresses);

// Setup Subdevice specification:
// The subdev spec maps a physical part of the daughter board to a
channel number
// Here we create two channels on two separate mboards on two separate
usrp devices
usrp->set_rx_subdev_spec(subdev0,ch0);
usrp->set_rx_subdev_spec(subdev1,ch1);

// Set rx rate (rate at which the data is
//transferred between the host and the device)
usrp->set_rx_rate(rate2); // sets across all channels


// Throw error if exactly two mother boards aren't connected
UHD_ASSERT_THROW(usrp->get_num_mboards() == 2);

// configuring the slave over mimo cable
// make m_board 1 slave over mimo cable
usrp->set_clock_source(ref, mb1);
usrp->set_time_source(ref, mb1);

// Set time on master mboard  \should have master mboard number
usrp->set_time_now(uhd::time_spec_t(0,0),mb0);

//Set master clock rate (this affects the digitization speed)
//usrp->set_master_clock_rate(rate, ch1);
//usrp->set_master_clock_rate(rate, ch2);


// Sleep a while so time can be properly locked
boost::this_thread::sleep(boost::posix_time::milliseconds(100));


// Set Gain
usrp->set_rx_gain(gain,ch1);
usrp->set_rx_gain(gain,ch0);

// Set center frequncy
uhd::tune_request_t tune_request(freq);
usrp->set_rx_freq(tune_request,ch1);
usrp->set_rx_freq(tune_request,ch0);

// Set Bandwidth
usrp->set_rx_bandwidth(bw,ch1);
usrp->set_rx_bandwidth(bw,ch0);


// Set antenna to recieve only
usrp->set_rx_antenna(ant_ch1,ch1);
usrp->set_rx_antenna(ant_ch0,ch0);

//-- GET AND WRITE DATA STREAM TO FILE 

// SETUP STREAMING PARAMETERS
uhd::stream_args_t stream_args("fc32","sc16");

// channels to use
int c1 =0;
int c2 =1;
std::vector  channel_nums(2);
channel_nums[1] = c1;
channel_nums[2] = c2;


uhd::rx_streamer::sptr rx_stream = usrp->get_rx_stream(stream_args);

double seconds_in_future = 1.5;
double total_num_samps = 1;
// the first call to recieve will later on block this many seconds
before recieving
double timeout = seconds_in_future +0.1;
size_t num_acc_samps = 0; //number of accumulated samples


uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE);
stream_cmd.num_samps = total_num_samps;
stream_cmd.stream_now = false;
stream_cmd.time_spec = uhd::time_spec_t(seconds_in_future);
rx_stream->issue_stream_cmd(stream_cmd);

//std::cout << "H2" << std::endl;

// CREATE BUFFERS
uhd::rx_metadata_t md; // will be filled automatically when data is
recieved
const size_t samps_per_buff = rx_str

[USRP-users] Gnuradio loopback TX and RX example

[Varban Metodiev via USRP-users]

Dear all,

For quite some time I have been trying to transmit a single byte in a
loopback scenario. I have the following questions:
1) Could anyone help me with an example about this?
2) Right now I am sending the digital data directly to the USRP Sink block.
Is this fine, or a one should send a digital description of an analog
signal to it?

Thanks in advance,
Varban
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com