Re: [USRP-users] E310, 3.15 LTS, Windows

[Nate Temple via USRP-users]

Hi Simon,

No, the USB cable will only provide serial access.

You could use GNU Radio to stream samples via ZMQ/TCP/UDP sockets. You
could also use pure C++/UHD API to stream via a UDP interface such as with
the example program rx_samples_to_udp.

Regards,
Nate Temple

On Mon, Feb 24, 2020 at 11:19 AM  wrote:

> Thanks,
>
>
>
> Would the E310 work with the USB cable?
>
>
>
> Simon Brown, G4ELI
>
> https://www.sdr-radio.com
>
>
>
> *From:* Nate Temple 
> *Sent:* 24 February 2020 19:11
> *To:* si...@sdr-radio.com
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] E310, 3.15 LTS, Windows
>
>
>
> Hi Simon,
>
> The E310 network mode was removed from UHD with the switch to the MPM
> based file systems. If you need to use the network mode, you should use an
> older version of UHD.
>
> Regards,
> Nate Temple
>
>
>
> On Mon, Feb 24, 2020 at 11:05 AM Simon G4ELI via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi All,
>
>
>
> A user cannot ‘see’ his E310 using 3.15 LTS compiled from source by me.
> The E310 is connected by Ethernet GigE.
>
>
>
> I’m wondering if there’s something special needed or if there’s a magic
> option I should enable in the source – the ENABLE_E300 option is checked,
> all looks good to me.
>
>
>
> There is a second person who will soon be testing just in case it’s finger
> trouble.
>
>
>
> Simon Brown, G4ELI
>
> https://www.sdr-radio.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] E310, 3.15 LTS, Windows

[Nate Temple via USRP-users]

Hi Simon,

The E310 network mode was removed from UHD with the switch to the MPM based
file systems. If you need to use the network mode, you should use an older
version of UHD.

Regards,
Nate Temple

On Mon, Feb 24, 2020 at 11:05 AM Simon G4ELI via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
>
>
> A user cannot ‘see’ his E310 using 3.15 LTS compiled from source by me.
> The E310 is connected by Ethernet GigE.
>
>
>
> I’m wondering if there’s something special needed or if there’s a magic
> option I should enable in the source – the ENABLE_E300 option is checked,
> all looks good to me.
>
>
>
> There is a second person who will soon be testing just in case it’s finger
> trouble.
>
>
>
> Simon Brown, G4ELI
>
> https://www.sdr-radio.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] USRP N310 Performance Issues

[Nate Temple via USRP-users]

Hi Austin,

>Is there a way to do it directly via the jtag and using the screen command
to speak with the N310?

You could connect to the ARM via JTAG as detailed in the link below, but
you're better off just SSH'ing into it.

https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Connecting_to_the_ARM_via_SSH

Streaming will be very flakey over any sort of wifi. Two options I'd
suggest exploring:

1) Use fiber to have a direct connection. Aqua multimode fiber is pretty
cheap and you can have long runs.

2) Put a host computer next to the USRP wherever it is installed, and
perform your DSP / streaming to that machine, Then connect to that remote
host via wifi for command and control. You can then stream at lower rate
your processed data off that host to a dashboard or whatever your
application is.

Regards,
Nate Temple



On Tue, Jan 28, 2020 at 3:34 PM Marcus D Leech 
wrote:

> Let’s do some quick math, shall we?
>
> 5msps with 16-bit complex == 160Mbit/second
> 1.25msps with 16-bit complex samples == an additional 40mbit-second
>
> Unless you have super reliable 1Gig wireless infrastructure, this just
> isn’t going to work.
>
> Sent from my iPhone
>
> On Jan 28, 2020, at 6:23 PM, Austin Adam via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hey Nate,
> Thanks for the quick response as always! I tried editing those files in
> the past, but I remember having issues because they were locked or I wasn’t
> able to actually save any changes that I made. Is there a way to do it
> directly via the jtag and using the screen command to speak with the N310?
>
> Also, unfortunately for the current project I am working on, we really
> need to have a wireless connection to the USRPs via the router. I am sure
> there is some way to make it work because we can still get data that looks
> good, it just starts to get clunky after a few seconds of streaming.
>
>
> On Jan 28, 2020, at 3:07 PM, Nate Temple  wrote:
>
> 
> Hi Austin,
>
> The MTUs on your host and N310 must match. You should modify the systemd
> configuration on the N310 are restart the whole device or restart
> systemd-networkd
>
>
> https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations
>
> It is not recommended to stream over a wireless connection as the
> additional delay will cause flow control errors. It is also generally
> recommended to not have a switch in line as some switches can reorder
> packets. You should directly connect to the USRP for the streaming
> interfaces. On the N3xx, it's fine to access the RJ45 management port via a
> switch.
>
> Regards,
> Nate Temple
>
>
>
> On Tue, Jan 28, 2020 at 2:52 PM Austin Adam via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi everyone,
>> I have a very basic GNU script with just a USRP block and a time sink
>> that when I run, there are tons of streaming errors with the tx and rx. In
>> GNU, the console is being filled with 'D's and the console for the N210 is
>> getting filled with 'U's and 'S's.
>>
>> My setup is just a USRP N210 connected to the RX LO ports of the N310. I
>> am sending the following command to the N210:
>>
>> *"sudo '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms'
>> --args "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX"
>> --subdev "A:0" --channels 0 --rate 1.25e6 --gain 29.5"*
>>
>> The USRPs are connected to a router via cat 5e cables, and then my laptop
>> is connected to the router via wifi. Something I noticed is that when I
>> connect to the router via ethernet to my laptop, I don't get any of the
>> performance issues. It seems to only happen over the wifi.
>>
>> When I run ifconfig on my laptop, my MTU is set to 1500, and on the USRP
>> N310 the MTU on the sfp0 port that we are using is 8000. I wasn't able to
>> change the MTU on the N310 because it said the device was in use, but those
>> values seem to work fine over ethernet so I didn't look too much into it.
>>
>> The sample rate on my GNU script is set to 5M for now, and lowering it
>> does seem to reduce the amount of 'D's that I get, but also negatively
>> affects our data.
>>
>> Lastly, here is some output from the N210 that shows the error:
>>
>> *austin@Austin-Blade:~$ sudo '/home/*austin
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> */workarea-uhd/uhd/host/build/examples/tx_waveforms' --args
>> "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX" --subdev
>> "A:0" --channels 0 --rate 1.25e6 --gain 29.5Creating the usrp device with:
>> addr=192.168.10.15,type=usrp2...[INFO] [UHD] linux; GNU C++ version 8.3.0;
>> Boost_106700; UHD_3.14.0.HEAD-0-g6875d061[INFO] [USRP2] Opening a
>> USRP2/N-Series device...[INFO] [USRP2] Current recv frame size: 1472
>> bytes[INFO] [USRP2] Current send frame size: 1472 bytesUsing Device: Single
>> USRP:  Device: USRP2 / N-Series Device  Mboard 0: N210r4  RX Channel: 0
>> RX DSP: 0RX Dboard: ARX Subdev: SBXv3 

Re: [USRP-users] USRP N310 Performance Issues

[Nate Temple via USRP-users]

Hi Austin,

The MTUs on your host and N310 must match. You should modify the systemd
configuration on the N310 are restart the whole device or restart
systemd-networkd

https://kb.ettus.com/USRP_N300/N310/N320/N321_Getting_Started_Guide#Updating_the_Network_Configurations

It is not recommended to stream over a wireless connection as the
additional delay will cause flow control errors. It is also generally
recommended to not have a switch in line as some switches can reorder
packets. You should directly connect to the USRP for the streaming
interfaces. On the N3xx, it's fine to access the RJ45 management port via a
switch.

Regards,
Nate Temple



On Tue, Jan 28, 2020 at 2:52 PM Austin Adam via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
> I have a very basic GNU script with just a USRP block and a time sink that
> when I run, there are tons of streaming errors with the tx and rx. In GNU,
> the console is being filled with 'D's and the console for the N210 is
> getting filled with 'U's and 'S's.
>
> My setup is just a USRP N210 connected to the RX LO ports of the N310. I
> am sending the following command to the N210:
>
> *"sudo '/home/austin/workarea-uhd/uhd/host/build/examples/tx_waveforms'
> --args "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX"
> --subdev "A:0" --channels 0 --rate 1.25e6 --gain 29.5"*
>
> The USRPs are connected to a router via cat 5e cables, and then my laptop
> is connected to the router via wifi. Something I noticed is that when I
> connect to the router via ethernet to my laptop, I don't get any of the
> performance issues. It seems to only happen over the wifi.
>
> When I run ifconfig on my laptop, my MTU is set to 1500, and on the USRP
> N310 the MTU on the sfp0 port that we are using is 8000. I wasn't able to
> change the MTU on the N310 because it said the device was in use, but those
> values seem to work fine over ethernet so I didn't look too much into it.
>
> The sample rate on my GNU script is set to 5M for now, and lowering it
> does seem to reduce the amount of 'D's that I get, but also negatively
> affects our data.
>
> Lastly, here is some output from the N210 that shows the error:
>
> *austin@Austin-Blade:~$ sudo '/home/*austin
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> */workarea-uhd/uhd/host/build/examples/tx_waveforms' --args
> "addr=192.168.10.15,type=usrp2" --freq 3.9e9 --ant "TX/RX" --subdev
> "A:0" --channels 0 --rate 1.25e6 --gain 29.5Creating the usrp device with:
> addr=192.168.10.15,type=usrp2...[INFO] [UHD] linux; GNU C++ version 8.3.0;
> Boost_106700; UHD_3.14.0.HEAD-0-g6875d061[INFO] [USRP2] Opening a
> USRP2/N-Series device...[INFO] [USRP2] Current recv frame size: 1472
> bytes[INFO] [USRP2] Current send frame size: 1472 bytesUsing Device: Single
> USRP:  Device: USRP2 / N-Series Device  Mboard 0: N210r4  RX Channel: 0
> RX DSP: 0RX Dboard: ARX Subdev: SBXv3 RX  TX Channel: 0TX DSP:
> 0TX Dboard: ATX Subdev: SBXv3 TXSetting TX Rate: 1.25
> Msps...Actual TX Rate: 1.25 Msps...Setting TX Freq: 3900.00
> MHz...Setting TX LO Offset: 0.00 MHz...Actual TX Freq: 3900.00
> MHz...Setting TX Gain: 29.50 dB...Actual TX Gain: 29.50
> dB...Setting device timestamp to 0...Checking TX: LO: locked ...Press Ctrl
> + C to stop streaming...*UUUS[ERROR] [USRP2] Control packet attempt
> 0, sequence number 470:
> RuntimeError: no control response, possible packet loss
> UUUSSUU^C
> *  Done!*
>
> I appreciate any help that anyone has to offer!
>
> Best,
> Austin
> ___
> 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] DOA with N310 or X310+TwinRX

[Nate Temple via USRP-users]

Hi Sammy,

>Can I turn it off and come back the next day and still have the same phase
offset between the channels that I had the day before?

Yes. This assumes that you are running with the same frequency, gain,
sample rate and system temperature that your calibrations were made with.
Also unless you have phase stable cables, if you move your cables at all,
it can cause phase variation.


Regards,
Nate Temple

On Mon, Jan 27, 2020 at 9:29 AM Sammy Welschen 
wrote:

> Hi Nate, thank you for the information.
>
> I'm still a bit unsure what repeatable phase offset means exactly. Suppose
> I have a system with 8 channels with X310+TwinRX and shared LO. Can I turn
> it off and come back the next day and still have the same phase offset
> between the channels that I had the day before?
>
> Sammy
>
> Nate Temple via USRP-users  schrieb am Mo.,
> 27. Jan. 2020, 18:04:
>
>> Hi Rob, Robert, Sammy:
>>
>> Generally for this type of application we would recommend the
>> X310+TwinRx. With the TwinRX, you'll be able to have repeatable phase
>> offsets with a given gain, frequency, sample rate and temperature of a
>> device/system. The N310 will have a 180 degree phase ambiguity due to the
>> /2 LO architecture.
>>
>> It is possible to share the LO across multiple motherboards for a
>> X310/Twin setup, and with the NI branded X310+TwinRX setup (NI-2955) the
>> LO's are provided out of the back panel. The chassis for currently shipping
>> and Rev C, F, G X310's back plate has the holes for the LO cables, but the
>> sticker needs to be removed. This application note covers the process:
>> https://kb.ettus.com/Modifying_an_X310_Chassis_for_External_LO_Sharing
>>
>> You'll also need to provide a splitter and most likely an inline
>> amplifier to overcome splitter losses. A splitter such as the ZFRSC-4-842+
>> will work. https://www.minicircuits.com/pdfs/ZFRSC-4-842+.pdf
>>
>>
>> @Rob: With the current init process of the N310, yes it is required to
>> first set the external LO to 5 GHz.
>>
>> With regards to the offsets you're seeing, I believe you should only see
>> a possible phase difference of 180* within the two channels on the same DB.
>> Are you issuing a tune request at the start of streaming?
>>
>> Regards,
>> Nate Temple
>>
>> On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Robert, Sammy,
>>> I am presently running some tests which compare the X310/TwinRx and the
>>> N310 with regard to channel-to-channel phase.  In my setup, I have a signal
>>> source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
>>> TwinRx and 4 channels of my N310. I have seen some strange behavior of the
>>> N310 that perhaps Robert has experienced?  Take a look:
>>>
>>>- For the TwinRx (for which I am a more experienced user with LO
>>>sharing), I get consistent channel-to-channel phase difference among all
>>>channels. This is true regardless of power cycles, re-starts of UHD, etc.
>>>- For the N310 (for which I am a beginner when it comes to external
>>>LO operation)
>>>   - it seems more complex to run in this mode (as compared to
>>>   TwinRx).  In order to get it to work, I have had to disable startup 
>>> QEC
>>>   calibration because it seems that the N310 initial cal occurs at 2500 
>>> MHz
>>>   RF such that I would need to have my external LO at 5000 MHz for 
>>> startup
>>>   (during the UHD deveice 'make') and then later switch my external LO 
>>> to the
>>>   desired RF*2. Is this true?
>>>   - when I run with either external LO or internal LO, I see
>>>   inconsistent channel-to-channel phase results even between the two 
>>> channels
>>>   of a given daughterboard that share the same LO.  I do not understand 
>>> how
>>>   this is possible.  My results over 16 captures (with some re-starts 
>>> of UHD,
>>>   device reboots, and switching between internal/external LO) show the
>>>   following channel-to-channel phase difference between channels 0 and 1
>>>   which share the same LO: (values in degrees) -77, -19, -77, -19, -77, 
>>> -19,
>>>   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
>>> only 3
>>>   unique values and the delta happens to be 58 deg, but I don't know 
>>> what
>>>   that implies...
>>>
>>> Rob
>>>
>>>
>>> On M

Re: [USRP-users] N310 phase jumps with 1 daughterboard

[Nate Temple via USRP-users]

Hi Rob,

Thanks for trying your setup with 3.15.0.0.

I will see what I can do about getting these fixes backported to 3.14, any
changes will need to be on the UHD-3.14 branch (the maint branch for 3.14),
we won't be able to apply these changes to 3.14.1.1, as it's a tagged
release.

Regards,
Nate Temple

On Mon, Jan 27, 2020 at 2:46 PM Rob Kossler  wrote:

> Nate,
> After switching to 3.15, I now get consistent results such that the
> relative phase between channels is as follows:
> - chan 0 to chan 1: constant
> - chan 1 to chan 2: constant +/- 180 deg
> - chan 2 to chan 3: constant
>
> So, it seems that the problem was in 3.14.
> Rob
>
> On Mon, Jan 27, 2020 at 3:45 PM Rob Kossler  wrote:
>
>> Nate,
>> So, I retested with 3.14.1.1 and got erratic results (same as last
>> week).  Now I am attempting to go to 3.15.0.0.  To make things as painless
>> as possible, I tried to just re-build MPM on the device and then update the
>> other stuff on the host (rather than flashing a new file system).  However,
>> MPM doesn't seem to build (see error below). I'm guessing this error is
>> related to something in the file system that is going to force me to
>> re-flash the file system.  Can you take a look and let me know if there is
>> an easier way.
>> Rob
>>
>> root@ni-n3xx-318F043:~/build_mpm# make -j2
>> [  5%] Built target periphs
>> [ 10%] Built target dboards
>> [ 27%] Built target mykonos
>> [ 32%] Built target spi
>> [ 34%] Building C object lib/i2c/CMakeFiles/i2c.dir/i2cdev.c.o
>> Scanning dependencies of target types
>> [ 36%] Building CXX object lib/types/CMakeFiles/types.dir/lockable.cpp.o
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c: In function 'i2cdev_open':
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c:26:33: error: 'O_LARGEFILE'
>> undeclared (first use in this function); did you mean '__O_LARGEFILE'?
>>  *fd = open(device, O_RDWR | O_LARGEFILE);
>>  ^~~
>>  __O_LARGEFILE
>> /home/root/uhd/uhd/mpm/lib/i2c/i2cdev.c:26:33: note: each undeclared
>> identifier is reported only once for each function it appears in
>> make[2]: *** [lib/i2c/CMakeFiles/i2c.dir/build.make:111:
>> lib/i2c/CMakeFiles/i2c.dir/i2cdev.c.o] Error 1
>> make[1]: *** [CMakeFiles/Makefile2:466: lib/i2c/CMakeFiles/i2c.dir/all]
>> Error 2
>> make[1]: *** Waiting for unfinished jobs
>> [ 38%] Building CXX object lib/types/CMakeFiles/types.dir/log_buf.cpp.o
>> [ 40%] Building CXX object
>> lib/types/CMakeFiles/types.dir/mmap_regs_iface.cpp.o
>> [ 40%] Built target types
>> make: *** [Makefile:141: all] Error 2
>> root@ni-n3xx-318F043:~/build_mpm#
>>
>>
>> On Mon, Jan 27, 2020 at 2:21 PM Rob Kossler  wrote:
>>
>>> ok.
>>>
>>> Yes, I always use timed tune commands. If that were not happening
>>> correctly, I don't think I could get consistent results with TwinRx.
>>>
>>> I am presently using 3.14.1.1.  I will complete the testing (using
>>> internal LO) I've already begun with this version and then re-test some/all
>>> using 3.15.  Assuming that the results are different, it would seem that
>>> Ettus should consider applying the fixes to the 3.14 branch.
>>>
>>> Rob
>>>
>>>
>>> On Mon, Jan 27, 2020 at 2:18 PM Nate Temple 
>>> wrote:
>>>
 Hi Rob,

 One other thing, if you're not on UHD v3.15.0.0, I'd recommend to
 update to it. There was some phase reset and accumulator fixes with
 3.15.0.0.

 https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/CHANGELOG#L44


 Regards,
 Nate Temple

 On Mon, Jan 27, 2020 at 11:17 AM Nate Temple 
 wrote:

> Hi Rob,
>
> You should always use a tune request with a timed command when you
> want to align channels.
>
> One thing you could test is to try using the internal LO and see if
> you get different results.
>
> Also you could try using the integer N tuning mode, but I don't think
> it will make any difference for this issue. Checkout this great blog post
> on USRP tuning if you haven't seen it before that covers a few more tips 
> on
> USRP tuning:
> http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html
>
> Regards,
> Nate Temple
>
> On Mon, Jan 27, 2020 at 9:33 AM Rob Kossler  wrote:
>
>> Hi Nate,
>> I changed the subject as to not further hijack the other thread. Of
>> the 16 captures I collected, some of them included a tuning command (but
>> using the same timed commands I use for other devices such as TwinRx). 
>> But,
>> others did not.  For example, for the first two data points below (with
>> measured phase difference of -77 and -19 respectively).  I simply issued
>> two consecutive timed streaming commands.  So, I was very perplexed by 
>> the
>> results.
>>
>> In any event, I plan to re-take the data today both with and without
>> a DDC.  Hopefully, if I get rid of the DDC, I will see consistent phase
>> 

Re: [USRP-users] N310 phase jumps with 1 daughterboard

[Nate Temple via USRP-users]

Hi Rob,

One other thing, if you're not on UHD v3.15.0.0, I'd recommend to update to
it. There was some phase reset and accumulator fixes with 3.15.0.0.

https://github.com/EttusResearch/uhd/blob/UHD-3.15.LTS/CHANGELOG#L44


Regards,
Nate Temple

On Mon, Jan 27, 2020 at 11:17 AM Nate Temple  wrote:

> Hi Rob,
>
> You should always use a tune request with a timed command when you want to
> align channels.
>
> One thing you could test is to try using the internal LO and see if you
> get different results.
>
> Also you could try using the integer N tuning mode, but I don't think it
> will make any difference for this issue. Checkout this great blog post on
> USRP tuning if you haven't seen it before that covers a few more tips on
> USRP tuning:
> http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html
>
> Regards,
> Nate Temple
>
> On Mon, Jan 27, 2020 at 9:33 AM Rob Kossler  wrote:
>
>> Hi Nate,
>> I changed the subject as to not further hijack the other thread. Of the
>> 16 captures I collected, some of them included a tuning command (but using
>> the same timed commands I use for other devices such as TwinRx). But,
>> others did not.  For example, for the first two data points below (with
>> measured phase difference of -77 and -19 respectively).  I simply issued
>> two consecutive timed streaming commands.  So, I was very perplexed by the
>> results.
>>
>> In any event, I plan to re-take the data today both with and without a
>> DDC.  Hopefully, if I get rid of the DDC, I will see consistent phase
>> results, but we'll see.  Let me know if you have other ideas.
>> Rob
>>
>> On Mon, Jan 27, 2020 at 12:04 PM Nate Temple 
>> wrote:
>>
>>>
>>> @Rob: With the current init process of the N310, yes it is required to
>>> first set the external LO to 5 GHz.
>>>
>>> With regards to the offsets you're seeing, I believe you should only see
>>> a possible phase difference of 180* within the two channels on the same DB.
>>> Are you issuing a tune request at the start of streaming?
>>>
>>> Regards,
>>> Nate Temple
>>>
>>> On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Robert, Sammy,
 I am presently running some tests which compare the X310/TwinRx and the
 N310 with regard to channel-to-channel phase.  In my setup, I have a signal
 source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
 TwinRx and 4 channels of my N310. I have seen some strange behavior of the
 N310 that perhaps Robert has experienced?  Take a look:

- For the TwinRx (for which I am a more experienced user with LO
sharing), I get consistent channel-to-channel phase difference among all
channels. This is true regardless of power cycles, re-starts of UHD, 
 etc.
- For the N310 (for which I am a beginner when it comes to external
LO operation)
   - it seems more complex to run in this mode (as compared to
   TwinRx).  In order to get it to work, I have had to disable startup 
 QEC
   calibration because it seems that the N310 initial cal occurs at 
 2500 MHz
   RF such that I would need to have my external LO at 5000 MHz for 
 startup
   (during the UHD deveice 'make') and then later switch my external LO 
 to the
   desired RF*2. Is this true?
   - when I run with either external LO or internal LO, I see
   inconsistent channel-to-channel phase results even between the two 
 channels
   of a given daughterboard that share the same LO.  I do not 
 understand how
   this is possible.  My results over 16 captures (with some re-starts 
 of UHD,
   device reboots, and switching between internal/external LO) show the
   following channel-to-channel phase difference between channels 0 and 
 1
   which share the same LO: (values in degrees) -77, -19, -77, -19, 
 -77, -19,
   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
 only 3
   unique values and the delta happens to be 58 deg, but I don't know 
 what
   that implies...

 Rob



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

Re: [USRP-users] N310 phase jumps with 1 daughterboard

[Nate Temple via USRP-users]

Hi Rob,

You should always use a tune request with a timed command when you want to
align channels.

One thing you could test is to try using the internal LO and see if you get
different results.

Also you could try using the integer N tuning mode, but I don't think it
will make any difference for this issue. Checkout this great blog post on
USRP tuning if you haven't seen it before that covers a few more tips on
USRP tuning:
http://www.radio-science.net/2017/12/adventures-in-usrp-tuning.html

Regards,
Nate Temple

On Mon, Jan 27, 2020 at 9:33 AM Rob Kossler  wrote:

> Hi Nate,
> I changed the subject as to not further hijack the other thread. Of the 16
> captures I collected, some of them included a tuning command (but using the
> same timed commands I use for other devices such as TwinRx). But, others
> did not.  For example, for the first two data points below (with measured
> phase difference of -77 and -19 respectively).  I simply issued two
> consecutive timed streaming commands.  So, I was very perplexed by the
> results.
>
> In any event, I plan to re-take the data today both with and without a
> DDC.  Hopefully, if I get rid of the DDC, I will see consistent phase
> results, but we'll see.  Let me know if you have other ideas.
> Rob
>
> On Mon, Jan 27, 2020 at 12:04 PM Nate Temple 
> wrote:
>
>>
>> @Rob: With the current init process of the N310, yes it is required to
>> first set the external LO to 5 GHz.
>>
>> With regards to the offsets you're seeing, I believe you should only see
>> a possible phase difference of 180* within the two channels on the same DB.
>> Are you issuing a tune request at the start of streaming?
>>
>> Regards,
>> Nate Temple
>>
>> On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Robert, Sammy,
>>> I am presently running some tests which compare the X310/TwinRx and the
>>> N310 with regard to channel-to-channel phase.  In my setup, I have a signal
>>> source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
>>> TwinRx and 4 channels of my N310. I have seen some strange behavior of the
>>> N310 that perhaps Robert has experienced?  Take a look:
>>>
>>>- For the TwinRx (for which I am a more experienced user with LO
>>>sharing), I get consistent channel-to-channel phase difference among all
>>>channels. This is true regardless of power cycles, re-starts of UHD, etc.
>>>- For the N310 (for which I am a beginner when it comes to external
>>>LO operation)
>>>   - it seems more complex to run in this mode (as compared to
>>>   TwinRx).  In order to get it to work, I have had to disable startup 
>>> QEC
>>>   calibration because it seems that the N310 initial cal occurs at 2500 
>>> MHz
>>>   RF such that I would need to have my external LO at 5000 MHz for 
>>> startup
>>>   (during the UHD deveice 'make') and then later switch my external LO 
>>> to the
>>>   desired RF*2. Is this true?
>>>   - when I run with either external LO or internal LO, I see
>>>   inconsistent channel-to-channel phase results even between the two 
>>> channels
>>>   of a given daughterboard that share the same LO.  I do not understand 
>>> how
>>>   this is possible.  My results over 16 captures (with some re-starts 
>>> of UHD,
>>>   device reboots, and switching between internal/external LO) show the
>>>   following channel-to-channel phase difference between channels 0 and 1
>>>   which share the same LO: (values in degrees) -77, -19, -77, -19, -77, 
>>> -19,
>>>   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
>>> only 3
>>>   unique values and the delta happens to be 58 deg, but I don't know 
>>> what
>>>   that implies...
>>>
>>> Rob
>>>
>>>
>>>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] DOA with N310 or X310+TwinRX

[Nate Temple via USRP-users]

Hi Rob, Robert, Sammy:

Generally for this type of application we would recommend the X310+TwinRx.
With the TwinRX, you'll be able to have repeatable phase offsets with a
given gain, frequency, sample rate and temperature of a device/system. The
N310 will have a 180 degree phase ambiguity due to the /2 LO architecture.

It is possible to share the LO across multiple motherboards for a X310/Twin
setup, and with the NI branded X310+TwinRX setup (NI-2955) the LO's are
provided out of the back panel. The chassis for currently shipping and Rev
C, F, G X310's back plate has the holes for the LO cables, but the sticker
needs to be removed. This application note covers the process:
https://kb.ettus.com/Modifying_an_X310_Chassis_for_External_LO_Sharing

You'll also need to provide a splitter and most likely an inline amplifier
to overcome splitter losses. A splitter such as the ZFRSC-4-842+ will work.
https://www.minicircuits.com/pdfs/ZFRSC-4-842+.pdf


@Rob: With the current init process of the N310, yes it is required to
first set the external LO to 5 GHz.

With regards to the offsets you're seeing, I believe you should only see a
possible phase difference of 180* within the two channels on the same DB.
Are you issuing a tune request at the start of streaming?

Regards,
Nate Temple

On Mon, Jan 27, 2020 at 8:20 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Robert, Sammy,
> I am presently running some tests which compare the X310/TwinRx and the
> N310 with regard to channel-to-channel phase.  In my setup, I have a signal
> source that is split 8 ways (1:8 splitter) to feed the 4 channels of my
> TwinRx and 4 channels of my N310. I have seen some strange behavior of the
> N310 that perhaps Robert has experienced?  Take a look:
>
>- For the TwinRx (for which I am a more experienced user with LO
>sharing), I get consistent channel-to-channel phase difference among all
>channels. This is true regardless of power cycles, re-starts of UHD, etc.
>- For the N310 (for which I am a beginner when it comes to external LO
>operation)
>   - it seems more complex to run in this mode (as compared to
>   TwinRx).  In order to get it to work, I have had to disable startup QEC
>   calibration because it seems that the N310 initial cal occurs at 2500 
> MHz
>   RF such that I would need to have my external LO at 5000 MHz for startup
>   (during the UHD deveice 'make') and then later switch my external LO to 
> the
>   desired RF*2. Is this true?
>   - when I run with either external LO or internal LO, I see
>   inconsistent channel-to-channel phase results even between the two 
> channels
>   of a given daughterboard that share the same LO.  I do not understand 
> how
>   this is possible.  My results over 16 captures (with some re-starts of 
> UHD,
>   device reboots, and switching between internal/external LO) show the
>   following channel-to-channel phase difference between channels 0 and 1
>   which share the same LO: (values in degrees) -77, -19, -77, -19, -77, 
> -19,
>   -19, 39, -19, -19, -77, -19, -77, 39, -19, -19.  Note that there are 
> only 3
>   unique values and the delta happens to be 58 deg, but I don't know what
>   that implies...
>
> Rob
>
>
> On Mon, Jan 27, 2020 at 9:57 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> With external LO its 300 MHz – 4 GHz, check footnote [3] from
>> https://www.ettus.com/all-products/usrp-n310/. LO has to be supplied at
>> twice the carrier freq.
>>
>>
>>
>> Currently we use 4 channels. You can find an example how to do the
>> calibration here: https://github.com/EttusResearch/gr-doa
>>
>> gr-doa was written for TwinRX, but can be adapted.
>>
>>
>>
>> Phase noise behavior of N310 and N320/1 could be different, as N310 uses
>> an RFIC and N32/1 use discrete components. This could be important if you
>> want to operate in the small sample regime.
>>
>>
>>
>>
>>
>> *From:* USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On
>> Behalf Of *Sammy Welschen via USRP-users
>> *Sent:* Monday, January 27, 2020 3:40 PM
>> *To:* usrp-users@lists.ettus.com
>> *Subject:* Re: [USRP-users] DOA with N310 or X310+TwinRX
>>
>>
>>
>> Thank you for the information Robert! Isn't it 6 GHz? However, 4 GHz
>> would also be sufficient for me.
>>
>>
>>
>> How many channels does your system have?  I suppose you use some
>> algorithm for phase calibration after power cycling? I plan to do the same,
>> so the 180 deg ambiguity should be manageable.
>>
>>
>>
>> I looked at the N32x, however, they cost twice as much and I dont't plan
>> on using 200 MHz of bandwidth. If I have an external LO signal I can feed
>> it to the N310, so the only difference between N310 and N32x in this regard
>> would be that I need to generate the LO externally when using the N310,
>> right?
>>
>>
>>
>>  schrieb am Mo., 27. Jan. 2020, 14:42:
>>
>> We use the N310 for DoA estimation, however:
>>
>> - 

Re: [USRP-users] Measuring TDOA for Localization

[Nate Temple via USRP-users]

I meant to include this link with regards to the same rates in my previous
email:
https://files.ettus.com/manual_archive/v3.15.0.0/html/page_general.html#general_sampleratenotes

On Fri, Jan 10, 2020 at 10:40 AM Nate Temple  wrote:

> Hi Richard,
>
> To clarify, are you using a common Octoclock, with the 3 X300's in the
> same location, or separate locations with 3x Octoclocks? Do you have equal
> length cables to the antennas and does the rest of the system match ?
>
> What is your RX frequency ?
>
> What daughterboard are you using?
>
> You may want to try using a decimation factor that will produce an
> non-fractional host sample rate, instead of 200e6/22 = 9090909.09090909_
> MHz. Does running at 10 MS/s sample rate produce any difference in the
> result?
>
>
> Regards,
> Nate Temple
>
> On Thu, Jan 9, 2020 at 4:08 PM Brian Padalino via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On Thu, Jan 9, 2020 at 6:45 PM Richard Bell 
>> wrote:
>>
>>> No I don't need to know phase information. I'm cross correlating the
>>> pairs of receivers and the location of the peak gives me the TDOA. If the
>>> hardware chains across different radios introduce different delays, that
>>> would invalidate the TDOA measurement. So long as the delay is the same
>>> through all the hardware chains, the TDOA estimate will be accurate. Can I
>>> assume the hardware delay through X300 USRPs with the same FPGA image and
>>> set to the same sampling frequency will be the same?
>>>
>>
>> I'd think the group delay should be pretty consistent - at least within
>> 10's of nanoseconds of each other if the setup is identical.
>>
>> What type of variation are you seeing when you perform your cross
>> correlations?  How much variation are you able to handle?
>>
>> Brian
>>
>>> ___
>> 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] Measuring TDOA for Localization

[Nate Temple via USRP-users]

Hi Richard,

To clarify, are you using a common Octoclock, with the 3 X300's in the same
location, or separate locations with 3x Octoclocks? Do you have equal
length cables to the antennas and does the rest of the system match ?

What is your RX frequency ?

What daughterboard are you using?

You may want to try using a decimation factor that will produce an
non-fractional host sample rate, instead of 200e6/22 = 9090909.09090909_
MHz. Does running at 10 MS/s sample rate produce any difference in the
result?


Regards,
Nate Temple

On Thu, Jan 9, 2020 at 4:08 PM Brian Padalino via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On Thu, Jan 9, 2020 at 6:45 PM Richard Bell 
> wrote:
>
>> No I don't need to know phase information. I'm cross correlating the
>> pairs of receivers and the location of the peak gives me the TDOA. If the
>> hardware chains across different radios introduce different delays, that
>> would invalidate the TDOA measurement. So long as the delay is the same
>> through all the hardware chains, the TDOA estimate will be accurate. Can I
>> assume the hardware delay through X300 USRPs with the same FPGA image and
>> set to the same sampling frequency will be the same?
>>
>
> I'd think the group delay should be pretty consistent - at least within
> 10's of nanoseconds of each other if the setup is identical.
>
> What type of variation are you seeing when you perform your cross
> correlations?  How much variation are you able to handle?
>
> Brian
>
>> ___
> 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] IOError: [Errno 2] No such file or directory - uhd_image_builder_gui crashes when trying to run

[Nate Temple via USRP-users]

There was recently a change to the directory structure for the E300/E310s.

If you're running 3.15.0.0, this should be fixed, see the commits from ~Nov
21 here:

https://github.com/EttusResearch/fpga/commits/v3.15.0.0/usrp3

Regards,
Nate Temple

On Fri, Jan 3, 2020 at 11:17 AM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Jerrid,
>
> could you check /home/ck/rfnoc/src/uhd-fpga/usrp3/top/e300/Makefile
> exists?
> My uhd-fpga directory has that; I think yours *should*. Which version
> of the uhd-fpga repo are you using?
>
> Best regards,
> Marcus
>
> On Fri, 2020-01-03 at 15:43 +, Jerrid Plymale via USRP-users wrote:
> > Hey All,
> >
> > So I recently started having issues with the uhd_image_builder_gui
> > after doing a fresh install of UHD and GNU Radio with RFNoC. Below is
> > the output of the terminal when I try to run the gui. Anyone run into
> > this issue and know how to fix it?
> >
> > Traceback (most recent call last):
> >   File "./uhd_image_builder_gui.py", line 656, in 
> > main()
> >   File "./uhd_image_builder_gui.py", line 652, in main
> > _window = MainWindow()
> >   File "./uhd_image_builder_gui.py", line 71, in __init__
> > self.init_gui()
> >   File "./uhd_image_builder_gui.py", line 149, in init_gui
> > self.populate_target('e300')
> >   File "./uhd_image_builder_gui.py", line 608, in populate_target
> > with open(build_targets) as fil:
> > IOError: [Errno 2] No such file or directory:
> > '/home/ck/rfnoc/src/uhd-
> > fpga/usrp3/tools/scripts/../../top/e300/Makefile'
> >
> > Best Regards,
> >
> > Jerrid
> > ___
> > 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] UHD Manual Archive now online

[Nate Temple via USRP-users]

Hi,

Just wanted to send the list a quick note that we have added an archive of
UHD manuals for all previous UHD versions, which can be found here [0].
These can be useful for reference if you're using an older version of UHD,
as the main manual [1] is built off of the master branch.

[0] - https://files.ettus.com/manual_archive/
[1] - https://files.ettus.com/manual/

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

Re: [USRP-users] Does USRP B210 support 2x2 30.72Mhz sampling rate?

[Nate Temple via USRP-users]

Hi Padorin,

Yes the B210 supports 2x2 @ 30.72e6, but is dependent upon your host system
and USB controllers.

You can try using sc12 OTW format which may help:

./benchmark_rate --rx_otw sc12 --tx_otw sc12 ..

Also ensure you've set your CPU governor to performance, and enabled thread
prioirty scheduling as detailed here
https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks

Regards,
Nate Temple

On Thu, Dec 12, 2019 at 7:45 PM Padorin Kurpinsky via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> The USRP B210 spec [1] says it supports  30.72 MHz of instantaneous
> bandwidth. However, If I run benchmark_rate, i.e., sudo ./benchmark_rate
> --rx_rate 30.72e6 --tx_rate 30.72e6 --channels 0,1. Then, it shows a lot of
> U and O. Is this because my host PC is not powerful enough? I'm using
> i7-8750H. Thank you.
>
> [1]
> https://www.ettus.com/wp-content/uploads/2019/01/b200-b210_spec_sheet.pdf
> ___
> 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] transmitting on two channels with replay block

[Nate Temple via USRP-users]

On Wed, Dec 11, 2019 at 9:33 AM Nate Temple  wrote:

> Hi Thomas,
>
> You will need to apply these changes below to the
> fpga-src/usrp3/top/x300/rfnoc_ce_default_inst_x310.v file. This will add
> additional SRAM FIFOs, which is basically what the "XGS" / SRAM image is.
> Make sure to start with the v3.14.1.1 fpga sources. (run git submodule
> init; git submodule update; in your UHD repo after checking out v3.14.1.1).
>
> 
>
> diff --git a/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> b/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> index d20a64962..bcb4c3c32 100644
> --- a/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> +++ b/usrp3/top/x300/rfnoc_ce_default_inst_x310.v
> @@ -1,4 +1,4 @@
> -  localparam NUM_CE = 4;  // Must be no more than 10 (6 ports taken by
> transport and IO connected CEs)
> +  localparam NUM_CE = 6;  // Must be no more than 10 (6 ports taken by
> transport and IO connected CEs)
>
>   wire [NUM_CE*64-1:0] ce_flat_o_tdata, ce_flat_i_tdata;
>   wire [63:0]  ce_o_tdata[0:NUM_CE-1], ce_i_tdata[0:NUM_CE-1];
> @@ -46,7 +46,9 @@
>   genvar n;
>   generate
> for (n = 4; n < NUM_CE; n = n + 1) begin
> -  noc_block_axi_fifo_loopback inst_noc_block_axi_fifo_loopback (
> +  noc_block_axi_fifo_loopback #(
> +.STR_SINK_FIFOSIZE(15)
> +  ) inst_noc_block_axi_fifo_loopback (
> .bus_clk(bus_clk), .bus_rst(bus_rst),
> .ce_clk(ce_clk), .ce_rst(ce_rst),
> .i_tdata(ce_o_tdata[n]), .i_tlast(ce_o_tlast[n]),
> .i_tvalid(ce_o_tvalid[n]), .i_tready(ce_o_tready[n]),
>
> 
>
>
> After making these modifications to the FPGA sources, you can build a FPGA
> image with the commands:
>
> cd fpga-src/usrp3/top/x300/
> source setupenv.sh
> make X310_XG
>
> Note: Even though you are calling X310_XG, it is really a "XGS" image
> since it has the additional SRAM fifos.
>
> After that has completed building, you should write that FPGA image to the
> X310 using uhd_image_loader.
>
> uhd_image_lodaer --args "addr=192.168.40.2,type=x300" --fpga-path
> /path/to/x300.bit
>
> After the FPGA image load and restarting the USRP, run uhd_usrp_probe and
> at the end of the output where the RFNoC blocks are listed, you should see
> two additional FIFO blocks:
>
> FIFO_0
> FIFO_1
>
>
>
>
>
> Random performance tuning notes:
>
> * Ensure your CPU governor is set to performance:
>
> sudo apt install cpufrequtils
>
> To set performance for all cores:
>
> for ((i=0;i<$(nproc);i++)); do sudo cpufreq-set -c $i -r -g performance;
> done
>
>
> Verify with:
>
> cpufreq-info
>
> * Set your network buffers
>
> sudo sysctl -w net.core.rmem_max=62500
> sudo sysctl -w net.core.wmem_max=62500
>
> * Set the MTU to 8000 on your 10Gb NICs
>
> * Ensure you have pthreads enabled for your user
>
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling
>
> http://files.ettus.com/manual/page_general.html#general_threading
>
>
> * Disable hyper threading in bios. This will typically give about a 10%
> boost in core performance if you can work without the additional cores.
> You'll need to update your cpu core list in DPDK.
>
> * Disable KPTI for spectra/meltdown. I would recommend to try disabling
> the KPTI protections for your CPU if the machine is offline, you may see a
> 10-15% performance increase.
>
> This can be done by adding the lines below to your /etc/default/grub at
> GRUB_CMDLINE_LINUX_DEFAULT="", then running sudo update-grub and rebooting.
>
> pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable no_stf_barrier
>
> Note, this disables protections against Meltdown/Spectra (links below). So
> if you try to do this, I would recommend disconnecting that host from any
> internet connected network.
>
> https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
> https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
>
> * There are additional recommendations here from Intel on various
> adjustments you can do to improve performance with DPDK:
> http://doc.dpdk.org/guides/linux_gsg/nic_perf_intel_platform.html
>
> Specifically I would recommend to try section 10.1.3 #3 where you isolate
> the CPU cores that are used for DPDK.
>
> * Here is a performance report from Intel on DPDK 17.11:
> https://fast.dpdk.org/doc/perf/DPDK_17_11_Intel_NIC_performance_report.pdf
>
> In the tables of boot and bio's settings the additional CPU options of
> nohz_full="" and rcu_nocbs="" are added to their kernel configs, this may
> help as well.
>
> Additionally they made the changes listed below:
>
> CPU Power and Performance Policy  (you should already be
> doing this)
> CPU C-state Disabled
> CPU P-state Disabled
> Enhanced Intel® Speedstep® Tech Disabled
> Turbo Boost Disabled
>
>
>
>
> Regards,
> Nate Temple
>
> On Wed, Dec 11, 2019 at 9:18 AM Thomas Harder 
> wrote:
>
>> 

Re: [USRP-users] transmitting on two channels with replay block

[Nate Temple via USRP-users]

Hi Thomas,

One option instead of using the Replay block could be to stream 2x 200e6
from your host.

On the X310, this requires using a SRAM image and DPDK. DPDK support was
added with UHD 3.14.1.0 for the X310, I'd suggest to use 3.14.1.1 at this
time though.

Some links on DPDK:

https://www.dpdk.org/
http://files.ettus.com/manual/page_dpdk.html

I've been able to run 2x2 @ 200e6 with the X310 with DPDK using a 4 GHz CPU.

./benchmark_rate --rx_rate 200e6 --rx_channels 0,1 --tx_rate 200e6
--tx_channels 0,1 --args
"addr=192.168.10.2,second_addr=192.168.20.2,use_dpdk=1,num_recv_frames=512,enable_tx_dual_eth=1,skip_ddc=1,skip_duc=1"

num_recv_frames=512 can help if you're seeing overflows.

enable_tx_dual_eth=1 is required for 2x TX @ 200e6

skip_ddc=1,skip_duc=1 can help as well since you'd be sending at full rate.



Regards,
Nate Temple

On Wed, Dec 11, 2019 at 7:03 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I do not think it is possible using the stock FPGA image.  However, I can
> think of a couple of possibilities:
>
>- On the N310, Ettus includes 4 FIFO blocks (rather than the DmaFIFO
>which used the off-FPGA RAM for memory), to provide capability for 4x125
>MS/s streaming. Perhaps if you built an X310 FPGA image with 2 such FIFO
>blocks, you could use these rather than the DmaFIFO and achieve the desired
>streaming.  Note that this requires a Vivado license to build your own FPGA
>image, but does not require FPGA experience because you would be building
>an image with "stock" blocks.  One caution though is that streaming at this
>very high rate still requires a high performance host and so it is still
>possible that you would have underruns if your host could not keep up.  If
>you go this route, I believe you will likely need to use the "DPDK"
>capability which is a bit of a pain to configure and get it working
>properly.
>- Another possibility is to create a custom RFNoC block that is
>similar to the replay block but that uses FPGA memory to store a fixed
>duration waveform and then plays it out cyclically like the replay block.
>The Ettus 'window' RFNoC block provides a good example of how to store
>coefficients and play them out repeatedly.  But, making the needed
>modifications is not a trivial task except for someone who is pretty good
>at FPGA programming.
>
> Given that you were trying the replay block, I'm guessing that your Tx
> waveforms are of fixed duration.  What is the duration (in number of
> samples) that you require?
> Rob
>
> On Wed, Dec 11, 2019 at 5:05 AM Thomas Harder 
> wrote:
>
>> Thank you Rob for this comment.
>>
>> But I am not sure if I understand you correctly. Do you want to say, that
>> it is *IMPOSSIBLE* to stream TX two different waveforms synchronized  on
>> the 2 channels of the x310 with the full bandwidth of 200MS/s on each
>> channel?
>>
>> That is what I am trying the last 6 months full time, starting with
>> Labview under windows and then UHD under Linux with a Dell Precision 5820
>> desktop (16GB RAM, Intel Xeon W-2125 CPU@ 4.GHz x8) with MXI connection,
>> dual 10Gbit connection(Intel X520-DA2), the replay block recently: always
>> the same result: continuous underruns.
>>
>> If you can confirm that this is not possible without an important FPGA
>> change (because I have no experience in this field and I have not the time
>> to invest into it), I must search for another solution to create two
>> different synchronized RF waveforms with 160MHz bandwidth (optical,
>> electronical,…) because this will be just a part of my experimental setup
>> but it is crucial to go on .
>>
>> I am thankful for any advise,
>>
>> Thomas
>>
>>
>>
>>
>>
>> *From: *Rob Kossler 
>> *Sent: *Tuesday, December 10, 2019 5:01 AM
>> *To: *Thomas Harder 
>> *Cc: *Sam Reiter ; usrp-users@lists.ettus.com
>> *Subject: *Re: [USRP-users] transmitting on two channels with replay
>> block
>>
>>
>>
>> Apart from solving the underrun issue, there is also an issue with
>> synchronization.  The replay block doesn't presently support timed commands.
>>
>>
>>
>> And, as a side note, the issue with streaming from the host is not just
>> the host.  The DMA FIFO has a maximum bandwidth of something like 600 MS/s
>> (combination of all inputs and outputs) that precludes streaming 400 MS/s
>> in and out of the block simultaneously.  So, even if the host could keep
>> up, the FIFO could not.
>>
>> Rob
>>
>>
>>
>> On Mon, Dec 9, 2019 at 4:34 AM Thomas Harder via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Hi Sam,
>>
>> Thank you for your reply.
>>
>> This morning I set the MCR to 184.32 and I am still having continuous
>> underruns using also
>>
>> replay_ctrl->get_record_fullness
>>
>> for both channels.
>>
>>
>>
>> But since I need the full bandwidth of 160MHz I would like implement a
>> second replay block in my fpga image.
>>
>>
>>
>> Could anyone help me with this?
>>
>> I am really new 

Re: [USRP-users] Default RFNoC image for N310 does not compile

[Nate Temple via USRP-users]

Hi Robert,

This patch/line change detailed below should resolve that issue and will be
included in the official 3.15.0.0 release:

---
 usrp3/lib/rfnoc/noc_shell.v | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/usrp3/lib/rfnoc/noc_shell.v b/usrp3/lib/rfnoc/noc_shell.v
index 927f40a70..732d41afa 100644
--- a/usrp3/lib/rfnoc/noc_shell.v
+++ b/usrp3/lib/rfnoc/noc_shell.v
@@ -267,7 +267,7 @@ module noc_shell
   .o_tdata({set_addr_bclk[8*k+7:8*k],
set_data_bclk[32*k+31:32*k]}),
   .o_tvalid(set_stb_bclk[k]), .o_tready(set_stb_bclk[k]));

-   localparam [31:0] STR_SINK_FIFO_SIZE_BYTES =
2**(STR_SINK_FIFOSIZE[8*k+7:8*k]+3);
+   localparam [31:0] STR_SINK_FIFO_SIZE_BYTES = (k < INPUT_PORTS) ?
2**(STR_SINK_FIFOSIZE[8*k+7:8*k]+3) : 0;
// "Lines" is the most useful unit for the command FIFO size, since
// commands take either 2 or 3 lines. Software can do the rest of
the
// math to figure out how many actual command packets it can send.



Regards,
Nate Temple

On Tue, Dec 10, 2019 at 8:46 AM  wrote:

> Hi Nate!
>
>
>
> I followed the guide in
> https://files.ettus.com/manual/md_usrp3_build_instructions.html, thus
> ended up with Vivado 2018.3 and then later found out this requires UHD
> 3.15. Thanks for pointing me to the Vivado bug. I thought with 2018.3.1
> this would be fixed, but apparently that is not the case. Now I went back
> to 2018.3 (clean re-install) and installed the patch AR#71898. The standard
> N310 image compiles fine now.
>
>
>
> The other error
>
> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
> 'STR_SINK_FIFOSIZE'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>
> seems to be happening only for few specific RFNoC blocks (fosphor and
> split_stream, specifically). Leaving these out, the RFNoC image does
> compile. Not sure what exactly is the problem, though. The recent commit
> https://github.com/EttusResearch/fpga/commit/1102779f49d44c9e8b88ce7251d203eb62ae26c9
> did not help (tried both versions, neither of them works).
>
>
>
> Regards
>
> Robert
>
>
>
>
>
> *From:* Nate Temple [mailto:nate.tem...@ettus.com]
> *Sent:* Monday, December 09, 2019 8:43 PM
> *To:* Pöhlmann, Robert
> *Cc:* USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Default RFNoC image for N310 does not compile
>
>
>
> Hi Robert,
>
>
>
> So this is a bug related to Vivado, you will need to install this linked
> below patch and it should resolve it.
>
>
>
> https://www.xilinx.com/support/answers/71898.html
>
>
>
> Regards,
>
> Nate Temple
>
>
>
> On Mon, Dec 9, 2019 at 10:38 AM Nate Temple  wrote:
>
> Hi Robert,
>
> Thanks for the bug report.
>
> If you're just trying to use RFNoC at this point, I would recommend to
> stick with the latest stable release, which at this time is v3.14.1.1.
>
> Note, 3.14.x.x UHD will require Vivado 2017.4.
>
>
> Regards,
> Nate Temple
>
>
>
> On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi all!
>
>
>
> I tried to compile the default RFNoC image for the N310, using UHD on tag
> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>
>
>
> Running "make N310_RFNOC_XG", the IP cores are compiled successfully, but
> then Vivado shows the following errors:
>
>
>
> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
> 'STR_SINK_FIFOSIZE'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-196] conditional expression could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
> ERROR: [Synth 8-6156] failed synthesizing module
> 'noc_shell__parameterized9'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>
>
>
> The full build.log file is attached. I did not modify any files, just
> trying to compile the RFNoC example as provided.
>
>
>
>
>
>
>
> Btw I also tried to build the default image with "make N310_XG", this one
> compiles but failed later during DRC:
>
> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
> For example, 

Re: [USRP-users] Default RFNoC image for N310 does not compile

[Nate Temple via USRP-users]

Hi Robert,

So this is a bug related to Vivado, you will need to install this linked
below patch and it should resolve it.

https://www.xilinx.com/support/answers/71898.html

Regards,
Nate Temple

On Mon, Dec 9, 2019 at 10:38 AM Nate Temple  wrote:

> Hi Robert,
>
> Thanks for the bug report.
>
> If you're just trying to use RFNoC at this point, I would recommend to
> stick with the latest stable release, which at this time is v3.14.1.1.
>
> Note, 3.14.x.x UHD will require Vivado 2017.4.
>
>
> Regards,
> Nate Temple
>
> On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all!
>>
>> I tried to compile the default RFNoC image for the N310, using UHD on tag
>> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>>
>> Running "make N310_RFNOC_XG", the IP cores are compiled successfully,
>> but then Vivado shows the following errors:
>>
>> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
>> 'STR_SINK_FIFOSIZE'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
>> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
>> ERROR: [Synth 8-196] conditional expression could not be resolved to a
>> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
>> WARNING: [Synth 8-693] zero replication count - replication ignored
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
>> ERROR: [Synth 8-6156] failed synthesizing module
>> 'noc_shell__parameterized9'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
>> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
>> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
>> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
>> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
>> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
>> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>>
>> The full build.log file is attached. I did not modify any files, just
>> trying to compile the RFNoC example as provided.
>>
>>
>>
>>
>> Btw I also tried to build the default image with "make N310_XG", this one
>> compiles but failed later during DRC:
>>
>> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
>> For example, the following two ports in this bank have conflicting VCCOs:
>> ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15]
>> (LVCMOS18, requiring VCCO=1.800)
>> [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
>>
>>
>> ___
>> 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] Default RFNoC image for N310 does not compile

[Nate Temple via USRP-users]

Hi Robert,

Thanks for the bug report.

If you're just trying to use RFNoC at this point, I would recommend to
stick with the latest stable release, which at this time is v3.14.1.1.

Note, 3.14.x.x UHD will require Vivado 2017.4.


Regards,
Nate Temple

On Mon, Dec 9, 2019 at 7:33 AM Robert via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all!
>
> I tried to compile the default RFNoC image for the N310, using UHD on tag
> v3.15.0.0-rc2 and Xilinx Vivado 2018.3.1.
>
> Running "make N310_RFNOC_XG", the IP cores are compiled successfully, but
> then Vivado shows the following errors:
>
> ERROR: [Synth 8-524] part-select [15:8] out of range of prefix
> 'STR_SINK_FIFOSIZE'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-521] parameter assignment could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:270]
> ERROR: [Synth 8-196] conditional expression could not be resolved to a
> constant [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:239]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:26]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:27]
> WARNING: [Synth 8-693] zero replication count - replication ignored
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:31]
> ERROR: [Synth 8-6156] failed synthesizing module
> 'noc_shell__parameterized9'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_shell.v:21]
> ERROR: [Synth 8-6156] failed synthesizing module 'noc_block_fosphor'
> [/usr/local/src/uhd/fpga-src/usrp3/lib/rfnoc/noc_block_fosphor.v:8]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx_core'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/n3xx_core.v:17]
> ERROR: [Synth 8-6156] failed synthesizing module 'n3xx'
> [/usr/local/src/uhd/fpga-src/usrp3/top/n3xx/dboards/mg/n3xx.v:13]
>
> The full build.log file is attached. I did not modify any files, just
> trying to compile the RFNoC example as provided.
>
>
>
>
> Btw I also tried to build the default image with "make N310_XG", this one
> compiles but failed later during DRC:
>
> [DRC BIVC-1] Bank IO standard Vcc: Conflicting Vcc voltages in bank 34.
> For example, the following two ports in this bank have conflicting VCCOs:
> ddr3_ck_p[0] (DIFF_SSTL15, requiring VCCO=1.500) and ddr3_addr[15]
> (LVCMOS18, requiring VCCO=1.800)
> [Vivado_Tcl 4-23] Error(s) found during DRC. Placer not run.
>
>
> ___
> 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] Phase relation between RX/TX LO

[Nate Temple via USRP-users]

Hi Luke,

There is an example of setting timed commands in a custom block for the
TwinRX in gr-doa here:

https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L101-L121

You can do this with the standard UHD source/sink blocks, by first making
your flowgraph, then generate the .py in GRC, then open up that .py file
and modify it to add the timed command calls.

If you modify the GRC and regenerate the .py, it'll overwrite your changes.

Regards,
Nate Temple

On Sat, Dec 7, 2019 at 11:35 AM Lukas Haase  wrote:

> Hi Nate,
>
> Thank you so much, this is very useful.
>
> I am using Gnuradio 3.7 on Windows and according to
> uhd_cal_rx_iq_balance.exe for example, UHD version is
> UHD_3.14.1.HEAD-0-g5491b80e. That should have the issue fixed, right?
>
>
> Would you mind to elaborate briefly how to get the "timed command"? (I am
> working with grc for a few weeks and I am fairly new to it)
>
> Just conceptually how to do it would be amazing or a pointer to an example
> that I could modify even better!
>
> For example, I went through the example at
> https://wiki.gnuradio.org/index.php/Guided_Tutorial_GNU_Radio_in_Python#3.1._Intro_to_Using_GNU_Radio_with_Python
> but I do not know if this really creates these "timed commands".
> Yes, I can store the frequency value in a variable but how do I ensure
> that it's updated exactly at a rate of say, 1/100ms?
>
> Also: Why wouldn't such an approach cause issues due to the clock
> differences between the host computer and the USRP?
>
> And if you are able to dig up any more information about the additional
> caveats you were mentioning, that would be truly amazing.
>
> Thanks a lot,
> Luke
>
>
>
>
>
> Gesendet: Samstag, 07. Dezember 2019 um 12:05 Uhr
> Von: "Nate Temple" 
> An: "Lukas Haase" 
> Cc: "USRP-users@lists.ettus.com" 
> Betreff: Re: [USRP-users] Phase relation between RX/TX LO
>
> Hi Luke,
>
> What version of UHD are you using?
>
> There was an issue with the DUC/DDC phase accumulator's resolution, but it
> was fixed with UHD 3.14.1.0.
>
> The threads below are were this was identified:
>
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059914.html
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-April/059465.html
>
> As recommended from the thread:
>
> Phase may change each time streamers are created, but the phase between TX
> and RX should remain consistent during streaming.  Tuning must be done with
> timed commands and a consistent time delta between the tune time of TX and
> RX must be maintained that is greater than 500us to maintain the coherence
> across re-tunes.
>
>
>
> If you're using the QT widget without any modifications, it will not be
> using timed commands, you'll need to generate the python file and manually
> add in the timed commands to the set_freq calls.
>
> Also, if I remember correctly, even with the phase accumulator fix, there
> was some caveats to which frequencies would stay coherent. I need to go
> back and look at some notes on it.
> Regards,
> Nate Temple
>
> On Fri, Dec 6, 2019 at 11:11 PM Lukas Haase via USRP-users <
> usrp-users@lists.ettus.com[mailto:usrp-users@lists.ettus.com]> wrote:Hi
> Marcus,
>
> Marcus wrote:> On 12/06/2019 09:33 PM, Lukas Haase via USRP-users wrote:
> >> Hi,
> >>
> >> I am using the USRP X310+UBX160 with gnuradio to perform very
> >> precicse phase measurements: The TX transmits a CW which is
> >> reflected by an object and received by the RX.
> >>
> >> The received phase provides an accurate estimate of the distance
> >> to>> the reflected object, once the fixed phase relation (between
> >> TX/RX- LO, filters, cables etc.) has been subtracted out.
> >>
> >> This works nicely so far.
> >>
> >> However, I need my system to work across power cycles, and more
> >> importantly, across different frequencies: The goal is to perform
> >> fast frequency hopping and obtain the phase for each frequency.
> >>
> >> Unfortunately it seems that the phase relationship between TX/RX
> >> is>> lost when I tune the USRP to a different center frequency and
> >> back. For example, I have the center frequency set to 900 MHz and
> >> the phase. I measure (by computing the angle of the I/Q samples)
> >> stays constant. But when I set the center frequency to 950 MHz and
> >> then back to 900 MHz, the phase has a random value again.
> >>
> >> Is there any way to avoid this? Or is there any way to lock the LO
> >> phase to a particular phase when>> tuning back to the original
> >> frequency?
> >
> > It *might* be possible to phase-synchroniez the RX and TX LOs using
> > timed commands combined, possibly with INTEGER_N tuning.
> >
> > There's an APP Note on phase-synchronization here:
> >
> >
> https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices[https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices]
>
> Thank you, I'm studying this right now.
>
> > My gut tells me this is going to be hard, though, since the
> > 

Re: [USRP-users] Phase relation between RX/TX LO

[Nate Temple via USRP-users]

Hi Luke,

What version of UHD are you using?

There was an issue with the DUC/DDC phase accumulator's resolution, but it
was fixed with UHD 3.14.1.0.

The threads below are were this was identified:

http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059914.html
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-April/059465.html

As recommended from the thread:

Phase may change each time streamers are created, but the phase between TX
and RX should remain consistent during streaming.  Tuning must be done with
timed commands and a consistent time delta between the tune time of TX and
RX must be maintained that is greater than 500us to maintain the coherence
across re-tunes.



If you're using the QT widget without any modifications, it will not be
using timed commands, you'll need to generate the python file and manually
add in the timed commands to the set_freq calls.

Also, if I remember correctly, even with the phase accumulator fix, there
was some caveats to which frequencies would stay coherent. I need to go
back and look at some notes on it.

Regards,
Nate Temple

On Fri, Dec 6, 2019 at 11:11 PM Lukas Haase via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Marcus,
>
> Marcus wrote:> On 12/06/2019 09:33 PM, Lukas Haase via USRP-users wrote:
> >> Hi,
> >>
> >> I am using the USRP X310+UBX160 with gnuradio to perform very
> >> precicse phase measurements: The TX transmits a CW which is
> >> reflected by an object and received by the RX.
> >>
> >> The received phase provides an accurate estimate of the distance
> >> to>> the reflected object, once the fixed phase relation (between
> >> TX/RX- LO, filters, cables etc.) has been subtracted out.
> >>
> >> This works nicely so far.
> >>
> >> However, I need my system to work across power cycles, and more
> >> importantly, across different frequencies: The goal is to perform
> >> fast frequency hopping and obtain the phase for each frequency.
> >>
> >> Unfortunately it seems that the phase relationship between TX/RX
> >> is>> lost when I tune the USRP to a different center frequency and
> >> back. For example, I have the center frequency set to 900 MHz and
> >> the phase. I measure (by computing the angle of the I/Q samples)
> >> stays constant. But when I set the center frequency to 950 MHz and
> >> then back to 900 MHz, the phase has a random value again.
> >>
> >> Is there any way to avoid this? Or is there any way to lock the LO
> >> phase to a particular phase when>> tuning back to the original
> >> frequency?
> >
> > It *might* be possible to phase-synchroniez the RX and TX LOs using
> > timed commands combined, possibly with INTEGER_N tuning.
> >
> > There's an APP Note on phase-synchronization here:
> >
> >
> https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices
>
> Thank you, I'm studying this right now.
>
> > My gut tells me this is going to be hard, though, since the
> > requirement is to bring a synthesizer back to the same relative phase
> > it had when it was previously tuned to the same frequency.
>
> Yes, this is about multiple devices, certainly hard.
>
> Let's take a step back and I am happy when just the TX/RX LO on a single
> device is synchronized.
>
> This is what I do right now: In gnuradio, I generate a sinudoid (fif=1MHz)
> at baseband and transmit (UHD: USRP Sink) it with fcenter=900MHz.
> Then I receive (UHD: USRP Source) it and multiply it with "-fif" again.
> This gives me a constant signal in I and Q.
>
> The center frequency is configured via "QT GUI Entry". I enter 900e6 and
> press enter. Then I plot "Complex to Arg". As long as I do nothing this
> value is fairly constant (somewhere between -pi and pi).
>
> Now I hit enter again in the QT GUI Entry. Although it's the same center
> frequency, the USRP retunes and the phase jumps to another value.
>
> Now let's look at the USRP block diagram:
>
> https://kb.ettus.com/images/1/16/2920_simplified_system_diagram.gif
>
> Yes, both TX and RX path have a separate PLL and VCO.
> However, the *reference* for this PLL is the same. Hence the PLL should
> lock to the phase of this reference (after all, it's a *phase* locked
> loop). And this implies that the *relative* phase between TX and RX, for a
> given frequency, should be fixed -- at least as long as the USRP is powered.
>
> So, how can it be that this is not the case?!
>
>
> There is just a single suspicion that I have: DSP on gnuradio (host
> computer runs a different clock) versus USRP clock. What do I mean by that?
> Initially I was transmitting a pure CW (in gnuradio, connecting a "Constant
> Source" to USRP Sink and setting the frequency to fcenter+fif). However,
> downconversion was performed with fcenter only and multiplying with fif in
> gnuradio. I could see a slow phase drift. It took me hours to figure out
> that this is caused by the different clocks. The effect was gone once I
> also generated the transmitted waveform in gnuradio.
> In order to fix this, I 

Re: [USRP-users] UHD and FPGA Image mismatch error

[Nate Temple via USRP-users]

Hi Bisma,

You should download the FPGA images for your installed version of UHD (with
uhd_images_downloader) and then write a new FPGA image to the E320 using
the uhd_image_loader utility.

UHD will work on Ubuntu 19.x.

Regards,
Nate Temple

On Wed, Nov 6, 2019 at 2:38 AM Bisma Amjad via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi there,
>
>
> · I have installed GNU Radio using PyBombs from
> http://ecee.colorado.edu/~mathys/ecen4652/SDRsoftware/GNURadioInstall.html
>
>
>
> · UHD was installed from
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>
>
>
> · GNU Radio works fine. I’ve created an FM Radio application on
> it.  USRP E320 is also detected on the system. However, when the flowgraph
> is executed on GNU Radio, following error shows up:
>
>
>
> *RuntimeError: FPGA component ‘noc_shell’ is revision 2 and UHD supports
> revision 3. Please either upgrade the FPGA image (Recommended) or downgrade
> UHD.*
>
> *Troubleshooting:*
>
> ·As indicated by few web sources, Pybombs could’ve created issues during
> GNU Radio installation. So, I re-installed GNU radio and UHD without using
> pybombs (from
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux)
> .
>
>  But the error still persists.
>
>
>
> *RuntimeError: FPGA component ‘noc_shell’ is revision 2 and UHD supports
> revision 6. Please either upgrade the FPGA image (Recommended) or downgrade
> UHD.*
>
>
>
>
>
> ·Moreover, the required installation libraries for UHD are supported for
> Ubuntu version 18.10 or less. Whereas, our system has Ubuntu version 19.0.
> Could this be the possible reason for this issue? Should I downgrade Ubuntu
> to 18.10?
> ___
> 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] X300 underflows with tx_rate 100Msps

[Nate Temple via USRP-users]

Hi Voonna,

What is your CPU frequency?

What kind of NIC are you using?

If your NIC supports DPDK, I would recommend trying to use the DPDK
transport, but you will need to update to UHD 3.14.1.1 to support DPDK with
the X310.


https://files.ettus.com/manual/page_dpdk.html

Regards,
Nate Temple

On Thu, Nov 21, 2019 at 9:35 AM voonna santosh via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Michael,
> I am experiencing lots of underflows when I use benchmark_rate example
> app. Following is the configuration:
>
> Host processor: Intel® Xeon® Processor D-1500 System on Chip (SoC)
> Host OS: Centos 7
> UHD: release_003_010_001_000
> SDR HW: X300 with UBX-160 (Calibration done as documented)
> Eth link: SFP
>  - Maximum socket buffer sizes (wmem_max, rmem_max)
>  - MTU 9000
>  - Tx/Rx descriptors (sudo ethtool -G  tx 4096 rx 4096)
>  - thread priority set to 1
> CPU usage: Only two CPUs are being used, but rest of the cores are free
> and the host is headless(No CPU consuming apps).
>
>   If I test rx_rate with 200Msps, it works well. But when I use tx_rate
> with 100Msps, I could see lots of underflows (Us).
>
> ./benchmark_rate --args="addr=192.168.40.2" --tx_rate=100e6
> --channels="0" --duration 200
> linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-39); Boost_105800;
> UHD_003.010.001.HEAD-0-g929e3b32
>
>
> Creating the usrp device with: addr=192.168.40.2...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 8000 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
> Rev 0.929b
> -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput: 1179.5MB/s)
> -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput: 1184.4MB/s)
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- [RFNoC Radio] Performing register loopback test... pass
> -- Performing timer loopback test... pass
> -- Performing timer loopback test... pass
> Using Device: Single USRP:
>   Device: X-Series Device
>   Mboard 0: X300
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
>   RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: Unknown (0x) - 0
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>   TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: Unknown (0x) - 0
>
> Setting device timestamp to 0...
> Testing transmit rate 100.00 Msps on 1 channels
> U ... Lots of
> underflows
>
> Thanks in advance.
>
> ___
> 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] E310 RFNoC image

[Nate Temple via USRP-users]

Hi Jorn,

The process for installing Xilinx Vivado WebPACK is fairly easy.

Download "Vivado Design Suite - HLx Editions - 2017.4  Full Product
Installation" from here:

https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/vivado-design-tools/archive.html

Decompress the tarball

Run "sudo ./xsetup"

When prompted to download the latest version, ignore and click "Continue",
2017.4 is required.

Click Next, and agree to the EULA and other terms, click Next and keep the
default /opt/Xilinx install prefix.

Click next through the rest of the menus and "install"

You'll now have Vivado installed to /opt/Xilinx/Vivado/2017.4 and can use
it with the build tools as described in the previously linked app note.



Regards,
Nate Temple

On Mon, Nov 11, 2019 at 11:56 PM Skorstad,Jørn via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi list,
>
>
>
> I have followed the application note
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
> to set up a cross compile environment for an E310 SDR. It works well,
> however I have not been able to get past chapter 7: Building a custom RFNoC
> FPGA Image, as I haven’t set up Vivado 2017.4, as required.
>
>
>
> I would like to experiment with RFNoC development also. The application
> note states «A future application note will cover a step-by-step install
> guide for Vivado». Until this application note is ready, is it possible to
> use an image built by someone else using this software version?
> (UHD_3.14.1.HEAD-0-gbfb9c1c7). If so, where could I eventually download it?
> What I need is 1xwindow, 1xFFT, 1xFIFO and 1xFosphor if there is space
> left. Radio and DDC is already on FPGA available as blocks?
>
>
>
> Regards,
>
> Jorn
> ___
> 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] Virtual Machine (VM) Application Note

[Nate Temple via USRP-users]

Hi Jeff,

That application note has not yet been posted. We hope to have it posted
soon. I've removed that section from the existing app note for now.

The main takeaways are that you should expect about half the performance as
running on bare metal when running a VM. If you're running with a B2xx
USRP, you will need to add VID/PID pass through rules.

Regards,
Nate Temple

On Mon, Nov 11, 2019 at 4:19 AM Jeff S via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Application Note AN-445 has a section that references "Using a Virtual
> Machine (VM)" and says that there is another Application Note which
> describes special issues regarding VMs, but does not have a link to it.  I
> did not see anything in the list of application notes which seems to
> match.  Which application note is needed for VMs?
>
> Link used for AN-445:
> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
>
> Link used for Application Notes: https://kb.ettus.com/Application_Notes
>
> Jeff
>
> ___
> 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] Record in disc 4 channels in continuos mode

[Nate Temple via USRP-users]

Hi,

Do you get the same result if you run the included (compiled/default)
version of rx_samples_to_file at a lower sample rate, such as:

/usr/local/lib/uhd/examples/rx_samples_to_file --args "addr=192.168.60.2"
--duration 10 --rate 1e6 --freq 100e6 --gain 10 --subdev "A:0" --file
test.sc16

What version of UHD are you using?

Regards,
Nate Temple

On Mon, Nov 11, 2019 at 9:02 AM Anabel Almodovar 
wrote:

> Dear Nate,
>
> The parameters that I introduce are the following:
>
>
> *//setup the program options*
>
> *po::options_description desc("Allowed options");*
>
> *desc.add_options()*
>
> *("help", "help message")*
>
> *("args",
> po::value()->default_value("addr0=192.168.60.2,second_addr0=192.168.50.2,recv_buff_size=9"),
> "multi uhd device address args")*
>
> *("file",
> po::value()->default_value("/home/rs3lab/Escritorio/Grabaciones"),
> "name of the file to write binary samples to")*
>
> *("type", po::value()->default_value("short"),
> "sample type: double, float, or short")*
>
> *("nsamps", po::value(_num_samps)->default_value(0),
> "total number of samples to receive")*
>
> *("duration", po::value(_time)->default_value(0),
> "total number of seconds to receive")*
>
> *("time", po::value(_time), "(DEPRECATED) will go
> away soon! Use --duration instead")*
>
> *("spb", po::value()->default_value(1), "samples
> per buffer")*
>
> *("rate", po::value()->default_value(25e6), "rate of
> incoming samples")*
>
> *("freq", po::value()->default_value(800e6), "RF
> center frequency in Hz")*
>
> *("gain", po::value()->default_value(80), "gain for
> the RF chain")*
>
> *("ant", po::value(), "antenna selection")*
>
> *("subdev", po::value()->default_value("A:0
> A:1 B:0 B:1"), "subdevice specification")*
>
> *("channel_list",
> po::value(_list)->default_value("0,1,2,3"), "which
> channel to use")*
>
> *("bw", po::value(), "analog frontend filter bandwidth
> in Hz")*
>
> *("ref", po::value()->default_value("external"),
> "reference source (internal, external, mimo)")*
>
> *("wirefmt",
> po::value()->default_value("sc16"), "wire format (sc8,
> sc16 or s16)")*
>
> *("setup", po::value(_time)->default_value(1.0),
> "seconds of setup time")*
>
> *("progress", "periodically display short-term bandwidth")*
>
> *("stats", "show average bandwidth on exit")*
>
> *("sizemap", "track packet size and display breakdown on exit")*
>
> *("null", "run without writing to file")*
>
> *("continue", "don't abort on a bad packet")*
>
> *("skip-lo", "skip checking LO lock status")*
>
> *("int-n", "tune USRP with integer-N tuning")*
>
> *;*
>
>
>
> Then I initialize a vector so I can save the data of the 4 channels:
>
>
> *uhd::rx_metadata_t md;*
>
> *//std::vector buff(samps_per_buff);*
>
> *//std::ofstream outfile;*
>
>
> *//***
>
> *//allocate buffers to receive with samples (one buffer per channel)*
>
> *const size_t samps_per_buff = rx_stream->get_max_num_samps();*
>
> *std::vector > > buffs(*
>
> *usrp->get_rx_num_channels(), std::vector
> >(samps_per_buff)*
>
> *);*
>
>
>
> *//create a vector of pointers to point to each of the channel buffers*
>
> *std::vector *> buff_ptrs;*
>
> *for (size_t i = 0; i < buffs.size(); i++)
> buff_ptrs.push_back([i].front());*
>
>
> *//
>
>
>
> *  //  if (not null)*
>
> *  //  outfile.open(file.c_str(), std::ofstream::binary);*
>
> *bool overflow_message = true;*
>
>
>
> *//setup streaming*
>
> *uhd::stream_cmd_t stream_cmd((num_requested_samples == 0)?*
>
> *uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:*
>
> *uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE*
>
> *);*
>
> *stream_cmd.num_samps = size_t(num_requested_samples);*
>
> *stream_cmd.stream_now = false;*
>
> *//stream_cmd.time_spec = uhd::time_spec_t();*
>
> *stream_cmd.time_spec = usrp->get_time_last_pps(0)+1.1;*
>
> *rx_stream->issue_stream_cmd(stream_cmd);*
>
>
> In addition, once a burst is adquired, the data is save in a file:
>
>
>
> *num_total_samps += num_rx_samps;*
>
>
>
> *for (size_t i=0; i < num_rx_channels; i++)*
>
> *{  *
>
> *std::ostringstream oss;*
>
> *oss << file << "/Grabaciones_CH_"<< i  << buffer <<
> ".dat";*
>
> *std::ofstream oss1;*
>
>
>
> *
> oss1.open(oss.str().c_str(),std::ofstream::app|std::ofstream::binary);*
>
> *  oss1.write((const char*)_ptrs,
> samps_per_buff)*sizeof(std::complex)); *
>
> *   oss1.close();*
>
> *}*
>
>
> Thank you in advanced.
>
>
> Regards,
>
> Anabel
>
> El lun., 11 nov. 2019 a las 16:55, Nate Temple ()
> escribió:
>
>> 

Re: [USRP-users] Record in disc 4 channels in continuos mode

[Nate Temple via USRP-users]

Hi Anabel,

What parameters are you using with the rx_samples_to_file example?

Regards,
Nate Temple

On Mon, Nov 11, 2019 at 3:02 AM Anabel Almodovar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I am trying to make a continuous acquisition with an ettus x310 card whose
> daughter boards are TwinRx. I have used as a base the example
> "rx_samples_to_file.cpp" and I have modified it to be able to acquire
> continuously with the 4 available channels. However, this gives me an
> error and saves a lot of zeros even though I don't get the overflow error. By
> testing the unmodified example I also get those zeros.
>
> Could someone tell me why this happens? How can I solve this error and
> save the acquisition continuously on disk with the 4 channels?
>
> Thank you in advanced.
>
> Regards,
> Anabel
> ___
> 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] Expected FPGA compatibility number mismatch

[Nate Temple via USRP-users]

Hi Adnan,

Sorry for the delay in response, this email fell through the cracks. Is
this still an outstanding issue for you?

Regards,
Nate Temple

On Wed, Sep 11, 2019 at 8:33 AM Quadri,Adnan via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We were working on the Schimdl Cox and OFDM Equalizer blocks.
>
> We updated to the recent version of UHD and did the installation manually.
> There is a rfnoc installation as well, done earlier. (UHD in rfnoc is 4.0
> but the new one is 3.14)
>
> With the newly installed UHD and few changes, we could build FPGA image
> for Schmidl Cox and OFDM Equalizer.
>
> However, when we run the gnuradio flowgraph (which contains blocks
> required to setup a OFDM receiver), we get the following RunTime error -
>
> *RuntimeError: RuntimeError: Expected FPGA compatibility number 36, but
> got 35:*
>
> *The FPGA image on your device is not compatible with this host code
> build. *
>
> *Download the appropriate FPGA images for this version of UHD. *
>
> *Please run: *
>
>
> * "/home/sdr/rfnoc/lib/uhd/utils/uhd_images_downloader.py" *
>
>
> *Then burn a new image to the on-board flash storage of your *
>
> *USRP X3xx device using the image loader utility. Use this command: *
>
>
> *"/home/sdr/rfnoc/bin/uhd_image_loader"
> --args="type=x300,addr=192.168.10.2" *
>
>
> Should I uninstall rfnoc setup. I have already downloaded the images in
> the newly installed UHD directory.
>
> I built the image using uhd_image_builder and image_loader from the newly
> installed UHD directory. For environment setup for the new UHD I used the
> setup_env.sh script from rfnoc folder.
>
>
> Thanks,
> Adnan
> ___
> 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] emergence, help, build uhd with error about dpdk

[Nate Temple via USRP-users]

Hi Jane,

What host OS are you using? What version of DPDK do you have installed?

Can you try using the latest stable release, UHD 3.14.1.1, master can be
unstable.


Regards,
Nate Temple

On Sun, Oct 27, 2019 at 10:24 AM Jane Zhang via USRP-users <
usrp-users@lists.ettus.com> wrote:

> hello, i am a new user with ubuntu and uhd. Later i need to build gnuradio.
> I build uhd(look from changelog, release 3.15). There were errors about
> dpdk as follows.
> Would you please help to solve this problem. I have time to finish this
> task.
> Thank you so much!
>
> dell@dell-XPS-15-9550:~/uhd/host/build$ cmake ../
> --
> -- Configuring the Python interpreter...
> -- Manually determining build Python version...
> -- Python interpreter: /usr/bin/python3.6 Version: 3.6.8
> -- Override with: -DPYTHON_EXECUTABLE=
> -- Manually determining runtime Python version...
> -- Python runtime interpreter: /usr/bin/python3.6 Version: 3.6.8
> -- Override with: -DRUNTIME_PYTHON_EXECUTABLE=
> -- Finding Python Libraries...
> -- Could not find Python Libraries.
> -- Operating on master branch.
> -- Using UHD Images Directory: /usr/local/share/uhd/images
> -- Build type not specified: defaulting to release.
> --
> -- Configuring Boost C++ Libraries...
> -- Looking for optional Boost components...
> -- Found Boost: /usr/include (found suitable version "1.58.0", minimum
> required is "1.58")
> -- Looking for required Boost components...
> -- Found Boost: /usr/include (found suitable version "1.58.0", minimum
> required is "1.58") found components:  chrono date_time filesystem
> program_options regex system unit_test_framework serialization thread
> atomic
> -- Boost include directories: /usr/include
> -- Boost library directories: /usr/lib/x86_64-linux-gnu
> -- Boost libraries:
> /usr/lib/x86_64-linux-gnu/libboost_chrono.so;/usr/lib/x86_64-linux-gnu/libboost_date_time.so;/usr/lib/x86_64-linux-gnu/libboost_filesystem.so;/usr/lib/x86_64-linux-gnu/libboost_program_options.so;/usr/lib/x86_64-linux-gnu/libboost_regex.so;/usr/lib/x86_64-linux-gnu/libboost_system.so;/usr/lib/x86_64-linux-gnu/libboost_unit_test_framework.so;/usr/lib/x86_64-linux-gnu/libboost_serialization.so;/usr/lib/x86_64-linux-gnu/libboost_thread.so;-lpthread;/usr/lib/x86_64-linux-gnu/libboost_atomic.so
> --
> -- Python checking for Python version 2.7 or greater
> -- Python checking for Python version 2.7 or greater - found
> --
> -- Python checking for Mako templates 0.4.2 or greater
> -- Python checking for Mako templates 0.4.2 or greater - found
> --
> -- Python checking for requests 2.0 or greater
> -- Python checking for requests 2.0 or greater - found
> --
> -- Python checking for numpy 1.7 or greater
> -- Python checking for numpy 1.7 or greater - found
> --
> -- Configuring LibUHD support...
> --   Dependency Boost_FOUND = TRUE
> --   Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
> --   Dependency HAVE_PYTHON_MODULE_MAKO = TRUE
> --   Enabling LibUHD support.
> --   Override with -DENABLE_LIBUHD=ON/OFF
> --
> -- Configuring LibUHD - C API support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Enabling LibUHD - C API support.
> --   Override with -DENABLE_C_API=ON/OFF
> --
> -- Configuring LibUHD - Python API support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Dependency HAVE_PYTHON_MODULE_NUMPY = TRUE
> --   Dependency HAVE_PYTHON_LIBS = FALSE
> --   Disabling LibUHD - Python API support.
> --   Override with -DENABLE_PYTHON_API=ON/OFF
> --
> -- Configuring Examples support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Enabling Examples support.
> --   Override with -DENABLE_EXAMPLES=ON/OFF
> --
> -- Configuring Utils support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Enabling Utils support.
> --   Override with -DENABLE_UTILS=ON/OFF
> --
> -- Configuring Tests support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Enabling Tests support.
> --   Override with -DENABLE_TESTS=ON/OFF
> --
> -- Could NOT find LIBERIO (missing: LIBERIO_LIBRARY LIBERIO_INCLUDE_DIR)
> --
> -- Configuring LIBERIO support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Dependency LIBERIO_FOUND = FALSE
> --   Disabling LIBERIO support.
> --   Override with -DENABLE_LIBERIO=ON/OFF
> --
> -- Configuring USB support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Dependency LIBUSB_FOUND = TRUE
> --   Enabling USB support.
> --   Override with -DENABLE_USB=ON/OFF
> --
> -- Configuring B100 support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Dependency ENABLE_USB = ON
> --   Enabling B100 support.
> --   Override with -DENABLE_B100=ON/OFF
> --
> -- Configuring B200 support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Dependency ENABLE_USB = ON
> --   Enabling B200 support.
> --   Override with -DENABLE_B200=ON/OFF
> --
> -- Configuring USRP1 support...
> --   Dependency ENABLE_LIBUHD = ON
> --   Dependency ENABLE_USB = ON
> --   Enabling USRP1 support.
> --   Override with -DENABLE_USRP1=ON/OFF
> --
> -- Configuring USRP2 support...
> --   Dependency ENABLE_LIBUHD = ON
> --   

Re: [USRP-users] X310 and N310: using multiple RF

[Nate Temple via USRP-users]

Hi Rodolphe,

It is only possible to have one application "claim" the USRP at any given
time. So two instances of OAI can not run on the same device.

The max sample rate (using sc16) on 1Gb is ~ 25 MS/s. The max sample rate
(on X310) is 200 MS/s for a 10Gb link. If you have two RF DBs in a single
X310 and want to run at faster than 100 MS/s per card, you need to use both
10Gb interfaces to a single host, however, you're still limited to a single
instance of an application claiming the X310. The N310 has the same in
behavior, for example, if you want to run 4x channels at 61.44 MS/s, you
would need to use both SFP ports as 10Gb links with a single application
claiming it at a time.

Regards,
Nate Temple

On Thu, Oct 24, 2019 at 5:52 AM BERTOLINI Rodolphe via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello USRP-users mailing list,
>
> We are using an X310 for OpenAirInterface (OAI). It has one RF card.
> I wonder the following:
>
>
>- With the following configuration:
>   - USRP X310, HG image, one RF card
>   - host connected to USRP through 1*10Gbps and 1*1Gbps
>- I run OAI on the 10Gbps ethernet interface, and while it is running
>I tried to run an other instance via the 1Gbps ethernet interface. I didn't
>expect it to work, but I didn't expect neither the error message: uhd tells
>me that no USRP was found (I made sure it looks-up through the 1Gbps
>interface).
>   - My interpretation is that once that all of the available RF cards
>   have an established link with the host, USRP closes all of the free
>   interfaces (PCIe, ethernet...)
>   - Thus, if I put an other RF card, and tell the USRP to use only
>   one ethernet interface per RF card, then I would be able to run one OAI
>   instance through an ethernet interface + an RF card, and an other 
> instance
>   through the other ethernet interface + the other RF card. Is it correct?
>   - Now if we consider the N310, its 4 RF cards and its 2 ethernet
>   interfaces: (ignoring limitation from OAI bandwidth requirements) is it
>   possible to run two instances of OAI through a single ethernet 
> interface,
>   so that I could run four instance through two ethernet interfaces?
>   - If all of the above is correct, do you have any idea on how to
>   achieve this?
>
>
> Thank you
> Regards,
> Rodolphe
> ___
> 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] python 2.7 on N310

[Nate Temple via USRP-users]

We are very close to releasing UHD 3.15.x.x which is going to include an
updated file system based on thud  for all of the embedded USRPs (N3xx,
E320, E310). We have also been working on improving the build system and
will have a file system option that includes GNU Radio for all the embedded
devices.

Also with 3.15 RFNoC is on by default with all UHD builds (instead of being
a flag or branch).


On Fri, Oct 25, 2019 at 2:07 PM Philip Balister via USRP-users <
usrp-users@lists.ettus.com> wrote:

> With all the annoying issues on this list with Ettus Embedded products,
> I'm curious if there is any interest in a gofundme for an image that
> supports gnuradio and rfnoc without a bunch of screwing around
> rebuilding uhd and manually updating sdks?
>
> Philip
>
> On 10/21/19 12:36 PM, Jason Matusiak via USRP-users wrote:
> > I am just starting to play with the N310 and I am having issues with
> some of our flowgraphs that work fine with the X310 and the E320.  The
> issue seems to be that there seems to be minimal support for python 2.7 for
> the N310.  Is there a toolchain or anything else I can do to get better
> support?  Things like threading.py are missing and only in python3.5 for it.
> >
> > Thanks.
> > ~Jason
> >
> >
> > ___
> > 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] what's wrong with my n310s?help me, please!

[Nate Temple via USRP-users]

Hi Wangpan,

You had contacted us directly via supp...@ettus.com on this same issue,
let's continue to debug through that channel and when the issue is
resolved, I can update the mailing list with the result.


Regards,
Nate Temple

On Thu, Oct 17, 2019 at 4:55 AM 王盼 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello：
> I got two n310s。I set up them follow the guide in
> http://kb.ettus.com。I can run
> “uhd_find_devices”and“uhd_usrp_probe”correctly。Then I want to test them use
> the uhd/examples。I have seveal problems.
> (1)One n310 can not run 
> "benchmark_rate"and"rx_samples_to_file"correctly.
> I have tyied seveal times, but got diffrent errors,and I dont know what is
> the problem.The file "benchmark_rate.log" is the log when i run "
> benchmark_rate","rx_samples_to_file_first_time.log"is the log of my fist
> time run "rx_samples_to_file","rx_samples_to_file_second_time.log" is the
> second time.
>
> *[WARNING] [CORES] Timer loopback test failed!*
> *[WARNING] [CORES] Expecting clock rate: 122.88 MHz*
> *Approximate clock rate: 0 MHz*
> * is the reason?*
>   (2) The other n310 run "benchmark_rate"and"rx_samples_to_file"correctly,
> but can not run "txrx_loopback_to_file",but I got error:
> *Please run: sudo sysctl -w net.core.wmem_max=625*
> *Checking TX: all_los: unlocked ...*
> *Error: AssertionError: lo_locked.to_bool()*
> *  in int _main(int, char**)*
> *  at /home/workarea-uhd/uhd/host/examples/txrx_loopback_to_file.cpp:471*
>
> the cmd is:
> ./txrx_loopback_to_file \
> --tx-args "type=n3xx,addr=192.168.10.2,master_clock_rate=125e6" \
> --rx-args "type=n3xx,addr=192.168.10.2,master_clock_rate=125e6" \
> --file 73_n310_1_const_short.dat \
> --rx-rate 3.84e6 \
> --tx-rate 3.84e6 \
> --tx-freq 240 \
> --rx-freq 240 \
> --tx-gain 40 \
> --rx-gain 40 \
> --tx-subdev  "A:0"  \
> --rx-subdev  "A:0"  \
> --tx-channels "0" \
> --rx-channels "0"
>
> ./txrx_loopback_to_file \
> --tx-args
> "type=n3xx,mgmt_addr=192.168.10.2,addr=192.168.10.2,master_clock_rate=125e6"
> \
> --rx-args
> "type=n3xx,mgmt_addr=192.168.10.2,addr=192.168.10.2,master_clock_rate=125e6"
> \
> --file 73_n310_4_const_short.dat \
> --rx-rate 125 \
> --tx-rate 125 \
> --tx-freq 240 \
> --rx-freq 240 \
> --tx-gain 40 \
> --rx-gain 40 \
> --tx-bw 100 \
> --rx-bw 100 \
> --tx-subdev  "A:0 A:1 B:0 B:1"  \
> --rx-subdev  "A:0 A:1 B:0 B:1"  \
> --tx-channels "0,1,2,3" \
> --rx-channels "0,1,2,3"
>
> ___
> 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] USRP + SDR#

[Nate Temple via USRP-users]

Hi Carl,

USRP support was added with the r1595 build to SDR#.

You can most likely listen to a trunking system with a single USRP (haven't
tried it myself) as it'll have enough bandwidth to cover both the control
and voice channels.

Regards,
Nate Temple

On Tue, Oct 15, 2019 at 12:18 PM Carl MacGentey via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Might I run an Ettus USRP on a Windows 10 Pro lap top with the software
> package SDR#? Simpleton that I am I would imagine all that’s needed is some
> kind of a dynamic link program like ’Zadig’. Am I right or wrong?  Suppose
> a connection might be accomplished. Would I need two USRP’s to decode
> public safety digital or could I get away with one USRP?
>
>
>
> Thanks for listening-
>
>
>
> Sent from Mail  for
> Windows 10
>
>
> ___
> 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] DPDK setup with N320

[Nate Temple via USRP-users]

Hi Daniel,

The uhd.conf file should be put at /root/.uhd/uhd.conf

You will also need to run the UHD app as root when using DPDK.

I can follow up with you offlist with some additional notes I have on
getting started with DPDK. We will be publishing a detailed app note soon
to cover the topic.

Regards,
Nate Temple

On Tue, Oct 15, 2019 at 11:37 AM Lundberg, Daniel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> My end goal is to use Gnuradio with an N320 to support 250 MS/s
> streaming.  I am posting to the USRP users list first, because I think
> that’s the current area of the problem.  I suspect I have a permissions or
> uhd.conf issue, but the documentation on how to set this up correctly is
> lacking.
>
>
>
> I can stream to the N320 in the “normal” way (without DPDK) via gnuradio
> at rates of 125 MS/s in each direction, so I know that all of the hardware
> and regular uhd and/or gnuradio setup is working.
>
>
>
> I have gone through and tried to set up DPDK to work with the N320 and the
> Ettus connectivity kit (2X SFP+) following this:
> https://files.ettus.com/manual/page_dpdk.html
>
> I can successfully bind the spf+ ports to the vfio-pci using the
> dpdk-devbind.py script.  If I check with dpdk-devbind.py –status after this
> they show up as assigned to the DPDK driver.
>
>
>
> I updated /etc/uhd/uhd.conf as suggested, including the mac addresses, cpu
> assignment, etc…, but I don’t think UHD is finding it correctly.  When I
> try to call uhd (via /usr/local/lib/uhd/examples/benchmark_rate) with a
> use_dpdk=1 argument, I get a number of errors, including:
>
>
>
> [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
>
> [INFO] [MPM.PeriphManager.UDP] No CHDR interfaces found!
>
> [ERROR] [MPMD] No viable transport path found!
>
> [ERROR] [MPMD] Failure during block enumeration: RuntimeError: No viable
> transport path found!
>
> …
>
> …
>
> Error: RuntimeError: Failed to run enumerate_rfnoc_blocks()
>
>
>
> I’ve tried running benchmark_rate as a regular user and via sudo, as well
> as via gnuradio as a regular user.  My gnuradio and UHD were installed from
> source.  Same issues with all approaches.  I see a very similar thread here
> in the 3.14.0.0 release notes and it doesn’t look like these issues were
> resolved within that thread:
>
>
> http://ettus.80997.x6.nabble.com/USRP-users-UHD-Announcing-3-14-0-0-Release-Candidate-1-td11840.html
>
>
>
> Can someone from Ettus chime in?  Do I need to be running UHD and/or
> gnuradio as root, as implied in that thread?  If this requires installing
> things in a manner different from your published “Getting started with the
> N320 guide…” can you please help me understand the steps needed to get DPDK
> working with an N320?
>
>
>
> I am running Ubuntu 18.03.4, UHD is 3.14.0 (specifically
> UHD_3.14.0.HEAD-0-gf6cacec8).
>
>
>
> Thank you,
>
>
>
> DL
>
>
> ___
> 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] Issues Completing Radio Build and Installation

[Nate Temple via USRP-users]

Hi Jon,

If you are following this app note [0], I would recommend starting with the
release-4 image. The pre-3.15 MPM based image that has been released is
currently a "beta" release. It lacks several of the dependencies required
to build out GNU Radio. We are working on a new release and hope to have it
posted soon.

[0] -
https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source


Regards,
Nate Temple

On Fri, Oct 11, 2019 at 10:14 AM Jonathan Lockhart 
wrote:

> Greetings Ettus Radio List,
>
> I have recently acquired and began using an Ettus E312 and have been
> trying to configure the dev host and the cross compile environment.
> Unfortunately I am having issues completing some of these tasks with the
> pre-release version of 3.15 image that Ettus mentions you should use in the
> manual for the E312. I forward those issues to support but have heard no
> reply. Please refer below to the issues I am reporting. The GNURadio cross
> compile issue with the SDK and environment is the more crucial one at the
> moment. I was wondering if anyone else has been experiencing these issues
> and if so how did you proceed to get it resolved. Is there an image, sdk,
> GNURadio version that I should be using other than the 3.15 image and
> instructions that Ettus currently recommends using until a stable RC is
> provided?
>
> Thanks for your help and feedback.
>
> Regards,
> Jon Lockhart
>
>
> -- Forwarded message -
> From: Jonathan Lockhart 
> Date: Mon, Oct 7, 2019 at 3:16 PM
> Subject: Issues Completing Radio Build and Installation
> To: 
>
>
> Greetings Ettus Support,
>
> I recently acquired an Ettus E312 and I was looking to do some development
> on it. Unfortunately I am have been having some issues. The manual via
> files.ettus.com and the "Getting Started" both failed to provide a
> working environment.
>
> The farthest I got was downloading the meta section direction for the E312
> to get 3.15.0 image and sdk for the radio, and then following this guide
> page for 3.14, correcting the UHD install accordingly to comply with 3.15.
> (Guide
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source#Running_RFNoC_Fosphor
> )
>
> When mounting the cross compiled UHD folders via the instructions on the
> radio, and using the uhd_usrp_probe command, there is an error checking for
> the libusb_init information.
>
> root@ni-e31x-313179A:~/newinstall# uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106600;
> UHD_3.15.0.HEAD-0-g6563c537
> [ERROR] [UHD] Device discovery error: AssertionError:
> libusb_init(&_context) == 0
>   in libusb_session_impl::libusb_session_impl()
>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>
> [ERROR] [UHD] Device discovery error: AssertionError:
> libusb_init(&_context) == 0
>   in libusb_session_impl::libusb_session_impl()
>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>
> [ERROR] [UHD] Device discovery error: AssertionError:
> libusb_init(&_context) == 0
>   in libusb_session_impl::libusb_session_impl()
>   at /home/jon/rfnoc/src/uhd/host/lib/transport/libusb1_base.cpp:36
>
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=127.0.0.1,type=e3xx,product=e310_sg3,serial=313179A,claimed=False
> [INFO] [MPM.PeriphManager] Found 1 daughterboard(s).
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=e310_sg3,mgmt_addr=127.0.0.1'.
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003310)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] RX freq = 2.4e+09
> [INFO] [0/Radio_0] RX band = 6
> [INFO] [0/Radio_0] RX SW1 = 5
> [INFO] [0/Radio_0] RX SWC = 0
> [INFO] [0/Radio_0] RX SWB = 1
> [INFO] [0/Radio_0] RX VCRX_SW = 1
> [INFO] [0/Radio_0] RX VCTXRX_SW = 0
> [INFO] [0/Radio_0] 

Re: [USRP-users] N320 Dual SFP issue with 40Gbps QSFP+ switch

[Nate Temple via USRP-users]

Hi David,

Can you try loading the XQ FPGA image onto the N320? When using the XG
image, only the onboard SFP 0,1 adapters are used. When using the XQ image,
two lanes of the QSFP will be used (0,1). A table showing what protocols /
ports per FPGA image can be found here [0].

[0] -
https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_rh_sfp_protocols

Regards,
Nate Temple

On Wed, Oct 9, 2019 at 7:33 AM Truan David via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> We are currently trying to connect the N320 (configured with the XG image)
> to one of our server using the QSFP+ interface through a switch (FS
> S5900-24S4T2Q). The server is equipped with 40Gbps QSFP+ interface and the
> connexion works when connecting directly by QSFP+ without the switch in
> between.
>
> However when connecting it to the switch (to a 40Gbps QSFP+ port) it
> doesn't even detect the connexion (port led light off on the switch) and we
> cannot reach the N320 from the server.
>
> Do you have an idea what could cause the issue?
>
>
> Thank you in advance!
>
>
> David Truan
>
> ___
> 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] E320 unable to lock to external reference

[Nate Temple via USRP-users]

Hi Jason,

Here is the commit that fixes the e320 ext ref issue.

https://github.com/EttusResearch/uhd/commit/6a11a141b8d32d1919e8f9fe95d5c65e95ddd03b

We are aiming to have 3.14.1.1 tagged and released next week which will
include this commit.

Regards,
Nate Temple


On Tue, Aug 6, 2019, 11:51 AM Jason Matusiak 
wrote:

> Thanks for the update Michael, I'll pass it along.  Fingers crossed.
>
> --
> *From:* Michael West 
> *Sent:* Monday, August 5, 2019 4:49 PM
> *To:* Nate Temple 
> *Cc:* Jason Matusiak ; Ettus Mail List <
> usrp-users@lists.ettus.com>
> *Subject:* Re: [USRP-users] E320 unable to lock to external reference
>
> We have someone looking into this now.  In the meantime, try adding the
> device arguments "clock_source=external,time_source=external".
>
> Regards,
> Michael
>
> On Tue, Jul 23, 2019 at 12:23 PM Nate Temple via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Hi Jason,
>
> I'm fairly confident that this is just a software issue.
>
> Regards,
> Nate Temple
>
> On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
> Thank you Nate.  Good to hear that it wasn't a screw up on our part.  Do
> you have a gut as to whether or not it is a hardware or software issue?
>
>
> --
> *From:* Nate Temple 
> *Sent:* Tuesday, July 23, 2019 2:01 PM
> *To:* Jason Matusiak 
> *Cc:* Ettus Mail List 
> *Subject:* Re: [USRP-users] E320 unable to lock to external reference
>
> Hi Jason,
>
> I've been able to recreate this and have filed an issue on our internal
> bug tracker and escalated as a high priority issue. I'm not able to provide
> any ETA on when we will have a fix for it, but hope it will be soon.
>
> I will follow up as soon as I have more information.
>
> Regards,
> Nate Temple
>
> On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
> Do you need anything from my side of things?
>
> --
> *From:* Nate Temple 
> *Sent:* Thursday, July 18, 2019 3:49 PM
> *To:* Jason Matusiak 
> *Cc:* Ettus Mail List 
> *Subject:* Re: [USRP-users] E320 unable to lock to external reference
>
> Hi Jason,
>
> This might be a bug with the E320. I will need to try to recreate this
> issue. I'll follow up as soon as I have more info.
>
> Regards,
> Nate Temple
>
> On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> OK, we've been fighting this for a while and we think we narrowed it down
> to being a problem with the E320 (NOTE: we are running the E320 in network
> mode, not embedded)
>
> Some background:
> 1) external reference input is from an octo clock (so it the 1pps input)
> on many different ports
> a) also tried to use a  Symmetricom box for external reference and
> had the same problems
>
> 3) the same code we are testing with works when using an x310 instead of
> an e320, with inputs from the same octoclock
>
> 4) the code basically does this:
> a) sets the reference source to external
> b) checks to see if the reference is locked (and it keeps doing
> this until we get a "locked" response, using the uhd commands to do this)
>
> 5) for the e320, the locked status never returns (when running the x310
> with this code, it sometimes responds with unlocked, but after a few checks
> it comes back ok)
>
> 6) I tried some of the Ettus (UHD) test code
> a) running the "sync_to_gps" program did work - the reference was
> able to lock to the internal (gps) reference
> b) "test_clock_synch"  returns similiar errors to what we get with
> our program (see below):
> Checking USRP devices for lock.
>  * 318B08B: false
> WARNING: One or more devices not locked.
> Querying Clock for time and setting USRP times...
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> Running 10 comparisons at random intervals.
> Comparison #1
>  * Clock time: 1563463644
>  * 318B08B time: 1563463644
> Comparison #2
>  * Clock time: 1563463652
>  * 318B08B time: 1563463652
> Comparison #3
>  * Clock time: 1563463657
>  * 318B08B time: 1563463657
> Comparison #4
>  * Clock time: 1563463664
>  * 318B08B time: 1563463664
> Comparison #5
>  * Clock time: 1563463666
>  * 318B08B time: 1563463666
> Comparison #6
>  * Clock time: 1563463671
>  * 318B08B time: 1563463671
> Comparison #7
>  * Clock time: 1563463676
>  * 318B08B time: 1563463676
> Comparison #8
>  * Clock time: 156346368

Re: [USRP-users] Error running 1024 pt FFT block on N310

[Nate Temple via USRP-users]

Hi Rob,

The N3xx (and E3xx) only support having an FFT size up to 512 due to the
page size. It'd be possible to modify the blocks to break up the FFT over
several packets but it is not currently implemented. The X310 as is
supports up to a 1024 point FFT.

Regards,
Nate Temple

On Mon, Sep 9, 2019 at 12:35 PM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
> I am having trouble running the FFT block of size 1024 on an N310.  I am
> using the "rfnoc_rx_to_file" example program (UHD v3.14.1.0) to run it.  It
> works with size 256 or 512.  Additionally, I am able to run with 1024 if I
> switch to an X310 (same PC). Please let me know if you have any ideas...
> Rob
>
> *Here is the command that fails:*
>
> rfnoc_rx_to_file --args="type=n3xx" --nsamps=65536 --block-id=FFT_0
> --block-args="spp=1024" --rate=125e6 --freq=2400e6 --radio-args="spp=1024"
>
> *The following is the output with error message:*
>
> Using radio 0, channel 0
> Setting RX Rate: 125.00 Msps...
> Actual RX Rate: 125.00 Msps...
>
> Setting RX Freq: 2400.00 MHz...
> Actual RX Freq: 2400.00 MHz...
>
> Connecting 0/Radio_0 ==> 0/FFT_0
> [WARNING] [RFNOC] Assuming max packet size for 0/Radio_0
> Samples per packet: 1024
> Using streamer args: block_id=0/FFT_0,spp=1024
> Issuing stream cmd
> [ERROR] [RX FLOW CTRL] Error unpacking packet: ValueError: Bad CHDR or
> packet fragment
>
> [ERROR] [STREAMER] The receive packet handler caught a value exception.
> ValueError: Bad CHDR or packet fragment
> Error: Receiver error: ERROR_CODE_BAD_PACKET
>
> *Note that the following works fine with an X310*
>
> rfnoc_rx_to_file --args="type=x300" --nsamps=65536 --block-id=FFT_0
> --block-args="spp=1024" --rate=100e6 --freq=2400e6
>
> ___
> 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] Processor requirements for full-rate streaming on N320

[Nate Temple via USRP-users]

Hi  Daniel,

As Marcus mentioned, an i3 is not ideal for streaming at such high rates.

For 200 MS/s of usable bandwidth, you'll need to stream at 250 MS/s per
channel.

A colleague has ran 2x2 @ 250 MS/s using an Intel Xeon E5-1620 v3 @
3.50GHz, and I've ran at those rates with an i9-9900x @ 4.4 GHz.

Generally speaking, you'll want to have a CPU with a clock freq of 3.5 GHz
or higher with as many cores as possible, ideally 4.0+ GHz.

To stream at 250 MS/s you'll need to use DPDK. The Mellanox MCX4121A-ACAT
NIC is a good option as you do not need to use the vfio-pci driver with it
for DPDK.


Regards,
Nate Temple

On Fri, Sep 6, 2019 at 3:24 PM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Daniel,
>
> i3 doesn't sound like the processor family of choice here; a few more
> cores can't hurt. Basically, assume one CPU core per stream for the
> wire- to CPU-format conversion, plus a bit of demand for someone
> handling OS/network card interrupts.
> What're you doing with the samples afterwards?
>
> Best regards,
> Marcus
>
> On Fri, 2019-09-06 at 21:53 +, Lundberg, Daniel via USRP-users
> wrote:
> > Does anyone have a known good hardware configuration to support full
> > (or at least close to full) 200 MS/s streaming from the N320?
> > Preferably with 1 Tx and 2 Rx channels.
> > As a data point, a recent i3 (4 cores) seems to be choking above 62.5
> > MS/s.  This is over dual SFP+ ports.  At higher sampling rates, it is
> > producing U’s, which I interpret to mean that the cpu can’t shovel
> > samples into the radio fast enough, not that there is a network jam.
> >
> > Thank you,
> > DL
> > ___
> > 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] N320: set_rx_bw() does not change the actual BW

[Nate Temple via USRP-users]

Hi David,

The N320 has a discrete component daughterboard and does not support
setting a bandwidth filter.

The RFIC based USRPs such as the B2xx, E31x, E320 (AD9361) and N300/N310
(AD9371) support the set_rx_bandwidth API call.

Regards,
Nate Temple

On Fri, Sep 6, 2019 at 4:55 AM Truan David via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> We received our N320 and started doing some basic RX tests on it and
> everything seems ok. We were able to get an emitted chirp and display it
> using GQRX.
>
> However, when calling the set_rx_bandwidth() UHD function and then reading
> the actual RX bandwidth, it always read back 250MHz. Using
> rx_samples_to_file example and with a --bw=1e6 parameter, I obtain the
> output:
>
> 
>
> Setting RX Bandwidth: 1.00 MHz...
>
> Actual RX Bandwidth: 250.00 MHz...
>
> 
>
> Is this normal or a bug? If it is a bug, does this have an impact on the
> acquisition, if yes what is this impact?
>
> We tested both the HG and the XQ FPGA bitstreams and we use UHD 3.14.0.0
> on both the N320 and the host, obtaining the same behavior in all cases.
>
>
> Thank you in advance for your answer!
>
> David T.
>
> ___
> 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] N200: Sequence error at low sampling rate

[Nate Temple via USRP-users]

Hi Emanuel,

What ethernet controller is installed on your NUC?

lspci | grep Ethernet


Can you try rebooting the NUC, and then run a benchmark to trigger the
sequence errors, after that run:

ethtool -S 

and send its output.

Regards,
Nate Temple

On Tue, Sep 3, 2019 at 1:35 AM Emanuel via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everybody,
>
> I experience a weird behavior while streaming from my N200 at low sampling
> rates.
> The setup is as follows: USRP N200 with latest FPGA image, UHD Version
> 3.14.1.0, Host computer is a Intel NUC Hades Canyon with Ubuntu 18.04 LTS
> and CPU governor set to performance. The USRP is directly connected to the
> NUC (no switch in between)
>
> If I use the benchmark program at 1 MHz sampling rate, I get multiple
> sequence errors, see one example log at the end of this Mail. It does not
> seem to correlate with the MTU size: I tried smaller ones and in same cases
> a smaller MTU size (about 1000) seems to decrease the number of sequence
> errors a bit. The overall CPU load is pretty small. I also experience the
> same troubles if I simply stream into a null-sink or any other block in
> Gnuradio.
>
> If I use a sampling rate of 20MHz or 25MHz I do not get any sequence
> errors. And that's what puzzles me: Does anyone have an idea why it works
> worse at low sampling rates?
>
> In the manual I found the entry about the ups_per_fifo and ups_per_sec for
> the N200 series. However, I did not find more information on that: Would
> changing those settings help, and if so, in which direction should I change
> those parameters?
>
> Best regards,
> Emanuel
>
> xx@xx:/usr/local/lib/uhd/examples$ ./benchmark_rate --duration 600
> --rx_subdev A:A --rx_rate 1e6 --args "addr=192.168.21.2"
>
> [INFO] [UHD] linux; GNU C++ version 8.3.0; Boost_106501;
> UHD_3.14.1.HEAD-0-gbfb9c1c7
> [00:00:00.01] Creating the usrp device with: addr=192.168.21.2...
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [INFO] [USRP2] Detecting internal GPSDO
> [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev
> 0.929
> [INFO] [USRP2] Setting references to the internal GPSDO
> Using Device: Single USRP:
>   Device: USRP2 / N-Series Device
>   Mboard 0: N200r4
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: BasicRX (A)
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: Unknown (0x) - 0
>
> [00:00:02.491478] Setting device timestamp to 0...
> [00:00:02.491698] Testing receive rate 1.00 Msps on 1 channels
> [D00:01:03.889970] Detected Rx sequence error.
> [D00:01:28.796795] Detected Rx sequence error.
> [D00:01:32.880153] Detected Rx sequence error.
> [D00:02:34.087632] Detected Rx sequence error.
> [D00:05:13.241379] Detected Rx sequence error.
> [D00:06:13.370751] Detected Rx sequence error.
> [D00:07:05.771504] Detected Rx sequence error.
> [D00:07:12.235087] Detected Rx sequence error.
> [D00:08:25.865832] Detected Rx sequence error.
> [D00:09:18.883324] Detected Rx sequence error.
> [00:10:02.491954] Benchmark complete.
>
>
> Benchmark rate summary:
>   Num received samples: 57347
>   Num dropped samples:  3630
>   Num overruns detected:0
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 10
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
>
> Done!
>
>
>
> ___
> 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] latest E310 tutorial

[Nate Temple via USRP-users]

Hi,

We've pushed updated flowgraphs into gr-ettus for the networked fosphor
example to fix the FIFO select and QT display issues. There is a few more
minor things fixed in them but can you please give them and try on your
system? I will try to replicate the siggen issue you ran into.


Regards,
Nate Temple

On Sun, Aug 11, 2019 at 1:38 PM d.des via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Thanks, Royce, that fixed the usrp side of both fosphor and my block!
>
> I also made two minor tweaks to the host side to get fosphor working on
> my PC. These are probably things that a Gnuradio expert would see right
> away but in case there's anyone else out there who primarily uses the
> c++ uhd interface and is barely Gnuradio literate here goes:
>
> The first problem was a segfault whenever the host side program
> rfnoc_siggen_network_host.py was launched. That turned out to be a
> problem with fosphor_display_impl.cc. The method
> "bool fosphor_display_impl::start()" ended without returning anything
> and my Fedora 30 machine really hated that. I put in a "return true"
> line at the end of the function and that fixed the problem. (It doesn't
> seem to matter whether the function returns true or false, it just
> needs to return something.)
>
> The second issue with the examples in stock form was that when I opened
> rfnoc_fosphor_network_host at first all I saw were controls, no plot. I
> spent some time looking for QT issues but it turned out to be really
> simple: there were GUI hints set on the slider controls but not on on
> the fosphor display block. The quickest fix is to remove the hints on
> the controls and the display shows up.
>
> Fosphor is a really nice quick survey tool. It's great to see 56 MHz at
> once with just a laptop and battery-powered E310.
>
>
> ___
> 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] USRP utility for spectrum analysis

[Nate Temple via USRP-users]

Hi Mauricio,

You could modify the rx_ascii_art_drf util if you wanted, the source is
here[0]. There is also the Python  version here[1]. There is also a GNU
radio OOT, gr-specest that I would recommend to checkout [2]. I would also
encourage you to look at the rx_tool utility which can be found here[3].

[0] -
https://github.com/EttusResearch/uhd/blob/master/host/examples/rx_ascii_art_dft.cpp
[1] -
https://github.com/EttusResearch/uhd/blob/master/host/examples/python/curses_fft.py
[2] - https://github.com/kit-cel/gr-specest
[3] - https://github.com/rxseger/rx_tools

Regards,
Nate Temple

On Mon, Aug 12, 2019 at 10:11 AM Mauricio via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> I recently started using USRP for spectrum analysis and the
> rx_ascii_art_dft utility is very useful for that. I wonder if there is
> an easy way to output the (freq, dB) values to a text file? Or another
> simple program that can do that?
>
> Thank you,
>
> Mauricio
>
> ___
> 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] cmake error : Cross-Compiling GNU Radio on Ubuntu 16.04

[Nate Temple via USRP-users]

Hi,

I hope to have the E310 version posted tomorrow. Don't have a firm timeline
for the E320/N3xx version yet.

The process is mostly the same, except you should not use rfnoc-devel, but
instead use a modern UHD version such as v3.14.1.0, and then during the
cmake configuration step, pass the arg -DENABLE_RFNOC=ON.

You can fetch the E320 SDK using uhd_images_downloader with the command
(with UHD 3.14.1.0 on your host):

uhd_images_downloader -t sdk -t e320

I would recommend to use maint-3.7 for the GR version with the E320.


Regards,
Nate Temple

On Thu, Aug 1, 2019 at 7:53 PM 福島幹雄  wrote:

> Hi Nate
> Thank you for always your support and quick reply.
>
> >Are you using the E320 SDK?
> No, I use the *E310 SDK*.
> bacause I am training to get used to build the UHD and GR for cross
> compiling environment.
> next step, I will use the *E320 SDK*.
>
> >Also that app note is outdated, and I will be posted an updated version
> soon. Another app note that covers the E320/N3xx will follow.
>
> Oh!!!
> I have no words to thank you.
> When do you think that will be?
>
> Thanks.
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] cmake error : Cross-Compiling GNU Radio on Ubuntu 16.04

[Nate Temple via USRP-users]

Hi,

That application note is specific to the E310. Are you using the E320 SDK?
Did you source the OE environment setup file? (What is the output of echo
$CC)?

Also that app note is outdated, and I will be posted an updated version
soon. Another app note that covers the E320/N3xx will follow.

Regards,
Nate Temple

On Thu, Aug 1, 2019 at 7:26 PM 福島幹雄 via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone.
> I try to compile the UHD and GNU Radio for my E320 on Ubuntu 16.04, I am
> referencing this application note.
>
>
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>
> but I got error message from cmake as follows.
> Do you know this solution?
>
> **Cross-Compiling GNU Radio**
> $ cd ~/e300/src
> $ git clone -b v3.7.10.2 --recursive
> https://github.com/gnuradio/gnuradio.git
> $ cd gnuradio/
> $ mkdir build
> $ cd build
> $ cmake -Wno-dev
> -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchains/oe-sdk_cross.cmake
> -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF -DENABLE_GR_DTV=OFF
> -DENABLE_GR_ATSC=OFF -DENABLE_DOXYGEN=OFF -DCMAKE_INSTALL_PREFIX=/usr ../
>
> CMake Error at cmake/Toolchains/oe-sdk_cross.cmake:4 (string):
>   string sub-command REGEX, mode MATCH needs at least 5 arguments total to
>   command.
> Call Stack (most recent call first):
>   build/CMakeFiles/3.5.1/CMakeSystem.cmake:6 (include)
>   CMakeLists.txt:31 (project)
>
> **snip**
>
>  CMake will not be able to correctly generate this project.
> Call Stack (most recent call first):
>  CMakeLists.txt:31 (project)
>
>
> -- Configuring incomplete, errors occurred!
> See also
> "/home/dolphin/e300/src/gnuradio/build/CMakeFiles/CMakeOutput.log".
> See also "/home/dolphin/e300/src/gnuradio/build/CMakeFiles/CMakeError.log".
>
>
> ___
> 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] E320 unable to lock to external reference

[Nate Temple via USRP-users]

Hi Jason,

I'm fairly confident that this is just a software issue.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 11:06 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Thank you Nate.  Good to hear that it wasn't a screw up on our part.  Do
> you have a gut as to whether or not it is a hardware or software issue?
>
>
> --
> *From:* Nate Temple 
> *Sent:* Tuesday, July 23, 2019 2:01 PM
> *To:* Jason Matusiak 
> *Cc:* Ettus Mail List 
> *Subject:* Re: [USRP-users] E320 unable to lock to external reference
>
> Hi Jason,
>
> I've been able to recreate this and have filed an issue on our internal
> bug tracker and escalated as a high priority issue. I'm not able to provide
> any ETA on when we will have a fix for it, but hope it will be soon.
>
> I will follow up as soon as I have more information.
>
> Regards,
> Nate Temple
>
> On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
> Do you need anything from my side of things?
>
> --
> *From:* Nate Temple 
> *Sent:* Thursday, July 18, 2019 3:49 PM
> *To:* Jason Matusiak 
> *Cc:* Ettus Mail List 
> *Subject:* Re: [USRP-users] E320 unable to lock to external reference
>
> Hi Jason,
>
> This might be a bug with the E320. I will need to try to recreate this
> issue. I'll follow up as soon as I have more info.
>
> Regards,
> Nate Temple
>
> On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> OK, we've been fighting this for a while and we think we narrowed it down
> to being a problem with the E320 (NOTE: we are running the E320 in network
> mode, not embedded)
>
> Some background:
> 1) external reference input is from an octo clock (so it the 1pps input)
> on many different ports
> a) also tried to use a  Symmetricom box for external reference and
> had the same problems
>
> 3) the same code we are testing with works when using an x310 instead of
> an e320, with inputs from the same octoclock
>
> 4) the code basically does this:
> a) sets the reference source to external
> b) checks to see if the reference is locked (and it keeps doing
> this until we get a "locked" response, using the uhd commands to do this)
>
> 5) for the e320, the locked status never returns (when running the x310
> with this code, it sometimes responds with unlocked, but after a few checks
> it comes back ok)
>
> 6) I tried some of the Ettus (UHD) test code
> a) running the "sync_to_gps" program did work - the reference was
> able to lock to the internal (gps) reference
> b) "test_clock_synch"  returns similiar errors to what we get with
> our program (see below):
> Checking USRP devices for lock.
>  * 318B08B: false
> WARNING: One or more devices not locked.
> Querying Clock for time and setting USRP times...
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> Running 10 comparisons at random intervals.
> Comparison #1
>  * Clock time: 1563463644
>  * 318B08B time: 1563463644
> Comparison #2
>  * Clock time: 1563463652
>  * 318B08B time: 1563463652
> Comparison #3
>  * Clock time: 1563463657
>  * 318B08B time: 1563463657
> Comparison #4
>  * Clock time: 1563463664
>  * 318B08B time: 1563463664
> Comparison #5
>  * Clock time: 1563463666
>  * 318B08B time: 1563463666
> Comparison #6
>  * Clock time: 1563463671
>  * 318B08B time: 1563463671
> Comparison #7
>  * Clock time: 1563463676
>  * 318B08B time: 1563463676
> Comparison #8
>  * Clock time: 1563463686
>  * 318B08B time: 1563463686
> Comparison #9
>  * Clock time: 1563463689
>  * 318B08B time: 1563463689
> Comparison #10
>  * Clock time: 1563463691
>  * 318B08B time: 1563463691
>
> Number of matches: 10/10
>
>
> 7) we ran the same tests at a sister site that has four E320s, and they
> all exhibited the same issues
>
> 8)Finally, a uhd_usrp_probe command returns this:
>
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
> Boost_105300; UHD_3.14.1.0-9-g2aa5289d
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> ... many of these warnings repeating ...
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> [WARNING] [MPM.RPCServer] A timeout event occured!
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=e320,mgmt_addr=192.168.10.3'.
> [INFO] [0/DUC_0] 

Re: [USRP-users] E320 unable to lock to external reference

[Nate Temple via USRP-users]

Hi Jason,

I've been able to recreate this and have filed an issue on our internal bug
tracker and escalated as a high priority issue. I'm not able to provide any
ETA on when we will have a fix for it, but hope it will be soon.

I will follow up as soon as I have more information.

Regards,
Nate Temple

On Tue, Jul 23, 2019 at 10:12 AM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> Do you need anything from my side of things?
>
> --
> *From:* Nate Temple 
> *Sent:* Thursday, July 18, 2019 3:49 PM
> *To:* Jason Matusiak 
> *Cc:* Ettus Mail List 
> *Subject:* Re: [USRP-users] E320 unable to lock to external reference
>
> Hi Jason,
>
> This might be a bug with the E320. I will need to try to recreate this
> issue. I'll follow up as soon as I have more info.
>
> Regards,
> Nate Temple
>
> On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> OK, we've been fighting this for a while and we think we narrowed it down
> to being a problem with the E320 (NOTE: we are running the E320 in network
> mode, not embedded)
>
> Some background:
> 1) external reference input is from an octo clock (so it the 1pps input)
> on many different ports
> a) also tried to use a  Symmetricom box for external reference and
> had the same problems
>
> 3) the same code we are testing with works when using an x310 instead of
> an e320, with inputs from the same octoclock
>
> 4) the code basically does this:
> a) sets the reference source to external
> b) checks to see if the reference is locked (and it keeps doing
> this until we get a "locked" response, using the uhd commands to do this)
>
> 5) for the e320, the locked status never returns (when running the x310
> with this code, it sometimes responds with unlocked, but after a few checks
> it comes back ok)
>
> 6) I tried some of the Ettus (UHD) test code
> a) running the "sync_to_gps" program did work - the reference was
> able to lock to the internal (gps) reference
> b) "test_clock_synch"  returns similiar errors to what we get with
> our program (see below):
> Checking USRP devices for lock.
>  * 318B08B: false
> WARNING: One or more devices not locked.
> Querying Clock for time and setting USRP times...
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> Running 10 comparisons at random intervals.
> Comparison #1
>  * Clock time: 1563463644
>  * 318B08B time: 1563463644
> Comparison #2
>  * Clock time: 1563463652
>  * 318B08B time: 1563463652
> Comparison #3
>  * Clock time: 1563463657
>  * 318B08B time: 1563463657
> Comparison #4
>  * Clock time: 1563463664
>  * 318B08B time: 1563463664
> Comparison #5
>  * Clock time: 1563463666
>  * 318B08B time: 1563463666
> Comparison #6
>  * Clock time: 1563463671
>  * 318B08B time: 1563463671
> Comparison #7
>  * Clock time: 1563463676
>  * 318B08B time: 1563463676
> Comparison #8
>  * Clock time: 1563463686
>  * 318B08B time: 1563463686
> Comparison #9
>  * Clock time: 1563463689
>  * 318B08B time: 1563463689
> Comparison #10
>  * Clock time: 1563463691
>  * 318B08B time: 1563463691
>
> Number of matches: 10/10
>
>
> 7) we ran the same tests at a sister site that has four E320s, and they
> all exhibited the same issues
>
> 8)Finally, a uhd_usrp_probe command returns this:
>
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
> Boost_105300; UHD_3.14.1.0-9-g2aa5289d
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> ... many of these warnings repeating ...
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> [WARNING] [MPM.RPCServer] A timeout event occured!
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=e320,mgmt_addr=192.168.10.3'.
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
>   _
>  /
> |   Device: E300-Series Device
> | _
> |/
> |   |   Mboard: ni-e320-318B08B
> |   |   eeprom_version: 2
> |   |   mpm_version: 3.14.0.0-g6875d061
> |   |   pid: 58144
> |   |   

Re: [USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

[Nate Temple via USRP-users]

Hi Taylor,

The behavior of UHD selecting the antenna port for the LF/Basic boards
changed a few releases ago on the X3xx. Instead of setting a subdev spec,
you use the antenna port with the name.

https://files.ettus.com/manual/page_dboards.html#dboards_basicrx

Within the UHD Source/Sink blocks you should not select "TX/RX", "RX2",
"RX1", but instead type "A" or "B" or "AB"



Regards,
Nate Temple

On Thu, Jul 18, 2019 at 5:18 PM Taylor Eisman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I don’t want to make this about gnuradio, because this isn’t the place.
> However, why would gnuradio know to link the ab,a,b,ba antennas to tx/rx
> and rx2?
>
> On Thu, Jul 18, 2019 at 7:14 PM Marcus D Leech 
> wrote:
>
>> There IS no RX2 or TX/RX antenna names on Basic_rx or Basic_tx boards.
>>
>> You can see In the probe output what the legit antenna names are for the
>> boards you have installed.
>>
>> Sent from my iPhone
>>
>> On Jul 18, 2019, at 6:33 PM, Robin Coxe via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>> Sorry, I misunderstood your question-- did you set up the mode in UHD
>> correctly?
>> http://files.ettus.com/manual/page_dboards.html
>>
>> Also, you might want to double-check the SMA connections just in case.
>> Not sure if the subdev spec has changed in the last year.  Someone who
>> knows the UHD codebase better than I do would have to answer that question.
>>
>>
>>
>> On Thu, Jul 18, 2019 at 3:26 PM Taylor Eisman via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Robin,
>>>
>>> We've set it up so that the RX Daughterboard connects to RX2 and the TX
>>> Daughterboard connects to TX/RX. Previously, we've been able to use these
>>> ports, but now it no longer identifies that we even have these ports. I
>>> don't think the issue is the Daughterboard as this worked less than a year
>>> ago.
>>>
>>> Thanks,
>>>
>>> Taylor
>>>
>>> ___
>>> 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] USRP X310 send period

[Nate Temple via USRP-users]

The RFNoC Replay block would be a good starting point, if you want to do
this all in the FPGA.

On Thu, Jul 18, 2019 at 2:04 PM Marcus Müller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> At the very benign 20 MS/s, I'd really say your first option is the way
> to go. The rest probably won't work very well du to turn on/off
> behaviour requiring you to zero pad a bit to flush your TX data chains.
>
> You can of course also write an RFNoC block to store and generate data
> in-FPGA, but really: at 20MS/s just continously stream. Even a bog-
> normal Gigabit Ethernet card has plenty enough bandwidth to do that. I
> doubt sending a sequence from RAM will occupy much CPU on your host PC.
>
> Best regards,
> Marcus
>
> On Thu, 2019-07-18 at 22:58 +0200, Cédric Hannotier via USRP-users
> wrote:
> > Dear all,
> >
> > I would like to periodically send a frame with an USRP X310 (frame
> > length: 320 samples, rate: 20 MS/s, period: 1-500 ms). However, I
> > struggle to find the best way to implement it. What I have tried so
> > far:
> >
> >   1. Append zeros to the frame to reach the expected period.
> > However,
> > this consumes too much bandwidth due to the zeros.
> >
> >   2. Use tx_streamer->send() with a tx_metadata_t.time_spec and
> > tx_streamer->recv_async_msg(). Using that, only the frame is sent,
> > saving most of the bandwidth. However, with small periods, it tends
> > to
> > print some 'L'.
> >
> >   3. Buffer a batch of send request on the USRP, then wait a
> > specific
> > time (using eg. recv_async_msg() until the returned metadata
> > contains
> > the penultimate time_spec (I expect that the time_spec returned is
> > the
> > one specified in the send metadata)) and redo. The issue is that I
> > was
> > not able to find the buffer size (is it related to the
> > tx_streamer->get_max_num_samps()?). I would like to fill the buffer
> > without overflow.
> >
> > I was hoping that I could save the frame in an USRP's memory, and
> > then
> > ask it to periodically send the frame with a specific period. Is it
> > possible?
> >
> > Here is an example of (2):
> >
> > template 
> > void send_from_file(const uhd::usrp::multi_usrp::sptr ,
> >  uhd::tx_streamer::sptr tx_stream, const
> > std::string&
> > file,
> >  const double period)
> > {
> > size_t data_size = get_file_size(file);
> > std::ifstream infile(file, std::ifstream::binary);
> > std::vector buff(data_size);
> > infile.read(reinterpret_cast(buff.data()),
> > (std::streamsize)(buff.size()*sizeof(samp_type)));
> > infile.close();
> > size_t num_tx_samps = buff.size();
> > std::cout << file << " " << buff[0] << " " << num_tx_samps <<
> > std::endl;
> >
> > uhd::tx_metadata_t md;
> > md.start_of_burst = true;
> > md.end_of_burst   = true;
> > md.has_time_spec  = true;
> > md.time_spec= usrp->get_time_last_pps()+5.;
> > double timeout = md.time_spec.get_real_secs();
> > uhd::async_metadata_t md_status;
> >
> > while (not stop_signal_called) {
> >   tx_stream->send((), num_tx_samps, md);
> >   if (tx_stream->recv_async_msg(md_status, timeout)) {
> >   if (md_status.event_code !=
> > uhd::async_metadata_t::event_code_t::EVENT_CODE_BURST_ACK) {
> >   std::cerr << "Error: " << md_status.event_code
> > << std::endl;
> >   exit(EXIT_FAILURE);
> >   }
> >   } else {
> >   std::cerr << "timeout before sent" << std::endl;
> >   exit(EXIT_FAILURE);
> >   }
> >
> >   timeout = 0.1;
> >   md.time_spec += period;
> > }
> > }
> >
> >
> >
> > Best Regards,
> > Cédric
> >
> > ___
> > 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] E320 unable to lock to external reference

[Nate Temple via USRP-users]

Hi Jason,

This might be a bug with the E320. I will need to try to recreate this
issue. I'll follow up as soon as I have more info.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 12:32 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> OK, we've been fighting this for a while and we think we narrowed it down
> to being a problem with the E320 (NOTE: we are running the E320 in network
> mode, not embedded)
>
> Some background:
> 1) external reference input is from an octo clock (so it the 1pps input)
> on many different ports
> a) also tried to use a  Symmetricom box for external reference and
> had the same problems
>
> 3) the same code we are testing with works when using an x310 instead of
> an e320, with inputs from the same octoclock
>
> 4) the code basically does this:
> a) sets the reference source to external
> b) checks to see if the reference is locked (and it keeps doing
> this until we get a "locked" response, using the uhd commands to do this)
>
> 5) for the e320, the locked status never returns (when running the x310
> with this code, it sometimes responds with unlocked, but after a few checks
> it comes back ok)
>
> 6) I tried some of the Ettus (UHD) test code
> a) running the "sync_to_gps" program did work - the reference was
> able to lock to the internal (gps) reference
> b) "test_clock_synch"  returns similiar errors to what we get with
> our program (see below):
> Checking USRP devices for lock.
>  * 318B08B: false
> WARNING: One or more devices not locked.
> Querying Clock for time and setting USRP times...
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> Running 10 comparisons at random intervals.
> Comparison #1
>  * Clock time: 1563463644
>  * 318B08B time: 1563463644
> Comparison #2
>  * Clock time: 1563463652
>  * 318B08B time: 1563463652
> Comparison #3
>  * Clock time: 1563463657
>  * 318B08B time: 1563463657
> Comparison #4
>  * Clock time: 1563463664
>  * 318B08B time: 1563463664
> Comparison #5
>  * Clock time: 1563463666
>  * 318B08B time: 1563463666
> Comparison #6
>  * Clock time: 1563463671
>  * 318B08B time: 1563463671
> Comparison #7
>  * Clock time: 1563463676
>  * 318B08B time: 1563463676
> Comparison #8
>  * Clock time: 1563463686
>  * 318B08B time: 1563463686
> Comparison #9
>  * Clock time: 1563463689
>  * 318B08B time: 1563463689
> Comparison #10
>  * Clock time: 1563463691
>  * 318B08B time: 1563463691
>
> Number of matches: 10/10
>
>
> 7) we ran the same tests at a sister site that has four E320s, and they
> all exhibited the same issues
>
> 8)Finally, a uhd_usrp_probe command returns this:
>
> [INFO] [UHD] linux; GNU C++ version 4.8.5 20150623 (Red Hat 4.8.5-36);
> Boost_105300; UHD_3.14.1.0-9-g2aa5289d
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=192.168.10.3,type=e3xx,product=e320,serial=318B08B,claimed=False,addr=192.168.10.3
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> ... many of these warnings repeating ...
> [WARNING] [MPM.PeriphManager] Reference Clock reporting unlocked.
> MB_CLOCK_CTRL reg: 0x0002
> [WARNING] [MPM.RPCServer] A timeout event occured!
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1324 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1322 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD10003320)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [MPM.PeriphManager] init() called with device args
> `product=e320,mgmt_addr=192.168.10.3'.
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C2)
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
> [INFO] [0/Radio_0] Performing CODEC loopback test...
> [INFO] [0/Radio_0] CODEC loopback test passed
>   _
>  /
> |   Device: E300-Series Device
> | _
> |/
> |   |   Mboard: ni-e320-318B08B
> |   |   eeprom_version: 2
> |   |   mpm_version: 3.14.0.0-g6875d061
> |   |   pid: 58144
> |   |   product: e320
> |   |   rev: 2
> |   |   rpc_connection: remote
> |   |   serial: 318B08B
> |   |   type: e3xx
> |   |   MPM Version: 1.2
> |   |   FPGA Version: 3.1
> |   |   FPGA git hash: e39334f.clean
> |   |   RFNoC capable: Yes
> |   |
> |   |   Time sources:  internal, external, gpsdo
> |   |   Clock sources: external, internal, gpsdo
> |   |   Sensors: gps_sky, gps_locked, temp_rf_channelA, temp_rf_channelB,
> temp_internal, fan, temp_main_power, ref_locked, gps_gpgga, temp_fpga,
> gps_tpv, gps_time
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   | 

Re: [USRP-users] Unable to Tx on 2 X300s with UHD 3.13.1.0 - benchmark_rate hangs

[Nate Temple via USRP-users]

Hi Serge,

We are aware of this issue and have an open issue on our internal bug
tracker for it. We currently do not have any work around and hope to have a
fix for it soon.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 10:53 AM Serge Malo via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> We are facing a important issue with UHD 3.13.1.0 with the X300:
> We can not Tx on the 4 channels of 2 X300s, even with the benchmark_rate
> example.
> We were able to do this flawlessly with UHD 3.10.3 for a long time.
>
> Here's the command we use:
> ./benchmark_rate --args addr0=192.168.40.2,addr1=192.168.50.2
> --tx_cpu=sc16 --tx_rate=2500 --ref=external --pps=external
> --tx_channels=0,1,2,3
>
> When using this command, the benchmark_rate hangs forever (See below the
> whole output)
> We have reproduced this error under Ubutun 18.04, with gcc 7.4 and Boost
> 1.68 (statically linked).
> We also saw the same problem under Windows 10.
>
> Please, let us if this issue was observed before, and if there is a
> correction available.
>
> Thanks,
> Serge
>
>
>
> benchmark_rate output:
> ./benchmark_rate --args addr0=192.168.40.2,addr1=192.168.50.2
> --tx_cpu=sc16 --tx_rate=2500 --ref=external --pps=external
> --tx_channels=0,1,2,3
>
> [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106800;
> UHD_3.13.1.skydel-1-ga4c99ab3
> [00:00:00.02] Creating the usrp device with:
> addr0=192.168.40.2,addr1=192.168.50.2...
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [1/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1300 MB/s)
> [INFO] [GPS] Found an internal GPSDO: LC_XO, Firmware Rev 0.929a
> [INFO] [1/DmaFIFO_0] BIST passed (Throughput: 1298 MB/s)
> [INFO] [1/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [1/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [1/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [1/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [1/DUC_0] Initializing block control (NOC ID: 0xD0C0)
> [INFO] [1/DUC_1] Initializing block control (NOC ID: 0xD0C0)
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1299 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1294 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
> Using Device: Multi USRP:
>   Device: X-Series Device
>   Mboard 0: X300
>   Mboard 1: X300
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
>   RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: UBX RX
>   RX Channel: 2
> RX DSP: 0
> RX Dboard: A
> RX Subdev: UBX RX
>   RX Channel: 3
> RX DSP: 0
> RX Dboard: B
> RX Subdev: UBX RX
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>   TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: UBX TX
>   TX Channel: 2
> TX DSP: 0
> TX Dboard: A
> TX Subdev: UBX TX
>   TX Channel: 3
> TX DSP: 0
> TX Dboard: B
> TX Subdev: UBX TX
>
> Now confirming lock on clock signals...
> [00:00:05.059918] Setting device timestamp to 0...
> [INFO] [MULTI_USRP] 1) catch time transition at pps edge
> [INFO] [MULTI_USRP] 2) set times next pps (synchronously)
> [00:00:06.714193] Testing transmit rate 25.00 Msps on 4 channels
> ^C
>
>
> ___
> 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] USRP E312 configuration

[Nate Temple via USRP-users]

Hi Philip,

We will be updating the kb.ettus.com application note when it is ready.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 10:03 AM Philip Balister  wrote:

> Why not post the instructions to the list and save people a bunch of time
> getting to this point?
>
> Philip
>
>
> On July 18, 2019 7:00:01 PM GMT+02:00, Nate Temple via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>>
>> Hi Andreas,
>>
>> The errors you see when loading the idle FPGA can be safely ignored and
>> are fixed in the new MPM based file system.
>>
>> We have a pending update for that application note that uses modern UHD
>> that will be posted soon. I can follow up with you off list with the
>> instructions for now.
>>
>> Regards,
>> Nate Temple
>>
>> On Thu, Jul 18, 2019 at 9:36 AM Andreas Weinand via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello,
>>>
>>> has someone already sucessfully made the E312 running using RFNOC
>>> scripts? like in the example in
>>>
>>> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>>>
>>>
>>> Unfortunately, i got the similar errors when following these
>>> instructions as reported here before (e.g.
>>>
>>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-March/056028.html
>>> ). I tried a lot of OS, UHD, gnuradio and gr-ettus combinations but all
>>> ended in some errors like this earlier or later.
>>>
>>> I am currently trying with Ubuntu 18.04., if anyone has a working setup,
>>> please let me know. Other OS are also fine for me.
>>>
>>> BR
>>>
>>> Andreas
>>>
>>>
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP E312 configuration

[Nate Temple via USRP-users]

Hi Andreas,

The errors you see when loading the idle FPGA can be safely ignored and are
fixed in the new MPM based file system.

We have a pending update for that application note that uses modern UHD
that will be posted soon. I can follow up with you off list with the
instructions for now.

Regards,
Nate Temple

On Thu, Jul 18, 2019 at 9:36 AM Andreas Weinand via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> has someone already sucessfully made the E312 running using RFNOC
> scripts? like in the example in
>
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>
>
> Unfortunately, i got the similar errors when following these
> instructions as reported here before (e.g.
>
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-March/056028.html
> ). I tried a lot of OS, UHD, gnuradio and gr-ettus combinations but all
> ended in some errors like this earlier or later.
>
> I am currently trying with Ubuntu 18.04., if anyone has a working setup,
> please let me know. Other OS are also fine for me.
>
> BR
>
> Andreas
>
>
> ___
> 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] Sequence Errors N200

[Nate Temple via USRP-users]

Hi Sumit,

Actually, I had a typo in the command, that previous benchmark_rate command
only tested RX, can you try passing the --tx_rate param and see if it will
produce sequence errors using benchmark_rate

./benchmark_rate --tx_rate 10e6 --duration 600

Regards,
Nate Temple

On Wed, Jul 17, 2019 at 8:27 AM Sumit Kumar  wrote:

> Ok I will do this.. but why the transmission with other USRP is working
> fine ?
>
> On Wed, Jul 17, 2019 at 5:22 PM Nate Temple  wrote:
>
>> Hi Sumit,
>>
>> So it looks like you have multiple version of UHD installed:
>>
>> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
>> sudo ./benchmark_tx.py -f 2.45G -S 10
>> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
>> UHD_003.009.002-0-unknown
>>
>>
>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
>> ./benchmark_rate --rx_rate 10e6 --duration 600
>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>> UHD_3.15.0.git-1-gf83faf28
>>
>>
>> I would recommend to stick to a single UHD version and use the latest
>> stable tagged released (currently 3.14.1.0) you will need to modify the
>> pybombs recipe to use the correct git tag (v3.14.1.0). The 'master' branch
>> can be unstable at times.
>>
>> Also, if you have a FPGA image of say 3.15.x.x flashed on the N210 and
>> then revert back to using 3.9.2, and UHD does not catch the mismatch, it
>> will likely cause flow control errors and unstable performance.
>>
>> The gr-digital/examples/narrowband/benchmark_tx.py example is also buggy,
>> and is being removed from GR 3.8. Using the UHD benchmark_rate utility will
>> test the hardware with a limited scope.
>>
>> Regards,
>> Nate Temple
>>
>>
>> On Wed, Jul 17, 2019 at 8:10 AM Sumit Kumar  wrote:
>>
>>> Sorry, here it is.
>>>
>>> Benchmark rate summary:
>>>   Num received samples: 586436
>>>   Num dropped samples:  0
>>>   Num overruns detected:0
>>>   Num transmitted samples:  0
>>>   Num sequence errors (Tx): 0
>>>   Num sequence errors (Rx): 0
>>>   Num underruns detected:   0
>>>   Num late commands:0
>>>   Num timeouts (Tx):0
>>>   Num timeouts (Rx):0
>>>
>>>
>>> On Wed, Jul 17, 2019 at 5:08 PM Nate Temple 
>>> wrote:
>>>
 Hi Sumit,

 It will take 10 minutes for that run to complete. Does it produce a
 report at the end of the run?

 Regards,
 Nate Temple

 On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar  wrote:

> Hi Nate,
> No there are not. At the end of the last line, cursor keeps blinking,
> no sequence errors.
>
> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
> ./benchmark_rate --rx_rate 10e6 --duration 600
>
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.15.0.git-1-gf83faf28
> [00:00:00.24] Creating the usrp device with: ...
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> Using Device: Single USRP:
>   Device: USRP2 / N-Series Device
>   Mboard 0: N200r4
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBXv3 RX
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBXv3 TX
>
> [00:00:01.796895] Setting device timestamp to 0...
> [00:00:01.797430] Testing receive rate 10.00 Msps on 1 channels
>
> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple 
> wrote:
>
>> Hi Sumit,
>>
>> If you run benchmark_rate for an extend period of time, do you see
>> any sequence errors?
>>
>> /usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 --duration
>> 600
>>
>>
>> Regards,
>> Nate Temple
>>
>> On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar  wrote:
>>
>>> Hi Nate,
>>> Yes I addressed the first 2 points you mentioned.
>>>
>>> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
>>> sudo ./benchmark_tx.py -f 2.45G -S 10
>>> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
>>> UHD_003.009.002-0-unknown
>>>
>>> Using Volk machine: avx_64_mmx_orc
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>>
>>> No gain specified.
>>> Setting gain to 15.75 (from [0.00, 31.50])
>>>
>>> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^C
>>>
>>> I am using ./benchmark_tx.py located
>>> in gnuradio/gr-digital/examples/narrowband
>>>
>>>

Re: [USRP-users] Sequence Errors N200

[Nate Temple via USRP-users]

Hi Sumit,

So it looks like you have multiple version of UHD installed:

john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
sudo ./benchmark_tx.py -f 2.45G -S 10
linux; GNU C++ version 5.3.1 20151219; Boost_105800;
UHD_003.009.002-0-unknown


john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
./benchmark_rate --rx_rate 10e6 --duration 600
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_3.15.0.git-1-gf83faf28


I would recommend to stick to a single UHD version and use the latest
stable tagged released (currently 3.14.1.0) you will need to modify the
pybombs recipe to use the correct git tag (v3.14.1.0). The 'master' branch
can be unstable at times.

Also, if you have a FPGA image of say 3.15.x.x flashed on the N210 and then
revert back to using 3.9.2, and UHD does not catch the mismatch, it will
likely cause flow control errors and unstable performance.

The gr-digital/examples/narrowband/benchmark_tx.py example is also buggy,
and is being removed from GR 3.8. Using the UHD benchmark_rate utility will
test the hardware with a limited scope.

Regards,
Nate Temple


On Wed, Jul 17, 2019 at 8:10 AM Sumit Kumar  wrote:

> Sorry, here it is.
>
> Benchmark rate summary:
>   Num received samples: 586436
>   Num dropped samples:  0
>   Num overruns detected:0
>   Num transmitted samples:  0
>   Num sequence errors (Tx): 0
>   Num sequence errors (Rx): 0
>   Num underruns detected:   0
>   Num late commands:0
>   Num timeouts (Tx):0
>   Num timeouts (Rx):0
>
>
> On Wed, Jul 17, 2019 at 5:08 PM Nate Temple  wrote:
>
>> Hi Sumit,
>>
>> It will take 10 minutes for that run to complete. Does it produce a
>> report at the end of the run?
>>
>> Regards,
>> Nate Temple
>>
>> On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar  wrote:
>>
>>> Hi Nate,
>>> No there are not. At the end of the last line, cursor keeps blinking, no
>>> sequence errors.
>>>
>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
>>> ./benchmark_rate --rx_rate 10e6 --duration 600
>>>
>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_3.15.0.git-1-gf83faf28
>>> [00:00:00.24] Creating the usrp device with: ...
>>> [INFO] [USRP2] Opening a USRP2/N-Series device...
>>> [INFO] [USRP2] Current recv frame size: 1472 bytes
>>> [INFO] [USRP2] Current send frame size: 1472 bytes
>>> Using Device: Single USRP:
>>>   Device: USRP2 / N-Series Device
>>>   Mboard 0: N200r4
>>>   RX Channel: 0
>>> RX DSP: 0
>>> RX Dboard: A
>>> RX Subdev: SBXv3 RX
>>>   TX Channel: 0
>>> TX DSP: 0
>>> TX Dboard: A
>>> TX Subdev: SBXv3 TX
>>>
>>> [00:00:01.796895] Setting device timestamp to 0...
>>> [00:00:01.797430] Testing receive rate 10.00 Msps on 1 channels
>>>
>>> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple 
>>> wrote:
>>>
 Hi Sumit,

 If you run benchmark_rate for an extend period of time, do you see any
 sequence errors?

 /usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 --duration 600


 Regards,
 Nate Temple

 On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar  wrote:

> Hi Nate,
> Yes I addressed the first 2 points you mentioned.
>
> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
> sudo ./benchmark_tx.py -f 2.45G -S 10
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
>
> Using Volk machine: avx_64_mmx_orc
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> No gain specified.
> Setting gain to 15.75 (from [0.00, 31.50])
>
> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^C
>
> I am using ./benchmark_tx.py located
> in gnuradio/gr-digital/examples/narrowband
>
>
>
> On Wed, Jul 17, 2019 at 4:25 PM Nate Temple 
> wrote:
>
>> Hi Sumit,
>>
>> A couple things to address:
>>
>> 1) Enable Thread priority scheduling on your host
>>
>> Note it is throwing a warning in the output: "[WARNING] [UHD] Unable
>> to set the thread priority. Performance may be negatively affected."
>>
>>
>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling
>>
>>
>> 2) Adjust your network buffers
>>
>> "
>> [WARNING] [UDP] The send buffer could not be resized sufficiently.
>> Target sock buff size: 250 bytes.
>> Actual sock buff size: 1048576 bytes.
>> See the transport 

Re: [USRP-users] Sequence Errors N200

[Nate Temple via USRP-users]

Hi Sumit,

It will take 10 minutes for that run to complete. Does it produce a report
at the end of the run?

Regards,
Nate Temple

On Wed, Jul 17, 2019 at 8:06 AM Sumit Kumar  wrote:

> Hi Nate,
> No there are not. At the end of the last line, cursor keeps blinking, no
> sequence errors.
>
> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/examples$ sudo
> ./benchmark_rate --rx_rate 10e6 --duration 600
>
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.15.0.git-1-gf83faf28
> [00:00:00.24] Creating the usrp device with: ...
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> Using Device: Single USRP:
>   Device: USRP2 / N-Series Device
>   Mboard 0: N200r4
>   RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: SBXv3 RX
>   TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: SBXv3 TX
>
> [00:00:01.796895] Setting device timestamp to 0...
> [00:00:01.797430] Testing receive rate 10.00 Msps on 1 channels
>
> On Wed, Jul 17, 2019 at 4:39 PM Nate Temple  wrote:
>
>> Hi Sumit,
>>
>> If you run benchmark_rate for an extend period of time, do you see any
>> sequence errors?
>>
>> /usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 --duration 600
>>
>>
>> Regards,
>> Nate Temple
>>
>> On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar  wrote:
>>
>>> Hi Nate,
>>> Yes I addressed the first 2 points you mentioned.
>>>
>>> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
>>> sudo ./benchmark_tx.py -f 2.45G -S 10
>>> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
>>> UHD_003.009.002-0-unknown
>>>
>>> Using Volk machine: avx_64_mmx_orc
>>> -- Opening a USRP2/N-Series device...
>>> -- Current recv frame size: 1472 bytes
>>> -- Current send frame size: 1472 bytes
>>>
>>> No gain specified.
>>> Setting gain to 15.75 (from [0.00, 31.50])
>>>
>>> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^C
>>>
>>> I am using ./benchmark_tx.py located
>>> in gnuradio/gr-digital/examples/narrowband
>>>
>>>
>>>
>>> On Wed, Jul 17, 2019 at 4:25 PM Nate Temple 
>>> wrote:
>>>
 Hi Sumit,

 A couple things to address:

 1) Enable Thread priority scheduling on your host

 Note it is throwing a warning in the output: "[WARNING] [UHD] Unable to
 set the thread priority. Performance may be negatively affected."


 https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling


 2) Adjust your network buffers

 "
 [WARNING] [UDP] The send buffer could not be resized sufficiently.
 Target sock buff size: 250 bytes.
 Actual sock buff size: 1048576 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.wmem_max=250
 [WARNING] [UDP] The send buffer could not be resized sufficiently.
 Target sock buff size: 250 bytes.
 Actual sock buff size: 1048576 bytes.
 See the transport application notes on buffer resizing.
 Please run: sudo sysctl -w net.core.wmem_max=250
 "

 https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#N2xx


 What is the command you're using to transmit(which utility and args?)


 Regards,
 Nate Temple

 On Wed, Jul 17, 2019 at 7:06 AM Sumit Kumar via USRP-users <
 usrp-users@lists.ettus.com> wrote:

> Following is what I am getting after the command you asked to run. The
> 192.168.10.5 gives SSS.
>
> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$
> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.5"
> Creating USRP device from address: addr=192.168.10.5
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.15.0.git-1-gf83faf28
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w 

Re: [USRP-users] Sequence Errors N200

[Nate Temple via USRP-users]

Hi Sumit,

If you run benchmark_rate for an extend period of time, do you see any
sequence errors?

/usr/local/lib/uhd/examples/benchmark_rate --rx_rate 10e6 --duration 600


Regards,
Nate Temple

On Wed, Jul 17, 2019 at 7:34 AM Sumit Kumar  wrote:

> Hi Nate,
> Yes I addressed the first 2 points you mentioned.
>
> john@john-Precision-M4600:~/pybombs/src/gnuradio/gr-digital/examples/narrowband$
> sudo ./benchmark_tx.py -f 2.45G -S 10
> linux; GNU C++ version 5.3.1 20151219; Boost_105800;
> UHD_003.009.002-0-unknown
>
> Using Volk machine: avx_64_mmx_orc
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
>
> No gain specified.
> Setting gain to 15.75 (from [0.00, 31.50])
>
> ..SS.SSS...S..SS.S..SS.SS...S.S...SS^C
>
> I am using ./benchmark_tx.py located
> in gnuradio/gr-digital/examples/narrowband
>
>
>
> On Wed, Jul 17, 2019 at 4:25 PM Nate Temple  wrote:
>
>> Hi Sumit,
>>
>> A couple things to address:
>>
>> 1) Enable Thread priority scheduling on your host
>>
>> Note it is throwing a warning in the output: "[WARNING] [UHD] Unable to
>> set the thread priority. Performance may be negatively affected."
>>
>>
>> https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling
>>
>>
>> 2) Adjust your network buffers
>>
>> "
>> [WARNING] [UDP] The send buffer could not be resized sufficiently.
>> Target sock buff size: 250 bytes.
>> Actual sock buff size: 1048576 bytes.
>> See the transport application notes on buffer resizing.
>> Please run: sudo sysctl -w net.core.wmem_max=250
>> [WARNING] [UDP] The send buffer could not be resized sufficiently.
>> Target sock buff size: 250 bytes.
>> Actual sock buff size: 1048576 bytes.
>> See the transport application notes on buffer resizing.
>> Please run: sudo sysctl -w net.core.wmem_max=250
>> "
>>
>> https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#N2xx
>>
>>
>> What is the command you're using to transmit(which utility and args?)
>>
>>
>> Regards,
>> Nate Temple
>>
>> On Wed, Jul 17, 2019 at 7:06 AM Sumit Kumar via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Following is what I am getting after the command you asked to run. The
>>> 192.168.10.5 gives SSS.
>>>
>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$
>>> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.5"
>>> Creating USRP device from address: addr=192.168.10.5
>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_3.15.0.git-1-gf83faf28
>>> [INFO] [USRP2] Opening a USRP2/N-Series device...
>>> [INFO] [USRP2] Current recv frame size: 1472 bytes
>>> [INFO] [USRP2] Current send frame size: 1472 bytes
>>> [WARNING] [UDP] The send buffer could not be resized sufficiently.
>>> Target sock buff size: 250 bytes.
>>> Actual sock buff size: 1048576 bytes.
>>> See the transport application notes on buffer resizing.
>>> Please run: sudo sysctl -w net.core.wmem_max=250
>>> [WARNING] [UDP] The send buffer could not be resized sufficiently.
>>> Target sock buff size: 250 bytes.
>>> Actual sock buff size: 1048576 bytes.
>>> See the transport application notes on buffer resizing.
>>> Please run: sudo sysctl -w net.core.wmem_max=250
>>> [WARNING] [UDP] The send buffer could not be resized sufficiently.
>>> Target sock buff size: 250 bytes.
>>> Actual sock buff size: 1048576 bytes.
>>> See the transport application notes on buffer resizing.
>>> Please run: sudo sysctl -w net.core.wmem_max=250
>>> [WARNING] [UHD] Unable to set the thread priority. Performance may be
>>> negatively affected.
>>> Please see the general application notes in the manual for instructions.
>>> EnvironmentError: OSError: error in pthread_setschedparam
>>>
>>> Fetching current settings from EEPROM...
>>> EEPROM ["hardware"] is "2576"
>>> EEPROM ["revision"] is ""
>>> EEPROM ["product"] is ""
>>> EEPROM ["mac-addr"] is "a0:36:fa:26:34:44"
>>> EEPROM ["ip-addr"] is "192.168.10.5"
>>> EEPROM ["subnet"] is "255.255.255.255"
>>> EEPROM ["gateway"] is "255.255.255.255"
>>> EEPROM ["gpsdo"] is "none"
>>> EEPROM ["serial"] is "E4R14V4UN"
>>> EEPROM ["name"] is ""
>>>
>>> Power-cycle the USRP device for the changes to take effect.
>>>
>>> Done
>>>
>>>
>>> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$
>>> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.3"
>>> Creating USRP device from address: addr=192.168.10.3
>>> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>> UHD_3.15.0.git-1-gf83faf28
>>> [INFO] [USRP2] 

Re: [USRP-users] Sequence Errors N200

[Nate Temple via USRP-users]

Hi Sumit,

A couple things to address:

1) Enable Thread priority scheduling on your host

Note it is throwing a warning in the output: "[WARNING] [UHD] Unable to set
the thread priority. Performance may be negatively affected."

https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux#Thread_priority_scheduling


2) Adjust your network buffers

"
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 250 bytes.
Actual sock buff size: 1048576 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=250
[WARNING] [UDP] The send buffer could not be resized sufficiently.
Target sock buff size: 250 bytes.
Actual sock buff size: 1048576 bytes.
See the transport application notes on buffer resizing.
Please run: sudo sysctl -w net.core.wmem_max=250
"

https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks#N2xx


What is the command you're using to transmit(which utility and args?)


Regards,
Nate Temple

On Wed, Jul 17, 2019 at 7:06 AM Sumit Kumar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Following is what I am getting after the command you asked to run. The
> 192.168.10.5 gives SSS.
>
> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$
> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.5"
> Creating USRP device from address: addr=192.168.10.5
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.15.0.git-1-gf83faf28
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> Fetching current settings from EEPROM...
> EEPROM ["hardware"] is "2576"
> EEPROM ["revision"] is ""
> EEPROM ["product"] is ""
> EEPROM ["mac-addr"] is "a0:36:fa:26:34:44"
> EEPROM ["ip-addr"] is "192.168.10.5"
> EEPROM ["subnet"] is "255.255.255.255"
> EEPROM ["gateway"] is "255.255.255.255"
> EEPROM ["gpsdo"] is "none"
> EEPROM ["serial"] is "E4R14V4UN"
> EEPROM ["name"] is ""
>
> Power-cycle the USRP device for the changes to take effect.
>
> Done
>
>
> john@john-Precision-M4600:~/pybombs/src/uhd/host/build/utils$
> ./usrp_burn_mb_eeprom --read-all --args "addr=192.168.10.3"
> Creating USRP device from address: addr=192.168.10.3
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.15.0.git-1-gf83faf28
> [INFO] [USRP2] Opening a USRP2/N-Series device...
> [INFO] [USRP2] Current recv frame size: 1472 bytes
> [INFO] [USRP2] Current send frame size: 1472 bytes
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [WARNING] [UDP] The send buffer could not be resized sufficiently.
> Target sock buff size: 250 bytes.
> Actual sock buff size: 1048576 bytes.
> See the transport application notes on buffer resizing.
> Please run: sudo sysctl -w net.core.wmem_max=250
> [WARNING] [UHD] Unable to set the thread priority. Performance may be
> negatively affected.
> Please see the general application notes in the manual for instructions.
> EnvironmentError: OSError: error in pthread_setschedparam
>
> Fetching current settings from EEPROM...
> EEPROM ["hardware"] is "2576"
> EEPROM ["revision"] is ""
> EEPROM ["product"] is ""
> EEPROM ["mac-addr"] is "a0:36:fa:26:34:42"
> EEPROM ["ip-addr"] is "192.168.10.3"
> EEPROM ["subnet"] is "255.255.255.255"
> EEPROM ["gateway"] is 

Re: [USRP-users] Meaning of "S" output

[Nate Temple via USRP-users]

Hi Alex,

The S is for a sequence error, which are generally a bad thing to observe.

What version of UHD are you using?

Do you have the N210 directly connected to your host? Do you have any other
networking gear in between (switch/router/hubs?)

What NIC do you have on your host machine?




Regards,
Nate Temple

On Tue, Jul 2, 2019 at 11:11 AM Alex Roberts via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I have N210 device that outputs a stream of a couple dozen "S" to the
> console before it stops processing samples. I say "stops processing
> samples" because when I use a GUI sink in gnuradio-companion to look at
> complex values being sent to the USRP, it updates once or twice, then goes
> static after the stream of "S" is complete. What does "S" mean? I can't
> find any documentation on it.
>
> Thanks!
> ___
> 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] RX/TX on 4 channels on N310

[Nate Temple via USRP-users]

Hi Jessica,

What sample rate are you trying to run at per channel?

I would suggest to use DPDK as it will remove a considerable overhead from
the Linux networking stack.

I can follow up with you off the list with some notes I have on getting
DPDK going, we have a pending app note that will be published soon on the
topic.

Regards,
Nate Temple


On Wed, Jun 19, 2019 at 12:05 PM Jessica Iwamoto via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
>
>
> I am getting a lot of underflows when trying to use dual RX/TX on 4
> channels on the N310. My application creates one multi_usrp object and 8
> streamers (4 RX, 4 TX) each on a different thread. Samples are received
> from the RX threads, put into buffers, and then transmitted in the TX
> threads. I can run it on 1 channel and 2 channels, but when I try using
> more channels, I get a ton of underflows. When I use 2 channels, I also
> have to specify the subdevice as “A:0 B:0 A:1 B:1”, otherwise I will get a
> lot of underflows with the default subdevice spec of “A:0 A:1 B:0 B:1”. I
> have tried the txrx_loopback_to_file example with 4 channels and it works
> fine, although this example only uses 2 streamers, each controlling 4
> channels. Any suggestions on what to try to make this work? I am using UHD
>  v3.13.1.0-rc1.
>
>
>
> Thanks,
>
>
>
> Jessica Iwamoto
>
> Member of Technical Staff
>
> The Aerospace Corporation
>
>
> ___
> 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] E320 with larger SD card

[Nate Temple via USRP-users]

Hi Jason,

I have some instructions I will send you off list for adding an additional
partition you can try. I wrote them for the E310, but have not yet tested
them on E320, however, it should be a similar process.

Regards,
Nate Temple

On Wed, Jun 19, 2019 at 9:44 AM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I used bmaptool to write the image and I used gparted to extend it.  I
> just tried again and still no dice.
>
>
> I just tried to boot with the serial terminal on and I see this on the
> screen (no LED ever comes on):
>
>
> U-Boot SPL 2018.01 (May 10 2019 - 13:20:55)
> mmc boot
> Trying to boot from MMC1
> reading u-boot.img
> reading u-boot.img
>
>
> U-Boot 2018.01 (May 10 2019 - 13:20:55 +)
>
> Model: NI Ettus Research Project NEON SDR
> DRAM:  ECC disabled 1 GiB
> MMC:   sdhci@e010: 0
>
>
>
>
>
> --
> *From:* USRP-users  on behalf of
> Marcus D. Leech via USRP-users 
> *Sent:* Wednesday, June 19, 2019 12:33 PM
> *To:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] E320 with larger SD card
>
> On 06/19/2019 12:29 PM, Jason Matusiak via USRP-users wrote:
>
> I wanted to use a larger SD card than the one that as supplied, but I am
> having issues.  I loaded up the card, and then extended the data partition
> to use up the rest of the free space (about 100GB).  But then it doesn't
> boot.
>
> What steps did you take to extend the partition?
>
>
>
> I am wondering if the change to a partition size screwed up something in a
> config file somewhere.  Is there a way to fix this without rebuilding a
> docker image?  I am using the UHD 3.14.0.0. that has the smaller data
> partition (UHD 3.14.1.0 has a larger data partition, but doesn't include
> any GR/python packages, so I need to use the older image).
>
>
> Thanks.
>
>
> ___
> 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] E310 Startup/Boot not working

[Nate Temple via USRP-users]

Hi Donnie,

Is your E310 a SG1 or SG3?

https://kb.ettus.com/Ettus_USRP_E300_Embedded_Family_Hardware_Resources#SD_Card_Images

Regards,
Nate Temple

On Mon, Jun 17, 2019 at 1:53 PM Donnie C via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> I'm currently trying to get the E310 to boot with the most recent image
> release (
> http://files.ettus.com/e3xx_images/e3xx-release-4/ettus-e3xx-sg1/sdimage-gnuradio-demo.direct.xz
> ) which I burned onto an microSD card using bitmap, but I cannot serial
> connect into it and the device has all the antennae LEDs on. I cannot find
> what the LEDs mean or why the E310 wont boot
> ___
> 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 master clock rate incorrect?

[Nate Temple via USRP-users]

Hi Nick,

This sounds like there may still be a bug in the new DDC/DUC's since the
change from CORDIC to DDSes [0]. There was a similar issue [1][2] but the
patch was merged in at 3.14.0.0 [3].

Could you try a UHD version pre-3.12.0.0 to see if it resolves the issue?
3.11.1.0 or 3.10.3.0 would be my recommendation.

[0] - https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L365
[1] - https://github.com/EttusResearch/uhd/issues/211
[2] - https://github.com/EttusResearch/fpga/pull/35
[3] -
https://github.com/EttusResearch/fpga/commit/fdd77081c4aaa2c79d56eb08516bdb563f9b6a89


Regards,
Nate Temple

On Sat, Jun 15, 2019 at 11:08 AM Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Yes to both!. That's what led me to believe the rate was wrong. LFRX is DC
> coupled, but the arrangement it's in has the next component in the chain
> blocking DC.
>
> I tested with gr-ettus/device3 today, and the bug isn't there. So I think
> there's something in the legacy driver.
>
> Nick
>
> On Sat, Jun 15, 2019 at 11:03 AM Ian Buckley 
> wrote:
>
>> Go tune WWV, your friendly Federal signal generator?
>> (Also isn’t LFRX DC coupled?)
>>
>> > On Jun 14, 2019, at 11:43 PM, Nick Foster via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>> >
>> > Got a weird one here. I'm using an X310 with UHD 3.14.0.0-87-g4e084337,
>> with two LFRX daughterboards installed. Legacy interface with gr-uhd, not
>> gr-ettus, just testing things in the field. When I tune to 15MHz sample
>> rate at 1Msps, I get a resulting stream that looks for all the world like
>> it's coming in at 7.5MHz and 500ksps. Because this is a field deployment,
>> and because I don't have immediate access to a signal generator, it's a bit
>> hard to confirm that. It looks to me (at first blush) like the DDC block is
>> getting an incorrect master clock rate, and setting its tick rate
>> accordingly. When I set the frequency to 30MHz and the sample rate to
>> 2Msps, I get the result I'm expecting.
>> >
>> > I don't believe I'm seeing the same problem with device3/gr-ettus, but
>> I'll test that further today. Anyone seen behavior like this before?
>> There's also an unexpected DC offset I haven't seen before, if that helps
>> jog anyone's memory. Since it's direct-sampled, not zero-IF, any DC offset
>> must be the result of the DSP chain.
>> >
>> > Nick
>> > ___
>> > 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] E320 hogging the network

[Nate Temple via USRP-users]

Hi Jason,

You could try running the new 3.15 MPM based file system for the E310, but
it has some caveats, more details here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2019-May/059897.html



Regards,
Nate Temple

On Fri, Jun 7, 2019 at 12:05 PM Jason Matusiak <
ja...@gardettoengineering.com> wrote:

> OK, this is actually an E310 problem.  The E310 always looks off device
> first.  A coworker reminded me that we spent a couple days years
> back trying to figure out why the device was asking like it was working,
> but we weren't seeing any results.  It was because it was actually talking
> to an N2xx on the network even with the IP address arg.
>
>
> We never found a solution (using both the 127 and 192 address as an
> argument still causes issues).  So, it would be nice to clean this up on
> the E310 at some point, but for now I will try not to mix the E310 and
> E320 on the same subnet.
>
>
> --
> *From:* Jason Matusiak
> *Sent:* Friday, June 7, 2019 12:41 PM
> *To:* Nate Temple
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
>
> OK, maybe based on my last email (which crossed yours I think).  The addr
> flag doesn't seem to work at all with the uhd_usrp_probe on the E310 (at
> least my version).
>
> --
> *From:* Nate Temple 
> *Sent:* Friday, June 7, 2019 12:37 PM
> *To:* Jason Matusiak
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Hi Jason,
>
> For what its worth, I haven't personally ran this exact combo (E310 w/ UHD
> 3.11 and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the
> same subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into
> the issue where probing in embedded mode would pickup the other device
> first, but when providing a localhost addr, it worked as expected. I could
> use both devices from a common host in network mode.
>
> Trying the E320/E310 on different subnets would be worth a try.
>
> I'll open an internal issue on our bug tracker for this, there is likely
> improvements we can make to the device discovery.
>
>
> Regards,
> Nate Temple
>
> On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak <
> ja...@gardettoengineering.com> wrote:
>
> Howdy.
>
>
> Nope, but it fails in a weird way.  I disconnected the E320 to make sure
> this issue wasn't due to it, but it still acts the same.
>
>
> If I run: uhd_usrp_probe --args "addr=127.0.0.1"
>
> *root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1" *
> *[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400;
> UHD_3.11.0.1-0-unknown*
> *Error: i2c_zc_impl recv timeout*
>
>
> Reading up on the USRP2, they specifically say that you need to be on
> different subnets if you are using more than on device.  I wonder if this
> is the case here too?
> https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
>
>
> --
> *From:* Nate Temple 
> *Sent:* Friday, June 7, 2019 12:17 PM
> *To:* Jason Matusiak
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Hi Jason,
>
> On the E310, if you pass the device arg addr with 127.0.0.1 does it work
> as expected?
>
> uhd_usrp_probe --args "addr=127.0.0.1"
>
>
> Regards,
> Nate Temple
>
> On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Darn, I was hoping that was it, but I don't think so.
>
>
> Here is the result from my E310:
>
> eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46
>
> and now the E320:
>
> sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB
>
> If I ping each device on my host, then run arp, I see this (the mac
> addresses match up correctly):
>
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 192.168.10.45ether   00:80:2f:24:c2:fb   C
>  p4p1
> 192.168.10.95ether   00:80:2f:25:44:46   C
>  p4p1
>
> I figured that that would be fine though because I have the same issue
> when I am running commands ON my E310.  And if it was a routing issue, it
> would mean that both my machine and the E310 and the E320 were being
> screwed up.
>
>
>
> --
> *From:* Marcus D Leech 
> *Sent:* Friday, June 7, 2019 12:01 PM
> *To:* Jason Matusiak
> *Cc:* Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check the MAC addresses.
>
> I know that on some ARM platforms that has to be programmed in at boot and
> perhaps these system images have it set to the same value.
>
> Sent from my iPhone
>
> On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Philip,
>
>
> They have unique addresses (10.95 and 10.45).  It is really weird that
> when I am on the E310, and set the ip-addr to himself, that he would even
> look off the device
>
>
> 

Re: [USRP-users] E320 hogging the network

[Nate Temple via USRP-users]

Hi Jason,

For what its worth, I haven't personally ran this exact combo (E310 w/ UHD
3.11 and E320 w/ 3.14) on the same subnet, but I have ran two N320's on the
same subnet (192.168.10.2 and 192.168.10.3, both with 3.14). I did run into
the issue where probing in embedded mode would pickup the other device
first, but when providing a localhost addr, it worked as expected. I could
use both devices from a common host in network mode.

Trying the E320/E310 on different subnets would be worth a try.

I'll open an internal issue on our bug tracker for this, there is likely
improvements we can make to the device discovery.


Regards,
Nate Temple

On Fri, Jun 7, 2019 at 9:22 AM Jason Matusiak 
wrote:

> Howdy.
>
>
> Nope, but it fails in a weird way.  I disconnected the E320 to make sure
> this issue wasn't due to it, but it still acts the same.
>
>
> If I run: uhd_usrp_probe --args "addr=127.0.0.1"
>
> *root@ettus-e3xx-sg3:~# uhd_usrp_probe --args "addr=127.0.0.1" *
> *[INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106400;
> UHD_3.11.0.1-0-unknown*
> *Error: i2c_zc_impl recv timeout*
>
>
> Reading up on the USRP2, they specifically say that you need to be on
> different subnets if you are using more than on device.  I wonder if this
> is the case here too?
> https://files.ettus.com/manual/page_usrp2.html#usrp2_network_multidev
>
>
> --
> *From:* Nate Temple 
> *Sent:* Friday, June 7, 2019 12:17 PM
> *To:* Jason Matusiak
> *Cc:* Marcus D Leech; Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Hi Jason,
>
> On the E310, if you pass the device arg addr with 127.0.0.1 does it work
> as expected?
>
> uhd_usrp_probe --args "addr=127.0.0.1"
>
>
> Regards,
> Nate Temple
>
> On Fri, Jun 7, 2019 at 9:10 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Darn, I was hoping that was it, but I don't think so.
>
>
> Here is the result from my E310:
>
> eth0  Link encap:Ethernet  HWaddr 00:80:2F:25:44:46
>
> and now the E320:
>
> sfp0  Link encap:Ethernet  HWaddr 00:80:2F:24:C2:FB
>
> If I ping each device on my host, then run arp, I see this (the mac
> addresses match up correctly):
>
> Address  HWtype  HWaddress   Flags Mask
> Iface
> 192.168.10.45ether   00:80:2f:24:c2:fb   C
>  p4p1
> 192.168.10.95ether   00:80:2f:25:44:46   C
>  p4p1
>
> I figured that that would be fine though because I have the same issue
> when I am running commands ON my E310.  And if it was a routing issue, it
> would mean that both my machine and the E310 and the E320 were being
> screwed up.
>
>
>
> --
> *From:* Marcus D Leech 
> *Sent:* Friday, June 7, 2019 12:01 PM
> *To:* Jason Matusiak
> *Cc:* Philip Balister; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check the MAC addresses.
>
> I know that on some ARM platforms that has to be programmed in at boot and
> perhaps these system images have it set to the same value.
>
> Sent from my iPhone
>
> On Jun 7, 2019, at 11:52 AM, Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> Philip,
>
>
> They have unique addresses (10.95 and 10.45).  It is really weird that
> when I am on the E310, and set the ip-addr to himself, that he would even
> look off the device
>
>
> They both have hostnames and they are not similar to each other at all.
>
>
>
> --
> *From:* Philip Balister 
> *Sent:* Friday, June 7, 2019 11:10 AM
> *To:* Jason Matusiak; Ettus Mail List
> *Subject:* Re: [USRP-users] E320 hogging the network
>
> Check each ones ip address, likely by running ifconfig. In the back of
> my mind, I recall something like this in the E100 days. Do they have the
> same hostname?
>
> Philip
>
> On 06/07/2019 07:37 AM, Jason Matusiak via USRP-users wrote:
> > It looks like I am misunderstanding something with how the E320 handles
> the network.
> >
> >
> > I have my E320 on my subnet with the sfp0 assigned to 10.45 (instead of
> the default 10.2).  I can ssh into it and things seem to run fine in
> embedded mode.
> >
> >
> > Now, if I ssh onto an E312 that is on the same network (IP 10.95), it
> doesn't work right as long as the E320 is plugged in.  When I do a probe or
> run any other UHD-type commands on the E310, it seems to always talk to the
> E320 first and it screws everything up.  It doesn't matter if I put the
> E310's address into the command or not, the E320 responds.  I also remember
> seeing this occur when I was on my host machine running commands (the E320
> bullied its way into being the main attraction).
> >
> >
> > My current work-around is to unplug Ethernet from the E320, run my
> command on the E310, plug back into the E320, then run its command.  This
> seems to allow things to work as I intended, but is obviously not ideal and
> is fairly difficult to do when devices are remote.
> >
> >
> > So what am I missing here?
> >
> >
> >

Re: [USRP-users] Max Sample Rate Exceeds Capacity

[Nate Temple via USRP-users]

Hi Mark,

We just merged DPDK support for the X3xx. You can try it out if you build
the current head of master. DPDK may help with 8 channels running at 100
MS/s each.

https://github.com/EttusResearch/uhd/commits/master

https://files.ettus.com/manual/page_dpdk.html

Regards,
Nate Temple


On Wed, Apr 10, 2019 at 3:33 PM Mark Gannet via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Okay thank you Marcus.
>
> Mark
>
> On Wed, Apr 10, 2019 at 3:09 PM Marcus D. Leech 
> wrote:
>
>> On 04/10/2019 05:31 PM, Mark Gannet wrote:
>>
>> I've addressed the USRP as the following:
>> USRP[0-3]: 192.168.4x.2, where x=0,1,2,3
>>
>> UHD 3.9.2
>>
>> You should probably upgrade to a newer UHD version.  There were bugs in
>> that area, as I recall, that have since been fixed.
>>
>>
>> On Wed, Apr 10, 2019 at 1:47 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 04/10/2019 04:41 PM, Mark Gannet via USRP-users wrote:
>>> > I have 4 USRP x310s running at 12.5 MSa/sec on a quad 10GbE network
>>> > adapter (each USRP has it's own 10 GbE connection).  I'm using the 16
>>> > bit short format.
>>> >
>>> > I can operate one USRP at a time 100 MSa/sec with no overflows or
>>> > drops (200 MSa/sec total for one USRP).  If I want to run all 4 USRP,
>>> > I can only achieve 25 MSa/sec for all 8 channels (total of 200
>>> MSa/sec).
>>> >
>>> > Basically the sum of sample rates cannot exceed 200 MSa/sec which is
>>> > about 6400 Mbps (200*4 bytes/sa * 8 b/B).
>>> >
>>> > Why is this?  I thought with a dedicated 10GbE network port for each
>>> > USRP, the sample rate limit would be 100 MSa/sec for each (6400 Mbps).
>>> >
>>> > Thanks,
>>> > Mark
>>> >
>>> What version of UHD are you using?
>>>
>>> How are you addressing the USRPs?
>>>
>>>
>>>
>>> ___
>>> 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] Changing sample rate while running.

[Nate Temple via USRP-users]

Hi Chance,

What version of UHD are you using?

Could you please give the UHD branch UHD-3.10 a try with your application
to see if it makes any difference?

Regards,
Nate Temple

On Mon, Apr 8, 2019 at 8:56 AM Chance Tarver via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
> I am working on a project where I need to change the sampling rate
> occasionally while running my application.
>
> At an event where I need to change the sampling rate, I am currently
> calling the following function:
> set_tx_rate(new_rate, channel)
>
> The master clock is always set to 30.72MHz and the TX bandwidth is set to
> 20MHz.
>
> When the change occurs, it seems that I am not getting the new sampling
> rate on the spectrum analyzer. I know these sort of changes in sampling
> rates can be weird and depend on how the various clocks are set.
>
> Is there a recommended procedure / series of steps for a change in
> sampling rate to take effect?
>
> I appreciate any guidance.
>
> Thanks,
> Chance Tarver
> Rice University
> ___
> 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 build for an e320

[Nate Temple via USRP-users]

Hi Jason,

You can disable the QT widgets (not needed on the E320 itself) by adding
the cmake flag -DENABLE_QT=OFF



Regards,
Nate Temple


On Mon, Apr 8, 2019 at 1:00 PM Nate Temple  wrote:

> Hi Jason,
>
> It looks like you are missing the package: python-setuptools
>
> Note, you should not use rfnoc-devel, but instead use a newer version of
> UHD like v3.14.0.0, and then you can enable RFNoC by adding the cmake flag
> -DENABLE_RFNOC=ON
>
> Regards,
> Nate Temple
>
>
> On Mon, Apr 8, 2019 at 12:34 PM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I should be getting an e320 in this week, so I started to get my
>> environment setup.  I started off like I do for the e310 and ran the
>> cross-compile shell script.  I then sourced the environment.  I cloned uhd
>> and checked out rfnoc-devel like I usually do.  Within uhd, I created a
>> folder called build_mpm.  Within that, I ran: cmake
>> -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
>> -DCMAKE_INSTALL_PREFIX=/usr ../mpm/
>>
>> That seemed to work OK.  I then ran mak -j12 and it looks like it is done
>> and worked, but it actually throws an error at the end:
>> [ 98%] Linking CXX shared library libpyusrp_periphs.so
>> [ 98%] Built target pyusrp_periphs
>> [100%] Generating build/timestamp
>> Traceback (most recent call last):
>>   File "/opt/gnuradio/e320/src/uhd/build_mpm/python/setup.py", line 11,
>> in 
>> from setuptools import setup
>> ImportError: No module named 'setuptools'
>> make[2]: *** [python/build/timestamp] Error 1
>> make[1]: *** [python/CMakeFiles/usrp_mpm.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Is something missing that needs to be built before building UHD?
>>
>> ___
>> 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 build for an e320

[Nate Temple via USRP-users]

Hi Jason,

It looks like you are missing the package: python-setuptools

Note, you should not use rfnoc-devel, but instead use a newer version of
UHD like v3.14.0.0, and then you can enable RFNoC by adding the cmake flag
-DENABLE_RFNOC=ON

Regards,
Nate Temple


On Mon, Apr 8, 2019 at 12:34 PM Jason Matusiak via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I should be getting an e320 in this week, so I started to get my
> environment setup.  I started off like I do for the e310 and ran the
> cross-compile shell script.  I then sourced the environment.  I cloned uhd
> and checked out rfnoc-devel like I usually do.  Within uhd, I created a
> folder called build_mpm.  Within that, I ran: cmake
> -DCMAKE_TOOLCHAIN_FILE=../host/cmake/Toolchains/oe-sdk_cross.cmake
> -DCMAKE_INSTALL_PREFIX=/usr ../mpm/
>
> That seemed to work OK.  I then ran mak -j12 and it looks like it is done
> and worked, but it actually throws an error at the end:
> [ 98%] Linking CXX shared library libpyusrp_periphs.so
> [ 98%] Built target pyusrp_periphs
> [100%] Generating build/timestamp
> Traceback (most recent call last):
>   File "/opt/gnuradio/e320/src/uhd/build_mpm/python/setup.py", line 11, in
> 
> from setuptools import setup
> ImportError: No module named 'setuptools'
> make[2]: *** [python/build/timestamp] Error 1
> make[1]: *** [python/CMakeFiles/usrp_mpm.dir/all] Error 2
> make: *** [all] Error 2
>
> Is something missing that needs to be built before building UHD?
>
> ___
> 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] x300_dac_ctrl: timeout waiting for DAC PLL to lock

[Nate Temple via USRP-users]

Hi Lisa,

This error usually points to a failure on the MB which requires a RMA.

If you remove your custom DB and run uhd_usrp_probe against just the MB do
you still get this error?

Regards,
Nate Temple


On Mon, Apr 8, 2019 at 9:13 AM Faller, Lisa-Marie via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> we see the following error when executing uhd_usrp_probe:
>
> ‘…x300_dac_ctrl: timeout waiting for DAC PLL to lock…’
>
> We are working on an x310 (2015) and built a custom RX-Board to it.
>
> This used to work fine;
>
> Recently we have another revision of the custom board
>
> and were trying to set the GPIOs on RXB multiple times to high and low (to
> set the gain of a PGA)…
>
> When changing the GPIO state the 5th or 6th time, we encountered the
> error as above;
>
> We already tried flashing a new image (also one without RFNOC),
>
> but nothing worked so far…
>
>
>
> Could the issue be the in the UHD, but how could that have happened?
>
>
>
> Any suggestions on how to proceed?
>
>
>
> Thank you and best wishes,
>
> Lisa
> ___
> 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] UHD3

[Nate Temple via USRP-users]

Hi Vinayak,

The INF files are only required for USB based USRPs.

If you're able to probe the device with uhd_usrp_probe.exe, you should be
good to go.

Regards,
Nate Temple

On Tue, Mar 26, 2019 at 1:58 PM VINAYAK KARANDIKAR via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello Everyone,
>  I was wondering if my message has not been
> delivered yet?
>  This is regarding the UHD installation.
>  Now following help earlier, i have been able
> to successfully install the UHD on a
> Windows 10 system.
>
>  However the page "
> http://files.ettus.com/manual/page_install.html; tells me
>  that there are post installation activities. So are they
> applicable to me as well,  in my
> case(Windows 10, UHD already downloaded and installed)? In
>that case, i have further questions: I see files with the
> inf extension which   may have something to
> do with various USRP devices except NI 2954R,
>which is my device of interest. So what do i do in this case? Which
> inf file do   i choose?
>
> Finally, is that all? Do i finish with all
> necessities to start using my USRP NI
> 2954R device finally?
> Thanks a lot,
> Vinayak Anant Karandikar
> ___
> 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?

[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] N310 Initial Connection Issues

[Nate Temple via USRP-users]

Hi Marc,

What version of UHD are you using? If you're not running with any
3.14.0.0-rcX release, can you please try v3.14.0.0-rc3 ?

Regards,
Nate Temple

On Tue, Mar 12, 2019 at 10:37 AM Marc Lichtman via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey,
>
> I'm having issues connecting to a N310 with stock firmware.  Its eth0 port
> works fine; it can get an IP address and I can even SSH into it from a
> different (host) computer, but when I set up a second ethernet port on my
> host with a static IP of 192.168.10.1 and mask 255.255.255.0, and connect
> it to SFP0 on the N310, pinging 192.168.10.2 fails with destination
> unreachable.  I'm using the transceiver that came with it, and the lights
> above the SFP0 port on the USRP are on (one is solid, one flashes on
> occasion).  I verified my host was using 192.168.10.1 on the port connected
> to SFP0.
>
> Some possible clues- When I run uhd_find_devices on the host, the N310
> shows up, but said "Reachable: No" (which is a new field to me).  When I
> SSH into the N310 and do ifconfig, it shows the eth0 with its assigned IP
> address, and it shows sfp1 but with no IP address, and no sfp0/sfp2 (not
> sure how its suppose to be labeled).  I was expected to do ifconfig and see
> sfp0 showing 192.168.10.2 and sfp1 with 192.168.20.2 since it's static.
>
> Any help would be greatly appreciated!  Thanks!
>
> -Marc
> ___
> 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] HG vs HGS

[Nate Temple via USRP-users]

Hi Bob,

The _HGS images are SRAM based vs the HG image is DRAM based.

The _HGS images were removed as of UHD 3.10.x.x and you should use the _HG
image.

The _HG* images are setup for 1Gb speeds on SFP0 and 10Gb on SFP1.

The XG image is 10Gb on both SFP0 and 1.

Regards,
Nate Temple

On Mon, Mar 4, 2019 at 1:41 PM Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> What is the difference between the two versions?
>
>
>
> Is there a preferred version for X310 with UBX-160 daughtercards and 10gbe?
>
>
>
> Thanks,
> ___
> 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] USRP X310 GPS or IEEE 1588 Synchronization

[Nate Temple via USRP-users]

Hi Rob,

Yes, that's correct, you can use the WR-LEN with the X310.

Regards,
Nate Temple






On Wed, Feb 27, 2019 at 12:40 PM Rob Kossler  wrote:

> Nate,
> Although the X3xx series to not natively support White Rabbit, I believe
> that they can get all of the benefits by using a WR-LEN in close proximity
> to the X310.  Is that correct?
>
> Rob
>
> On Wed, Feb 27, 2019 at 11:45 AM Nate Temple via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Akin,
>>
>> The Octoclock-G would be suitable for this purpose, and yes, it does
>> contain a GPSDO (OCXO). https://kb.ettus.com/GPSDO#GPSDO_.28OCXO.29
>>
>> The Octoclock-G does not contain an antenna, you must provide one to the
>> GPS Antenna input (SMA).
>>
>> The X3xx series do not support IEEE 1588, however, the N3xx series USRPs
>> do support White Rabbit, which is an extension of the IEEE-1588-2008
>> standard. More info can be found here on it
>> https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
>>
>>
>> Regards,
>> Nate Temple
>>
>> On Wed, Feb 27, 2019 at 8:31 AM akin soysal via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello All,
>>>
>>>
>>> I have a question. We want to synchronize the clock of the two USRP
>>> X310s with a GPS or IEEE 1588 standard. I would like to synchronize the two
>>> USRPs with each other so that the base station and user terminal would not
>>> experience any synchronization issue. I also would like to synchronize one
>>> of the USRP X310s with an external base station, which supports IEEE 1588
>>> and GPS clocks, and we have a synchronization budget of about *250us*.
>>>
>>>
>>> I learned that the setup that worked in France is using the following
>>> Ettus product:
>>>
>>>
>>> https://www.ettus.com/product/details/OctoClock-G
>>>
>>>
>>> Do you think that this would suffice for our needs? It has its own GPS
>>> clock and antenna inside, right? It is compatible with USRP X310?
>>>
>>>
>>> I know that the product specification does not include IEEE 1588, so I
>>> am concluding that it would not be possible to use this standard for our
>>> scenario, do you agree?
>>>
>>> Thanks and regards,
>>>
>>> Akın
>>> ___
>>> 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] USRP X310 GPS or IEEE 1588 Synchronization

[Nate Temple via USRP-users]

Hi Akin,

The Octoclock-G would be suitable for this purpose, and yes, it does
contain a GPSDO (OCXO). https://kb.ettus.com/GPSDO#GPSDO_.28OCXO.29

The Octoclock-G does not contain an antenna, you must provide one to the
GPS Antenna input (SMA).

The X3xx series do not support IEEE 1588, however, the N3xx series USRPs do
support White Rabbit, which is an extension of the IEEE-1588-2008 standard.
More info can be found here on it
https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices


Regards,
Nate Temple

On Wed, Feb 27, 2019 at 8:31 AM akin soysal via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello All,
>
>
> I have a question. We want to synchronize the clock of the two USRP X310s
> with a GPS or IEEE 1588 standard. I would like to synchronize the two USRPs
> with each other so that the base station and user terminal would not
> experience any synchronization issue. I also would like to synchronize one
> of the USRP X310s with an external base station, which supports IEEE 1588
> and GPS clocks, and we have a synchronization budget of about *250us*.
>
>
> I learned that the setup that worked in France is using the following
> Ettus product:
>
>
> https://www.ettus.com/product/details/OctoClock-G
>
>
> Do you think that this would suffice for our needs? It has its own GPS
> clock and antenna inside, right? It is compatible with USRP X310?
>
>
> I know that the product specification does not include IEEE 1588, so I am
> concluding that it would not be possible to use this standard for our
> scenario, do you agree?
>
> Thanks and regards,
>
> Akın
> ___
> 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] USRP eNB to USRP UE - OAI

[Nate Temple via USRP-users]

Hi Matthew,

We often run OAI on B2xx, X3xx and N3xx USRPs.

The best resource for getting started are OAI's getting started page and
associated wiki / tutorials.

https://www.openairinterface.org/?page_id=25
https://gitlab.eurecom.fr/oai/openairinterface5g/wikis/home

Regards,
Nate Temple

On Wed, Feb 27, 2019 at 8:30 AM Matthew Day via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I’m currently running a couple LimeSDR’s trying to get an LTE lab setup
> but have had issues and looking to change hardware. Has anyone here has had
> success with OAI and connecting two USRP devices together? I’d love any
> guides and hardware recommendations.
> ___
> 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] GPS week rollover readiness?

[Nate Temple via USRP-users]

Hi Joshua,

Ublox has confirmed the u-blox 6 modules have been tested and there is no
issue with the 2019 GPS week number roll over event.

Regards,
Nate Temple


On Fri, Feb 15, 2019 at 2:17 PM Nate Temple  wrote:

> Hi Joshua,
>
> The Jackson Labs based GPSDOs (for B2xx, X3xx and N3xx, E320) are all
> ready for the GPS roll over event. We dont expect any issues with the JL
> GPSDOs until 2028 and later. Depending upon when the units were
> manufactured it is out until 2038.
>
> I'll need to look into the Ublox on the E310.
>
> Regards,
> Nate Temple
>
>
> On Fri, Feb 15, 2019 at 1:29 PM Sirkin, Joshua F. via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I was wondering if Ettus or anyone on this listserve has tested their
>> products to make sure that no issues are going to come up with the gps week
>> rollover in April?
>>
>>
>> https://www.orolia.com/resources/blog/lisa-perdue/2018/gps-2019-week-rollover-what-you-need-know
>>
>> The product that would worry me the most potentially is the E310 and how
>> the UBLOX gps and how GPSD deal with the rollover, but I would also want to
>> try to be prepared for any issues with the B or X series products that use
>> a gpsdo.
>>
>> 
>>  This message is intended only for the use of the individual or entity to
>> which it is addressed and may contain ZETA Associates confidential or
>> proprietary information. If you are not the intended recipient, any use,
>> dissemination, or distribution of this communication is prohibited. If you
>> have received this communication in error, please notify the sender and
>> delete all copies.
>>
>> ___
>> 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] GPS week rollover readiness?

[Nate Temple via USRP-users]

Hi Joshua,

The Jackson Labs based GPSDOs (for B2xx, X3xx and N3xx, E320) are all ready
for the GPS roll over event. We dont expect any issues with the JL GPSDOs
until 2028 and later. Depending upon when the units were manufactured it is
out until 2038.

I'll need to look into the Ublox on the E310.

Regards,
Nate Temple


On Fri, Feb 15, 2019 at 1:29 PM Sirkin, Joshua F. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I was wondering if Ettus or anyone on this listserve has tested their
> products to make sure that no issues are going to come up with the gps week
> rollover in April?
>
>
> https://www.orolia.com/resources/blog/lisa-perdue/2018/gps-2019-week-rollover-what-you-need-know
>
> The product that would worry me the most potentially is the E310 and how
> the UBLOX gps and how GPSD deal with the rollover, but I would also want to
> try to be prepared for any issues with the B or X series products that use
> a gpsdo.
>
> 
>  This message is intended only for the use of the individual or entity to
> which it is addressed and may contain ZETA Associates confidential or
> proprietary information. If you are not the intended recipient, any use,
> dissemination, or distribution of this communication is prohibited. If you
> have received this communication in error, please notify the sender and
> delete all copies.
>
> ___
> 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] [Discuss-gnuradio] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Nate Temple via USRP-users]

Hi Andre,

The one example I can give at this time is limited and semi-anecdotal as
I've only tested it on a single machine.

With an i7-4790k / Intel x520-DA2 and N310, to stream at full duplex, over
two channels at 125 MS/s, the lowest I can run my CPU clock freq at without
flow control errors is 3.8 GHz using benchmark_rate and the native
networking stack. Using DPDK I can run 2x2 @ 125 MS/s with my CPU freq
locked at 1.5 GHz with no flow control errors.

Regards,
Nate Temple

On Thu, Feb 14, 2019 at 3:57 AM Andre Puschmann <
andre.puschm...@tu-ilmenau.de> wrote:

> Hey guys,
>
> any idea or numbers on the performance improvement using DPDK, e.g. CPU
> usage during rx/tx streaming, when compared to the legacy approach?
> Would be great to get a feeling for the achievable gains.
>
> Thanks
> Andre
>
>
> On 13/2/19 20:58, Nick Foster via USRP-users wrote:
> > Any plans to update to the latest API? Won't compile with anything after
> > 17.05.
> >
> > On Wed, Feb 13, 2019, 11:33 AM Michael West
> >  > > wrote:
> >
> > Hi Nick,
> >
> > Information on using DPDK can be found here:
> > http://files.ettus.com/manual/page_dpdk.html
> >
> > DPDK can be used with any example.  Think of it as an accelerator
> > for Ethernet transports if using Intel NICs.
> >
> > Regards,
> > Michael
> >
> > On Thu, Feb 7, 2019 at 10:29 AM Nick Foster
> >  > > wrote:
> >
> > Great news! DPDK support is an interesting development. Is there
> > any documentation or examples which show this capability?
> >
> > Nick
> >
> >
> > On Thu, Feb 7, 2019 at 10:05 AM Michael West via USRP-users
> >  > > wrote:
> >
> > The release candidate of UHD version 3.14.0.0 has been
> > tagged and is available for testing.  This API release
> > introduces support for the N320 and N321 USRPs soon to be
> > released (watch for the announcement on ettus.com
> > !), a DPDK-based transport, and several
> > other features and bug fixes.  This release includes all bug
> > fixes and enhancements in the 3.13.0.1, 3.13.0.2, and
> > 3.13.1.0 maintenance releases.
> >
> > The tag for this release candidate:
> >
> https://github.com/EttusResearch/uhd/releases/tag/v3.14.0.0-rc1
> >
> > There have been 406 commits since the last API release
> > (3.13.0.0)which can be viewed here:
> >
> https://github.com/EttusResearch/uhd/compare/v3.13.0.0...v3.14.0.0-rc1
> >
> > Please report any bugs found on the UHD issue tracker:
> > http://github.com/EttusResearch/uhd/issues
> > * Please do not use the issue tracker for help or support.
> >
> > Pull requests for direct code changes may be submitted to
> > the UHD or FPGA repositories:
> > http://github.com/EttusResearch/uhd/pulls
> > http://github.com/EttusResearch/fpga/pulls
> >
> > CHANGELOG:
> > ## 003.014.000.000
> > * N320: Add N320 and N321
> > * Test: Add Python API test
> > * Device3: Move from packet-based to byte-based flow control
> > * X300: Reduce default send_frame_size to 4000 over Ethernet
> > * UHD: Release recv buffers earlier in rx_streamer
> > * Device3: Constrain send_buff_size to input fifo size
> > * X300: Change Ethernet buffering
> > * MPMD: Parallelize broadcast-finding
> > * Device: Parallelize device discovery
> > * Docs: Fix Doxygen warnings
> > * B100: Move fifo_ctrl_excelsior to b100 subdir
> > * B100: Fix fifo_ctrl_excelsior not exiting
> > * B100: Remove all Boostisms from fifo_ctrl_excelsior
> > * B100: Demote some clocking-related log messages to trace
> > * X300: Log git hash and compat number as debug message
> > * N310: Modify AD9371 reset function to keep it in reset
> > * N3xx: clocking API changes for transitioning clock and
> > time sources
> > * E320: bist: Fix ref_clock lock test implementation
> > * UHD: Fix ADF400x driver for ref counter and charge pump
> mode
> > * E320: bist: Add link_up test
> > * MPM: Get list of temperatures from all thermal zones
> > * E320: Add all 5 temp sensors, fan sensor and rssi sensors
> > per channel
> > * E320: Fix tx/rx atr - antenna and frequency settings
> > * E320: Enable devtest for E320
> > * X300: Move defaults to their own header
> > * UHD: Improve constrained_device_args_t
> > * X300: Use constrained_args
> > * X300: Enable clock_source and time_source device 

Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1

[Nate Temple via USRP-users]

Hi Robert,

Can you send the output of:

tree /sys/kernel/iommu_groups/

Do you have an external GPU installed on your system?

Regards,
Nate Temple



On Fri, Feb 8, 2019 at 9:13 AM  wrote:

> Hi Nate,
>
>
>
> thanks for the quick reply. I changed the dpdk-driver and copied the
> config file to /root/.uhd/uhd.conf. MAC addresses are correct. Started
> benchmark_rate as root this time, without using sudo. Still get the same
> error.
>
>
>
> Robert
>
>
>
> *From:* Nate Temple [mailto:nate.tem...@ettus.com]
> *Sent:* Friday, February 08, 2019 5:58 PM
> *To:* Pöhlmann, Robert
> *Cc:* Nick Foster; Michael West; USRP-users@lists.ettus.com
> *Subject:* Re: [USRP-users] [UHD] Announcing 3.14.0.0 Release Candidate 1
>
>
>
> Hi Robert,
>
> Can you try adding the NIC configuration to /root/.uhd/uhd.conf instead of
> /etc/uhd/uhd.conf ? You'll need to run your UHD applications as root as
> well.
>
> You will also need to change the line:
>
> dpdk-driver=/usr/local/lib/dpdk-pmds/
>
> to be:
>
> dpdk-driver=/usr/lib/x86_64-linux-gnu/
>
> You'll also need to update the MAC addresses for your NICs.
>
>
> With the config setup, you'll see the NICs come up like this when running
> a UHD application:
>
> ...
> PMD: ixgbe_dev_link_status_print():  Port 0: Link Down
> EAL: Port 0 MAC: xx xx xx xx xx xx
> EAL: Port 0 UP: 1
> PMD: ixgbe_dev_link_status_print():  Port 1: Link Down
> EAL: Port 1 MAC: xx xx xx xx xx xx
> EAL: Port 1 UP: 1
> EAL: Init DONE!
> EAL: Starting I/O threads!
> USER2: Thread 1 started
> [00:00:00.03] Creating the usrp device with:
> ...
>
> We'll be updating the DPDK docs to reflect a few of these changes before
> the final 3.14 release.
>
> Regards,
> Nate Temple
>
>
>
> On Fri, Feb 8, 2019 at 6:40 AM Robert via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
> I found this wiki page on DPDK:
> https://files.ettus.com/manual/page_dpdk.html
>
>
>
> Tried to follow the described steps on Xubuntu 18.04 with UHD
> v3.14.0.0-rc1 (also updated SD and FPGA image) and Intel X520DA, but no
> success so far.
>
>
>
> -  IOMMU is enabled for NIC, checked with short bash script:
>
> #!/bin/bash
>
> shopt -s nullglob
>
> for d in /sys/kernel/iommu_groups/*/devices/*; do
>
> n=${d#*/iommu_groups/*}; n=${n%%/*}
>
> printf 'IOMMU Group %s ' "$n"
>
> lspci -nns "${d##*/}"
>
> done;
>
>
>
> shows:
>
>
>
> IOMMU Group 0 00:00.0 Host bridge [0600]: Intel Corporation Device
> [8086:3ec2] (rev 07)
>
> IOMMU Group 10 00:1d.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #9 [8086:a298] (rev f0)
>
> IOMMU Group 11 00:1f.0 ISA bridge [0601]: Intel Corporation Device
> [8086:a2c9]
>
> IOMMU Group 11 00:1f.2 Memory controller [0580]: Intel Corporation 200
> Series PCH PMC [8086:a2a1]
>
> IOMMU Group 11 00:1f.3 Audio device [0403]: Intel Corporation 200 Series
> PCH HD Audio [8086:a2f0]
>
> IOMMU Group 11 00:1f.4 SMBus [0c05]: Intel Corporation 200 Series PCH
> SMBus Controller [8086:a2a3]
>
> IOMMU Group 12 00:1f.6 Ethernet controller [0200]: Intel Corporation
> Ethernet Connection (2) I219-V [8086:15b8]
>
> IOMMU Group 13 04:00.0 Network controller [0280]: Intel Corporation
> Wireless 8265 / 8275 [8086:24fd] (rev 78)
>
> IOMMU Group 14 3e:00.0 Non-Volatile memory controller [0108]: Samsung
> Electronics Co Ltd Device [144d:a808]
>
> IOMMU Group 1 00:01.0 PCI bridge [0604]: Intel Corporation Skylake PCIe
> Controller (x16) [8086:1901] (rev 07)
>
> IOMMU Group 1 01:00.0 Ethernet controller [0200]: Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>
> IOMMU Group 1 01:00.1 Ethernet controller [0200]: Intel Corporation
> 82599ES 10-Gigabit SFI/SFP+ Network Connection [8086:10fb] (rev 01)
>
> IOMMU Group 2 00:02.0 VGA compatible controller [0300]: Intel Corporation
> Device [8086:3e92]
>
> IOMMU Group 3 00:14.0 USB controller [0c03]: Intel Corporation 200 Series
> PCH USB 3.0 xHCI Controller [8086:a2af]
>
> IOMMU Group 3 00:14.2 Signal processing controller [1180]: Intel
> Corporation 200 Series PCH Thermal Subsystem [8086:a2b1]
>
> IOMMU Group 4 00:16.0 Communication controller [0780]: Intel Corporation
> 200 Series PCH CSME HECI #1 [8086:a2ba]
>
> IOMMU Group 5 00:17.0 SATA controller [0106]: Intel Corporation 200 Series
> PCH SATA controller [AHCI mode] [8086:a282]
>
> IOMMU Group 6 00:1b.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #17 [8086:a2e7] (rev f0)
>
> IOMMU Group 7 00:1c.0 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #1 [8086:a290] (rev f0)
>
> IOMMU Group 8 00:1c.2 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #3 [8086:a292] (rev f0)
>
> IOMMU Group 9 00:1c.4 PCI bridge [0604]: Intel Corporation 200 Series PCH
> PCI Express Root Port #5 [8086:a294] (rev f0)
>
>
>
>
>
> -  hugepages are available and free according to cat
> /proc/meminfo | grep Huge:
>
> AnonHugePages: 0 kB
>
> ShmemHugePages:0 kB
>
> 

Re: [USRP-users] Utilisation of core RFNoC Image

[Nate Temple via USRP-users]

Hi Andrew,

Please take note of this section of the KB with regards to FPGA
modifications: https://kb.ettus.com/X300/X310#FPGA_User_Modifications

The PCIe interface and LvFpga_Chinch_Interface cannot be modified, even if
you are not using PCIe as a transport, as it will brick the flash memory:
https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/x300/x300.v#L656

As Leandro mentioned, removing the DDC/DUCs will result in the most gains.
You could possibly adjust the HB and max CIC within the DDC/DUC to reduce
utilization at the cost of reducing your resampling range.

Regards,
Nate Temple

On Tue, Jan 29, 2019 at 11:55 AM Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey Andrew,
>
> Have you confirmed the available resources are not enough for your
> purpose?
> If so, I'd suggest you run the build command with the GUI option on,
> implement the design using the Vivado interface, and run a
> post-implementation utilization report to see which blocks are consuming
> the most. Still, there is not much that can be taken away without bricking
> the core, but if I recall correctly removing the DDCs and DUCs could
> release about 5 or 10% of the resources. This would, of course, reduce the
> functionality, forcing you to run the device at full rate all the time.
>
> Regards,
>
> Leo
>
> On Tue, Jan 29, 2019 at 4:15 PM Andrew Thommesen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> I was wondering if there is any way to reduce the resources used by the
>> default RFNoC image. It currently utilises ~50% of the Kintex-7 FPGA of the
>> Ettus X310, and I want to make more resources available (LUTs and FFs
>> mainly) for bespoke firmware development.
>>
>> Thanks,
>>
>> Andy
>>
>> Sent from Outlook 
>> ___
>> 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] Live rate changes within an RFNOC block

[Nate Temple via USRP-users]

Hi Andrew,

This is an issue we are aware of related to the RFNoC DDC/DUC blocks. We
are working on a fix and expect to have in a future release of UHD.

Regards,
Nate Temple

On Mon, Jan 28, 2019 at 10:11 AM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I have an RFNOC block that, based on a control register can either
> decimate the signal it's working on or leave the output rate the same as
> the input rate. If I set the control register to an initial value (either
> decimate, or not decimate) and let the system run, it works fine in either
> mode. If I try to change the decimation mode while the block is running, I
> start getting timeout errors. I currently use the axi_rate_change block to
> help handle the rate change, and have tried to synchronize changing the
> block's mode (decimate or not) with the axi_rate_change's clear_user flag.
> Any thoughts?
>
> Thanks,
> Andrew
>
> --
> Information contained, linked, or attached to this email and all verbal
> communications from WhiteFox Defense to your entity in the prior 30 days
> constitute proprietary and confidential information unless otherwise
> indicated and is therefore subject to obligations in any executed
> confidentiality agreements. Further, this email is intended solely for the
> use of the individual or entity to whom they are addressed. If you are not
> the intended recipient and this message has been addressed to you in error,
> please promptly notify i...@whitefoxdefense.com and destroy all copies of
> the message and any attachments. This email and attachments may contain
> technical data as defined in the International Traffic In Arms Regulations
> (ITAR) 22 CFR 120.10 or the Export Administration Regulations (EAR) 15 CFR
> Parts 730 – 780.  Export of this material may be controlled by these
> regulations and may not be exported or transferred to non-U.S. persons
> without prior written approval from the U.S. government.
> ___
> 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] Issues with N300 - GPSDO Lock/Synchronization, Spectrum asymmetry, MPM performance and Low band phase

[Nate Temple via USRP-users]

Hi Sam,

These are all new issues that we were unaware of. I will follow up with you
off list to debug these issues through your previously sent email to
supp...@ettus.com.


Regards,
Nate Temple

On Fri, Jan 25, 2019 at 2:13 PM Samuel Prager via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> We are experiencing a number of issues with our N300s. We would like to
> know if these are known issues and whether or not they are being addressed.
>
> We have recently updated the filesystems, FPGA images and UHD/MPM to
> 3.13.1 (currently up to date with UHD 3.13.1 release, commit 711ec8a). We
> are using our N300s in embedded mode. All software/rfnoc firmware has been
> previously tested and used on X300s and E312s.
>
> I have uploaded a few supporting images to a google drive folder. (Link:
> https://drive.google.com/drive/folders/1b1T69G7AAA2-QlIByBYp9UQ_gs8_1253?usp=sharing
> )
>
>
> 1) GPSDO Locking and Synchronization:
>
> - The time to obtain and GPS lock, even when outside is long and often
> unstable. Code used to query GPSDO lock:
>
> *uhd::property_tree::sptr tree = _usrp->get_tree();*
> *uhd::fs_path path;*
> *std::vector mboard_names = tree->list("/mboards");*
> *path = "/mboards/" + mboard_names[0];*
> *try {*
> *path = "/mboards/" + mboard_names[0];*
> *try {*
> * tree->access(path / "sensors" / "gps_locked").get().value;*
> *} catch (std::exception &) {*
> *} catch (std::exception &) {*
> * std::cerr << "Error: No response from GPSDO" << std::endl;*
> * return false;*
> *}*
> *//Check for GPS lock*
> *uhd::sensor_value_t gps_locked = tree->access(path / "sensors" /
> "gps_locked").get();*
> *return(gps_locked.to_bool());*
> *}*
>
>
> This is a printout of the N300 sensor values when GPSDO is in a non-locked
> state:
>
> *- Sensors -*
> *Clock Source: gpsdo*
> *Time Source: gpsdo*
> *ref_locked: true*
> *gps_locked: false*
> *gps_time: 1548206414*
> *gps_tpv: {"ept": 0.0050001, "speed": 3.7042,
> "epv": 73.594, "device": "/dev/ttyPS1", "eps":
> 141.210001, "lon": -118.169881667, "epy": 109.009, "epx": 101.339,
> "alt": 367.69, "lat": 34.20062666702, "class": "TPV",
> "epc": 92.0, "track": 318.0, "time": "2019-01-23T01:20:14.000Z", "mode": 3,
> "climb": 32.203}*
> *gps_sky: {"hdop": 9.3007, "class": "SKY", "device":
> "/dev/ttyPS1", "pdop": 9.8007, "vdop": 3.2002,
> "ydop": 7.2696, "tdop": 3.6201, "gdop": 11.09,
> "satellites": [{"PRN": 30, "az": 53, "el": 71, "ss": 26, "used": false},
> {"PRN": 28, "az": 327, "el": 67, "ss": 0, "used": false}, {"PRN": 135,
> "az": 205, "el": 47, "ss": 34, "used": false}, {"PRN": 7, "az": 101, "el":
> 44, "ss": 33, "used": true}, {"PRN": 17, "az": 188, "el": 44, "ss": 32,
> "used": true}, {"PRN": 13, "az": 308, "el": 38, "ss": 0, "used": false},
> {"PRN": 11, "az": 80, "el": 32, "ss": 34, "used": true}, {"PRN": 1, "az":
> 99, "el": 17, "ss": 27, "used": false}, {"PRN": 19, "az": 199, "el": 17,
> "ss": 28, "used": true}, {"PRN": 18, "az": 70, "el": 14, "ss": 28, "used":
> true}, {"PRN": 8, "az": 39, "el": 11, "ss": 0, "used": false}, {"PRN": 9,
> "az": 164, "el": 10, "ss": 27, "used": false}, {"PRN": 15, "az": 321, "el":
> 7, "ss": 0, "used": false}, {"PRN": 5, "az": 255, "el": 4, "ss": 0, "used":
> false}], "xdop": 6.7598}*
> *fan: 4320*
> *temp: 42.0*
>
>
> This is a printout of the N300 sensor values when GPSDO is in a locked
> state:
>
> *- Sensors -*
> *Clock Source: gpsdo*
> *Time Source: gpsdo*
> *ref_locked: true*
> *gps_locked: true*
> *gps_time: 1548215759*
> *gps_tpv: {"lat": 34.200188333, "class": "TPV", "speed": 0.0, "device":
> "/dev/ttyPS1", "epv": 112.7, "ept": 0.0050001, "alt":
> 341.12, "mode": 3, "time": "2019-01-23T03:55:57.000Z", "climb":
> 0.69996, "lon": -118.169401667, "epc": 225.41,
> "track": 148.09}*
> *gps_sky: {"hdop": 3.2998, "class": "SKY", "satellites":
> [{"used": false, "el": 80, "az": 318, "PRN": 19, "ss": 12}, {"used": false,
> "el": 58, "az": 32, "PRN": 17, "ss": 13}, {"used": true, "el": 49, "az":
> 199, "PRN": 133, "ss": 35}, {"used": false, "el": 47, "az": 205, "PRN":
> 135, "ss": 31}, {"used": true, "el": 42, "az": 159, "PRN": 6, "ss": 31},
> {"used": false, "el": 36, "az": 311, "PRN": 24, "ss": 0}, {"used": true,
> "el": 35, "az": 75, "PRN": 28, "ss": 29}, {"used": true, "el": 24, "az":
> 221, "PRN": 13, "ss": 32}, {"used": false, "el": 19, "az": 258, "PRN": 15,
> "ss": 17}, {"used": false, "el": 17, "az": 189, "PRN": 2, "ss": 23},
> {"used": false, "el": 16, "az": 146, "PRN": 30, "ss": 21}, {"used": false,
> "el": 8, "az": 290, "PRN": 12, "ss": 15}, {"used": false, "el": 5, "az":
> 35, "PRN": 1, "ss": 0}], "vdop": 4.9004, "device":
> "/dev/ttyPS1", "pdop": 5.9004}*
> *fan: 4320*
> *temp: 38.0*
>
>
> We note that 

Re: [USRP-users] E310 something or other

[Nate Temple via USRP-users]

Hi Steve,

Those application notes are outdated. We are working on updating them
currently and expect to have the new versions posted soon.

I'll follow up with you off list with a set of instructions using a newer
version of UHD.

Regards,
Nate Temple

On Mon, Jan 21, 2019 at 9:43 AM Steve Clift via USRP-users <
usrp-users@lists.ettus.com> wrote:

> We are working on an application that involves development of an RFNOC
> module to be used in the Gnuradio environment. What is the recommended way
> to build working, compatible versions of UHD (with RFNOC), Gnuradio and
> gr-ettus for the E310? So far we are not having much luck.
>
>
>
> We have tried following
>
>
>
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
>
>
> which uses PyBOMBS recipe e3xx-rfnoc. That fails during the Gnuradio cmake
> runs because the Python “six” module is not included in the
> cross-development environment. This can be worked around by installing six
> while PyBOMBS is busy compiling UHD, but Gnuradio compilation then fails,
> apparently because an incompatible version of volk is checked out.
>
>
>
> Also
>
>
> https://kb.ettus.com/Software_Development_on_the_E3xx_USRP_-_Building_RFNoC_UHD_/_GNU_Radio_/_gr-ettus_from_Source
>
>
>
> The git clone command for UHD probably should include the –recursive
> option to have the FPGA source submodule included in the UHD tree,
> presumably with a compatible commit. The version of Gnuradio is limited to
> 3.7.13.4 or earlier because later versions require a more recent version of
> cmake than that in the cross-development environment. FPGA bit files built
> from this setup fail to load with uhd_usrp_probe, which reports a CODEC
> loopback test failure.
>
>
>
> There is more, but for the sake of brevity, I’ll stop there.
>
>
>
> What to do?
>
>
>
> Thanks, Steve
> --- CONFIDENTIALITY NOTICE: This
> email and any attachments are for the sole use of the intended recipient
> and may contain material that is proprietary, confidential, privileged or
> otherwise legally protected or restricted under applicable government laws.
> Any review, disclosure, distributing or other use without expressed
> permission of the sender is strictly prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies without
> reading, printing, or saving..
> ___
> 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] Python uhd API

[Nate Temple via USRP-users]

Hi Luz,

You can call the api calls just as you would in C++ from the usrp object.

For example:

usrp = uhd.usrp.MultiUSRP(args.args)

usrp.set_clock_source("external")
usrp.set_time_source("external")

Regards,
Nate Temple

On Wed, Jan 16, 2019 at 2:51 PM Florez Manduca, Luz E CIV USARMY (USA) via
USRP-users  wrote:

> Does anyone have any sample python uhd API code to select the clock source
> (internal, external, GPSDO)? The UHD manual has no documentation on the
> python uhd APIs (only the C++ ones and I am quite lost there). Any
> suggestion would be greatly appreciated.
>
> Thank you very much.
>
> Sincerely.
>
> Luz Elena (Luchi) Florez Manduca (formerly Roth)
> R Electrical Engineer
> US Army Armament Research Development & Engineering Center
> Precision Armaments & Intelligent Sensors Division
> Munition Sensors Branch
> RDAR-MEF-P, Bldg 407 Buffington Road, Picatinnny Arsenal, NJ 07806-5000
> Desk 973-724-6618
> Cell 267-884-9517
> New Home 267-247-5839
> luz.e.florezmanduca@mail.mil
>
>
>
> ___
> 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] Device String for external clock source USRP N210

[Nate Temple via USRP-users]

Hi Andre,

GQRX uses gr-osmosdr under the hood to interface to the USRP, the setters
and getters are there [0] to set the sources for an external ref/timing
source, but it does not parse the device arg to set them [1].  If you add
the parsing and rebuild gr-osmosdr and then GQRX, it will work.

https://github.com/osmocom/gr-osmosdr/blob/master/lib/uhd/uhd_source_c.cc#L392-L437
https://github.com/osmocom/gr-osmosdr/blob/master/lib/uhd/uhd_source_c.cc#L51-L127


Regards,
Nate Temple

On Wed, Jan 9, 2019 at 5:05 PM Andre Kraller via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hello,
>
> i tried to get the N210  working with external clock source on GQRX by
> adding the following to the device string:
>
> *clock_source*=*external*
>
> *But it is not working.*
>
> *With gnuradio the external clock source is working fine.*
>
> *Please, anyone can help me?*
>
>
> ___
> 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] synchronizing multiple USRP N310

[Nate Temple via USRP-users]

Hi Florian,

If you pass the arg  "--ref external" to tx_waveforms, does it resolve this
frequency offset?

https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L62

Regards,
Nate Temple

On Thu, Dec 6, 2018 at 12:22 AM Florian Kaltenberger via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Marcus,
>
> I have measured this with a spectrum analyzer simply by setting markers to
> the peak of the sinusoid (one marker per measured USRP) and then taking the
> delta.
>
> Could it be that the USRP is ignoring the external reference when used
> alone? Remember, I am doing the test with one USRP at a time, as the test
> using multiple USRP simultaneously does not work.
>
> Florian.
> On 06/12/2018 00:29, Marcus Müller wrote:
>
> oh! That means 341 ppb frequency error, which *really* shouldn't be
> happening.
>
> I'd like to get some statistics of that error, how are you measuring
> it?
>
> Best regards,
> Marcus
>
> On Wed, 2018-12-05 at 12:55 +0100, Florian Kaltenberger wrote:
>
> Sorry typo. I did use a frequency of 3.51GHz.
>
>
> On 5 Dec 2018, at 12:54, Marcus Müller  
> 
> wrote:
>
> Hi Florian,
>
> trying to get my head to understand the order of problems here:
> Could you try to use a higher frequency (say, --freq 2e9 instead of
> 3.5e6)?
> I'd thing 3.51 MHz is out of range for the N310, anyway?
>
> Best regards,
> Marcus
>
> On Wed, 2018-12-05 at 11:49 +0100, Florian Kaltenberger via USRP-
> users
> wrote:
>
> So I can confirm that there is a frequency offset between the two
> USRP N310s when using only an octoclock (10MHz + PPS) to
> synchronize.
> I have measured with the tx_waveforms program
> ./tx_waveforms --args
> "addr=192.168.x.2,time_src=external,clock_src=external,master_clo
> ck_r
> ate=122.88e6" --rate 122.88e6 --freq 3.51e6 --wave-type SINE --
> wave-
> freq 10e6 --gain 100
> on the first USRP N310 (x=10) and then on the other (x=20). There
> is
> an offset of 1200Hz between the peaks of the sinusoids between
> the
> two measurements.
> Using an external LO didn't change anything either. Unless I need
> to
> provide any other arguments in that case?
> I also tried to do a test where I use both USRPs simultaneously
> ./tx_waveforms --args
> "addr0=192.168.10.2,addr1=192.168.20.2,time_src=external,clock_sr
> c=ex
> ternal,master_clock_rate=122.88e6" --rate 122.88e6 --freq 3.51e6
> --
> wave-type SINE --wave-freq 10e6 --gain 100--channels "0,4"
> but unfortunately that does not work at all at my testbench
> (program
> hangs and no signal transmitted).
> My UHD version is 3.13.0.2 (UHD_3.13.0.HEAD-0-g0ddc19e5)
> Any help appreciated.
> Thanks!
> Florian.
>
>
> On 04/12/2018 21:29, Florian Kaltenberger via USRP-users wrote:
> Hi Marcus and Robin,
> thanks for your answers, this is helpful information. I should
> add,
> that I actually tried the synchronization with an octoclock
> (10MHz
> + PPS), but it did not give me the expected results, i.e., I
> saw
> some residual frequency offsets. But maybe I screwed up at some
> point. Let me do some more measurements and get back to you on
> this.
> Florian.
>
>
> On 04/12/2018 18:57, Marcus D. Leech via USRP-users wrote:
> On 12/04/2018 10:14 AM, Florian Kaltenberger via USRP-users
> wrote:
>
> Hi there,
> I just discovered that in addition to the external 10MHz
> reference in, the USRP N310 also has external local
> oscilator
> inputs, one for each daughterboard and each TX/RX. So does
> that
> mean that in order to synchronize multiple N310 in
> frequency,
> phase, and time, it is no longer sufficient to use an
> octoclock
> to provide a 10MHz reference and PPS? If so, at what
> frequency
> do you have to drive the external LOs and at what power?
> Florian.
>
>
> In addition to what Robin posted, I'll observe that the
> external
> LO port is an *additional feature* of this device.
>
> You should still be able to use the external 10MHz and 1PPS
> ports
> the same way you would with a B210 or E310, since the AD9371
>  front-end chip is similar to the AD9361 chip used in the
> B210
> and E310.
>
> The thing about synchronizing multiple independent PLL
> synthesizers, though, compared to a strictly-shared-LO, is
> that
> the former will
>  experience both phase ambiguities, and have a higher mutual
> phase-noise than the latter, which is why you might decide to
> choose
>  the latter.
>
>
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Follow us on Google+, LinkedIn, or Twitter!
>
>
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Follow us on Google+, LinkedIn, or Twitter!
> ___
> USRP-users mailing 
> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> --
> Follow us 

Re: [USRP-users] get_rx_antenna() bug in RFNoC x300_radio_ctrl_impl.cpp

[Nate Temple via USRP-users]

Hi Rob,

Thanks for bringing this to our attention. We will file an issue on our
internal bug tracker and get it resolved.

Regards,
Nate Temple

On Fri, Nov 16, 2018 at 10:41 AM Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I am using the RFNoC radio_ctrl API with my X310 and when I call
> get_rx_antenna() , I get an empty string.  The problem is in
> x300_radio_ctrl_impl.cpp.  The corresponding set_rx_antenna() function
> should be calling the base class radio_ctrl_impl->set_rx_antenna() so that
> the locally cached value is updated.  But, this call is missing.  Thus, any
> call to get_rx_antenna() which is not overridden for the X310 always
> returns an empty string.
> 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

Re: [USRP-users] N310 Rack mount Kit

[Nate Temple via USRP-users]

Hi David,

You can find the N3xx rack mount kit here:
https://www.ettus.com/product/details/n3xx-rack-mount

Regards,
Nate Temple

On Fri, Nov 16, 2018 at 8:19 AM Bengtson, David E. via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Is there a 19” Rack mount Kit for the N310 available or planned?
>
> Thanks
>
> Dave
>
>
>
>
> ___
> 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] N3xx operational questions

[Nate Temple via USRP-users]

Hi EJ,

Thanks for the detailed report. We are working on addressing these issues
and will follow up with a more detailed response soon.

Regards,
Nate Temple

On Wed, Oct 24, 2018 at 3:01 PM, EJ Kreinar via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I've been working with the N3xx series for a week or so and I've hit a few
> issues in the "operational" side of things that are either not addressed in
> the manual or work differently than expected. I'll just handle this as a
> "laundry list" of items/issues...
>
> To start, I've been directly testing on the N300 so far. I reflashed the
> N300 SD card with version UHD-3.13.02 last week.
>
> 1. As a heads up, and I'm sure you're aware, I've had a fair bit of
> trouble coordinating the uhd_images_downloader with the correct images...
> First, when I originally built UHD-3.13.0.0 as described in the manual,
> there's no images provided for 3.13.0.0. I just noticed today that if I
> update to UHD-3.13 branch (currently 3.13.0.3) and run the downloader, it
> tries to pull images for 3.13.0.2, which is likely incompatible with the
> 3.13.0.3 head (noc shell seems to be updated to version 3 in the most
> recent 3.13.0.3).
>
> 2. I keep running into a number of issues trying to download new FPGA
> images. Could someone explain the mechanics of FPGA loading for N3xx? I'm
> assuming this is similar to X310, however I would have expected that a
> zynq-based platform would simply program to /dev/xdevcfg like the E310.
>
> More tactically, I have a few issues when trying to download FPGA images.
> If I run a "host mode update", then I get an unexpected error:
>
> ```
> $ uhd_image_loader --args "type=n3xx,addr=10.1.151.245"
> --fpga-path=n3xx.bit
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.13.0.3-14-gd1555232
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=10.1.151.245,type=n3xx,product=n300,serial=
> 3145FF4,claimed=False,skip_init=1
> [INFO] [MPMD] Claimed device without full initialization.
> [WARNING] [MPMD IMAGE LOADER] RuntimeError: Component file does not exist:
> /home/ejk/fpga-build/he360-fpga-builder/src/uhd-fpga/
> usrp3/top/n3xx/build-N300_RFNOC_HG/n3xx.dts
> [INFO] [MPMD IMAGE LOADER] Starting update. This may take a while.
> [ERROR] [UHD] An unexpected exception was caught in a task loop.The task
> loop will now exit, things may not work.rpc::timeout: Timeout of 5000ms
> while calling RPC function 'get_log_buf'
> [INFO] [MPM.PeriphManager] Device serial number: 3145FF4
> [INFO] [MPM.PeriphManager] Initialized 1 daughterboard(s).
> [INFO] [MPM.PeriphManager] init() called with device args `'.
> Error: rpc::timeout: Timeout of 2ms while calling RPC function
> 'update_component'
> ```
>
> Fortunately, this error appears that it doesnt materially impact anything,
> and I can now probe the FPGA successfully afterwards.
>
> When trying to load FPGA images in embedded mode, first, I get an error
> when running uhd_images_downloader that suggests argparse is not installed
> into the rootfs:
>
> ```
> root@ni-n3xx-3145FF4:~# uhd_images_downloader
> Traceback (most recent call last):
>   File "/usr/bin/uhd_images_downloader", line 11, in 
> import argparse
> ImportError: No module named argparse
> ```
>
> Oddly, pip3 seems to be installed, and I can run `pip3 install argparse`
> but there's no pip or python2 argparse :(
>
> Anyway, if I scp a relevant image onto the N300 PS, I get a similar issue
> as over network mode.
>
> At one point, I found fpga programming in embedded mode crashed the N300
> and require a hard reboot, but I cant recreate that right now so I'll leave
> that off my list.
>
> 3. Embedded mode vs host/network mode: Ideally, I would like to run the
> N3xx using both a high rate ethernet connection through the sfp's, and a
> connection to the Zynq PS over the RJ45. (not at the same time from the
> same program, but both ports physically connected)... However, I cannot
> succeed in switching between embedded mode and host mode without 1)
> physically unplugging the ethernet cables, or 2) taking down the IP
> interface that I'm not using at the moment. Is there a way to do this??
>
> To give a specific example of behavior I see, I've set up the N300 to
> boot with 1GigE connection on sfp0 and RJ45 on the eth0. From a host
> device, in network mode, I fail to probe the N300:
>
> ```
> $ uhd_usrp_probe --args "type=n3xx"
> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.13.0.HEAD-0-g0ddc19e5
> [INFO] [MPMD] Initializing 1 device(s) in parallel with args:
> mgmt_addr=10.1.151.60,type=n3xx,product=n300,serial=
> 3145FF4,claimed=False,addr=10.1.151.245
> [INFO] [MPM.PeriphManager] init() called with device args
> `mgmt_addr=10.1.151.60,product=n300'.
> [ERROR] [UHD] Exception caught in safe-call.
>   in ctrl_iface_impl<_endianness>::~ctrl_iface_impl() [with
> uhd::endianness_t _endianness = (uhd::endianness_t)0]
>   at 

Re: [USRP-users] n310 offset tuning seems broken

[Nate Temple via USRP-users]

Hi Bob,

What USRP / DB are you using?

Regards,
Nate Temple

On Thu, Sep 13, 2018 at 6:53 AM, Tillson, Bob (US) via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Running 3.13.0.0 on Windows.
>
>
>
> I have a flag in my app to enable/disable offset tuning.
>
>
>
> Application works properly and receives signal when not using offset
> tuning, but when I enable it and tell it to offset tune by 1 MHz, I get no
> signal on Rx.
>
>
>
> Worked fine on 3.9.2.
>
>
>
> Any known issues?
>
>
>
> Thanks,
>
> ___
> 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] GPS and frequency drift problems on TDMA receiver (E310)

[Nate Temple via USRP-users]

Hi David,

We would like to debug this off the mailing list. Could you please email us
at supp...@ettus.com with the device's serial number?


Regards,
Nate Temple

On Tue, Sep 4, 2018 at 8:31 AM, David Zamorano Fernández via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all!
>
> We have implemented a TDMA receiver using the GPS signal to discipline the
> internal clock of the E310 and thus reduce frequency deviations. The
> system works fine, but in some cases, frequency drifts appear and the slots
> start to be erroneous (wrong CRC). The number of visible satellites has
> also been controlled and abruptly goes from a high number (12-13) to a few
> (1-2) or even none.
>
> The GPS antenna is outside. The system has been tested with different
> antennas and the behavior has been the same.
>
> Is there any kind of known bug in the gps daemon related to this? Is
> there any other reason why this may be happening?
>
> I attached an image of a large message capture. You can see how there are
> three zones where the frequency drift starts to appear and the slots start
> to be erroneous (green circle = ok and red circle = error).
>
> --
>
>
> [image: logo_170x100px.png] 
>
>
>
> David Zamorano Fernández
> Investigador - Desarrollador | Área de Comunicaciones Avanzadas
> Researcher - Developer | Advanced Communications Department
>
>
>
> Ph. (+34) 986 120 430  Ext. 3012
> dzamor...@gradiant.org   |  www.gradiant.org
>
> [image: Iconos Redes Sociales GRD Firma email-01]
>   [image: Iconos Redes Sociales
> GRD Firma email-02]   [image: Iconos Redes
> Sociales GRD Firma email-03]
>   [image: Iconos Redes
> Sociales GRD Firma email-04]
> 
> Take care of the environment. Try not to print this email.
> The information contained in this email message may be confidential
> information, and may also be the subject of legal professional privilege.
> If you are not the intended recipient, any use, interference with,
> disclosure or copying of this material is unauthorized and prohibited.
> Please inform us immediately and destroy the email. Thank you for your
> cooperation.
>
> ___
> 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 software reset revisted

[Nate Temple via USRP-users]

Hi Jason,

This magic poke should do the trick:

python $UHD_INSTALL_DIR/firmware/usrp3/x300/x300_debug.py --addr=
--poke=0x100058 --data=1


Regards,
Nate Temple

On Mon, Jul 23, 2018 at 9:45 AM, Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:

> I've solved this with the USB JTAG interface and an external machine. An
> RPi will happily run Vivado Lab.
>
> AFAIK there are no plans to integrate a software reset into the X310.
>
> Nick
>
> On Mon, Jul 23, 2018 at 6:11 AM Jason Matusiak via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> I know it has been questioned many times on here, but I wanted to verify
>> something.  It has always been said that there is no way to do a software
>> reset on the X310; I am curious if that is "currently" or "ever?"
>>
>> I wasn't sure if there was a way to send a packet either via UHD or RFNoC
>> that could trigger a reset of some kind (this assumes that you have a
>> functioning X310 on the other end), and no one has had time to look into
>> it?  Or if it has been looked into and there truly is no way to do it.
>>
>> I have some situations where I cannot get to my X310s easily, so if I
>> need to reflash the bitfile (which is going to be necessary for RFNoC
>> flowgraphs, I will have to add an external appliance to get the job
>> done.  I was thinking about looking into it, but if it already has and was
>> deemed a non-starter, I don't want to waste the cycles.
>> ___
>> 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] N310 Subdevice Specification

[Nate Temple via USRP-users]

Hi Sarah,

For four channels on the N310 and UHD 3.11.0.1, the subdev spec will be
"A:0 B:0 C:0 D:0".

What sample rate are you running at ?

Regards,
Nate Temple



On Mon, Apr 23, 2018 at 6:50 PM, Sarah Tran via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi all,
>
>
>
> I recently got the N310, and I got one of the example programs from
> gr-digital to run on it. However because I didn’t specify a subdevice, it
> only uses one channel. I want to be able to TX on all 4 channels but I
> couldn’t get the right subdevice specification syntax correct. I tried “A:0
> B:0” just to get maybe two channels transmitting, but it just printed out a
> lot of ‘S’ and ‘L’s. I also tried the syntax for the E310 “A:A A:B” which
> didn’t work either. I know this is just my error, but I can’t find much
> documentation on the correct syntax to use! I am using UHD version 3.11 and
> GNU Radio 3.7.11.1. Any help is greatly appreciated!
>
>
>
>
>
> -Sarah Leony
>
>
>
> ___
> 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] Spurious emissions using B200

[Nate Temple via USRP-users]

Hi Carmine,

Can you please post a plot showing the spurious emissions you're seeing?

If possible, if you can include how you're generating the plots (the
script) would be useful as well.

What version of UHD are you using?

What color is the PCB of your B200?

What USRP are you using as a receiver ?

Regards,
Nate Temple

On Tue, Apr 10, 2018 at 1:09 AM, carmine via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear community,
>
> I implemented C++ codes of the transmitter and receiver using UHD API,
> starting from example provided by Ettus.
>
> Until now, I'm testing my codes using a coax cable for connecting the
> USRPs (a USRP used as transmitter and a USRP used as receiver).
>
> In this setup, just before the beginning of data transmission, I found two
> spurious emissions (around correlated 1 samples per times), which
> precede the data. I need to synchronize Tx and Rx, so this spurious
> emissions became a nightmare for me.
>
> My transmitter code is very easy:
> uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make("");
>
> //Lock mboard clocks
> usrp->set_clock_source("internal");
> //set the sample rate
> usrp->set_tx_rate(1000);
> //set the center frequency
> uhd::tune_request_t tune_request;
> tune_request = uhd::tune_request_t(24.0, 10.0);
> usrp->set_tx_freq(tune_request);
> //set the rf gain
> usrp->set_tx_gain(40);
> usrp->set_tx_bandwidth(1000);
> //set the antenna
> usrp->set_tx_antenna("TX/RX");
>
> boost::this_thread::sleep(boost::posix_time::seconds(1)); //allow for
> some setup time
>
> //Check Ref and LO Lock detect
> std::vector sensor_names;
> sensor_names = usrp->get_tx_sensor_names(0);
> if (std::find(sensor_names.begin(), sensor_names.end(), "lo_locked") !=
> sensor_names.end()) {
> uhd::sensor_value_t lo_locked = usrp->get_tx_sensor("lo_locked",0);
> std::cout << boost::format("Checking TX: %s ...") %
> lo_locked.to_pp_string() << std::endl;
> UHD_ASSERT_THROW(lo_locked.to_bool());
> }
> sensor_names = usrp->get_mboard_sensor_names(0);
>
> //create a transmit streamer
> uhd::stream_args_t stream_args("fc32", "sc16");
> uhd::tx_streamer::sptr tx_stream = usrp->get_tx_stream(stream_args);
>
> uhd::tx_metadata_t md;
> md.start_of_burst = true;
> md.end_of_burst = false;
>
> // Some operations for creating IQ samples stored in float tx_vec
>
> for(n_real=0;n_real<1000;n_real++) tx_stream->send((const
> void**)_vec[0], 80, md);
>
> I'm receiving the dump using the executable script rx_samples_to_file.
>
> Can anyone help me, please?
>
> Thanks in advance,
>
> Carmine
>
>
> ___
> 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] RF_NoC fosphor issue (Source IO size "8" does not match sink IO size "8192".)

[Nate Temple via USRP-users]

Hi Tarik,

If you press "F6" instead of the "Run" button, it will bypass this warning
and run the flowgraph.

Regards,
Nate Temple

On Mon, Mar 19, 2018 at 8:59 AM, Tarik Kazaz via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
>
> I am using USRP X310 with UBX-160MHz. I tried to run RFNoC fosphor demo,
> however I am getting errors related to connection of RFNoC:Radio to RFNoC:
> DDC and to RFNoC:Window (Source IO size "8" does not match sink IO size
> "8192"). I found this discussion on mailing list (from 2016)
> https://lists.gnu.org/archive/html/discuss-gnuradio/2016-03/msg00366.html.
> However, I did not manage to make it work.
>
>
> Could you please provide me more information which modifications I should
> do in order to make it work?
>
>
> KInd Regards
>
> ___
> 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] Multi N200 issues

[Nate Temple via USRP-users]

Hi Keith,

Can you please give UHD 3.9.7 or the 3.9-LTS branch of a try with your
setup?

What kind of CPU does your host have? What is the load profile while your
application is running?

Regards,
Nate Temple

On Thu, Mar 8, 2018 at 1:55 PM, Keith k via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hey all
>
> Just wondering if anyone had a chance to look at this for me. I'd
> appreciate it immensely! Thank you.
>
> On Fri, Mar 2, 2018 at 3:37 PM, Keith k  wrote:
>
>> Hello all
>>
>> I'm working on a project to use 16 N200s in a multi USRP configuration
>> for a radar project. They are synchronized using 3 Octoclocks (one master
>> with a GPSDO, and two slaves that drive the 16 N200s). I've been getting
>> many errors that I was hoping someone could help with. I have attached a
>> sample program that mimics how the USRPs are used. The basic goal here is
>> to sample a determined number of samples while transmitting some spaced
>> pulses (a "pulse sequence") and then repeat. It would be beneficial to have
>> as little delay as possible in between loops. I've been running into some
>> problems however.
>>
>> BASIC INFO
>>   We have 16 N200s + 1 spare
>>   3 Octoclocks (1 has gps and it drives the other two)
>>   LFTX and LFRX daughterboards in each N200
>>   linux; GNU C++ version 4.8.5; Boost_105400;
>> UHD_003.010.002.000-0-gbd6e21dc
>>   Intel Corporation Ethernet Controller 10-Gigabit X540-AT2
>>   Devices are all connected via 3 daisy chained Netgear XS708E switches
>>   Ideal sampling rates: 5-10MHz TX, 5-10MHz RX depending on
>> hardware/software limitations.
>>
>> One of the issues I sometimes get after several minutes of runtime (or
>> several thousand pulse sequences) is the overflow(O) with the out of
>> sequence flag set in the rx metadata. I also get sequence errors(S) on the
>> tx side too. It seems to happen more often and faster with higher sampling
>> rate. I've gathered from other mailing list posts that this is likely a
>> network configuration issue. Can someone recommend a known working computer
>> build and network configuration that can handle the amount of USRPs and
>> data we are attempting to use?
>>
>> Another major issue I eventually get during runtime is a slurry of
>> lates(L) on TX and then a LATE in the RX metadata. I've tried increasing
>> the time in the future that the TX/RX should start (from when the stream
>> commands are called) and I've tried to minimize the number of operations
>> happening between that calculation and when TX/RX start, but the lates
>> still eventually happen. I've tried to time profile what I can in my code
>> and it seems I should really only need about ~0.5ms of delay, but even at
>> 3-10ms of delay I have issues. I feel like 10ms of time should be more that
>> plenty of time for the host to issue stream commands. I don't seem to get
>> lates if I have test applications that individually test TX or RX, but when
>> I put them together using threads, I can't seem to find a way to eliminate
>> the lates. Any ideas on how I should set up what I'm trying to do here?
>>
>> Here is the compiler line to make the test program:
>> g++ -o test_rx_tx -std=c++11 -Wall test_rx_tx.cpp -lboost_system -luhd
>>
>> If I can explain anything in further detail please let me know.
>>
>> Thank you for your time.
>>
>> --
>> -Keith Kotyk
>>
>
>
>
> --
> -Keith Kotyk
>
> ___
> 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] B200 USB high CPU usage

[Nate Temple via USRP-users]

Hi Kasper,

There are several caveats/issues/topics to consider with regards to running
at higher sample rates with the B2xx. Generally speaking, Linux will offer
better performance than Windows.

What version of UHD are you using? If you're not using UHD 3.10.3.0, can
you please try upgrading? UHD 3.10.3.0 includes a commit [1] and updated
firmware, which optimizes the FX3 performance.

The i5-3210M may be slightly under-powered for the task, however you can
try all the following performance tuning adjustments, and it may be able to
support 56 MS/s.

It is worth noting that the recent KPTI patches and other related
workarounds [2] for Intel CPUs to protect against Meltdown/Spectre attacks
[3], may cause a considerable overhead. Here [4] are instructions on how to
check to see if KPTI is enabled for Ubuntu. You may want to disable KPTI,
if it is enabled on your system, then test to see how much additional
overhead it creates, running your application.

Adjust your CPU Governor to "performance". This can be done with the
cpu-frequtils utility [5]. ( sudo cpufreq-set -g performance )

Ensure your CPU is not throttling due to overheating ( sudo cat
/var/log/syslog | grep throttled ). This is very common in laptops,
especially older devices where the thermal grease is in need of replacement.

You can test using sc8 and sc12 OTW (over the wire) [6] sample sizes with
the benchmark_rate [7] utility. Using sc12 will not drop any information as
the ADC/DAC on the B2xx is 12bits.

./benchmark_rate --rx_otw sc12 --rx_rate 40e6
./benchmark_rate --tx_otw sc8 --tx_rate 40e6

Some USB controllers can be problematic. Intel Series 7/8/9 USB controllers
usually offer the best performance.

Using Thinkpads (T430s, T470p) I've found that a recv/send frame size of
8192 tends to work the best at higher sample rates.

As Marcus mentioned, the UHD examples are provided as an API reference and
not tuned for performance. Case in point is rx_samples_to_file being single
threaded. GNU Radio will by default offer a multi-threaded architecture,
which can be useful to test. You may need to adjust the min buffer sizes to
handle the higher sample rates however within the GR Blocks.

I've attached an example of rx_samples_to_file.cpp which is multi-thread
and has additional buffering.

Without a SSD or NVMe hard drive, sustaining a high sample rate to disk can
be difficult. Depending upon your system configuration, you may want to
consider using a ram disk. I would recommend leaving at least 2-8 GB of ram
for your host OS (this is dependent upon your application etc). This will
however limit the length of time you can save to disk (as limited by the
ram in the machine). Below is an example to create a 24GB ramdisk:

mkdir -p ~/ramfs
mount -t tmpfs -o size=24G tmpfs ~/ramfs


[1] -
https://github.com/EttusResearch/uhd/commit/d95613152da3e7c7f41c71acca65101ed0896893
[2] - https://en.wikipedia.org/wiki/Kernel_page-table_isolation
[3] - https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)
[4] -
https://askubuntu.com/questions/992137/how-to-check-that-kpti-is-enabled-on-my-ubuntu
[5] - http://www.thinkwiki.org/wiki/How_to_use_cpufrequtils
[6] - https://files.ettus.com/manual/page_stream.html#stream_datatypes_otw
[7] -
https://github.com/EttusResearch/uhd/blob/maint/host/examples/benchmark_rate.cpp

Regards,
Nate Temple

On Tue, Feb 13, 2018 at 11:59 AM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 02/13/2018 04:52 AM, Kasper Føns via USRP-users wrote:
>
>> Hi.
>>
>> We have bought a B200 board and are having issues simply receiving the
>> samples and would like some support in the matter.
>>
>> Running the command
>>./rx_samples_to_file --null --rate 5600
>> on a Sony Vaio Z with an I5-3210M running Ubuntu Server 17.10 shows a
>> high CPU usage of ~78%.
>>
>> Is such a high CPU usage expected?
>> Switching terminal windows (ALT + F1 or ALT + F2) is enough to cause an
>> overflow on the Linux host.
>>
>>
>> There is also a high CPU usage on a Windows 10 machine (ThinkPad,
>> i7-4810MQ).
>> Running
>>./rx_samples_to_file --null --rate 5600
>> results in a infinite stream of overflows.
>>
>> Running
>>./rx_samples_to_file --null --rate 3200
>> utilizes 22% CPU and still overflows once in a while. Moving a
>> calculator window around the screen results in overflows.
>>
>> We have tried increasing buffers using --args="recv_frame_size=X,
>> num_recv_frames=Y"
>> However, we haven't been able to increase X to higher values than ~16000
>> (16384 fails with lots of overflows).
>> The same applies to Y, where 300 fails with an error.
>>
>> The software was compiled in release mode an ran over a USB 3 connection.
>>
>> Thus, for USB transfers using the B200:
>>   - On Vaio: Is ~78% CPU usage expected for 56 Msps ?
>>   - On Win10: Is it not possible to receive 56 Msps?
>>   - On Win10: Is 22% CPU usage expected for 32 Msps?
>>   - Is there some limit to recv_frame_size? A value of 16384 

Re: [USRP-users] X310 underflow in transmit-only configuration

[Nate Temple via USRP-users]

Hi Steven,

If you are able, can you please post an application/code that demonstrates
this ? Without seeing the code, its nearly impossible to debug the issue.

What version of UHD are you using?

Regards,
Nate Temple



On Thu, Feb 8, 2018 at 1:33 PM, Steven Knudsen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> I have been scratching my head for a while on this one…
>
> I have made a TDMA radio that has a simple 4 slot cycle with a relatively
> low duty cycle (slots are 40% and the remaining 60% of the cycle the USRP
> is idle).
>
> A radio transmits in it’s “owned” slot and receives in all others (3 of
> them). The transmit is timed as are the receptions in each slot. Transmit
> is schedule 10 ms in advance (at the start of a cycle) and the receives are
> scheduled at least 6 ms in advance (at the end of the last receive slot).
>
> When I test with a B200mini connected to an Octoclock G for 1 PPS
> reference, it runs flawlessly for hours (5 is the longest). When, on the
> exact same Linux host I run with an X310 connected to the same Octoclock G
> for 1 PPS and 10 MHz, it stops working after not too long with a slew of
> ’U’s and ’L’s
>
> Trying to narrow things down, I created a version fo the radio that only
> transmits. Reception is completely disabled and I confirm that no receive
> commands are ever scheduled and rxStreamer->recv() is never called.
>
> So, imagine my surprise when after a fairly long time of transmitting
> successfully (evidenced by using an oscilloscope to view packets), the
> transmit-only version fails!?! Below is a copy o the log showing the first
> evidence of failure, namely ’L’s indicating transmits were too late. But,
> what is the ‘U’ doing there? As I mentioned, no reception functionality is
> in the program, so what is going on?
>
> Anyone else see this kind of thing? I never see it with the B200mini, but
> see it consistently with the X310.
>
> thanks very much for your time and consideration,
>
> steven
>
> ULLsendFrame() MPDU #719935  mpdu size = 488 bytes at 1518123481s 89 us
> ULLLsendFrame() MPDU #719936  mpdu size = 488 bytes at 1518123481s 90 us
> UsendFrame() MPDU #719937  mpdu size = 488 bytes at 1518123481s 91 us
> ULsendFrame() MPDU #719938  mpdu size = 488 bytes at 1518123481s 92 us
> ULLsendFrame() MPDU #719939  mpdu size = 488 bytes at 1518123481s 93 
> us
> ULLLsendFrame() MPDU #719940  mpdu size = 488 bytes at 1518123481s 94 
> us
> UsendFrame() MPDU #719941  mpdu size = 488 bytes at 1518123481s 
> 95 us
> ULsendFrame() MPDU #719942  mpdu size = 488 bytes at 1518123481s 
> 96 us
> ULLsendFrame() MPDU #719943  mpdu size = 488 bytes at 1518123481s 
> 97 us
> ULLLsendFrame() MPDU #719944  mpdu size = 488 bytes at 1518123481s 
> 98 us
> UsendFrame() MPDU #719945  mpdu size = 488 bytes at 1518123481s 
> 99 us
> ULsendFrame() MPDU #719946  mpdu size = 488 bytes at 1518123482s 
> 0 us
> ULsendFrame() MPDU #719947  mpdu size = 488 bytes at 1518123482s 
> 1 us
> ULLsendFrame() MPDU #719948  mpdu size = 488 bytes at 1518123482s 
> 2 us
> ULLLsendFrame() MPDU #719949  mpdu size = 488 bytes at 
> 1518123482s 3 us
> UsendFrame() MPDU #719950  mpdu size = 488 bytes at 
> 1518123482s 4 us
> ULsendFrame() MPDU #719951  mpdu size = 488 bytes at 
> 1518123482s 5 us
> ULLsendFrame() MPDU #719952  mpdu size = 488 bytes at 
> 1518123482s 6 us
> ULLLsendFrame() MPDU #719953  mpdu size = 488 bytes at 
> 1518123482s 7 us
>
>
>
> Steven Knudsen, Ph.D., P.Eng.
> www. techconficio.ca
>
> www.linkedin.com/in/knudstevenknudsen
>
>
>
> *All the wires are cut, my friendsLive beyond the severed ends.  Louis
> MacNeice*
>
>
> ___
> 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