Re: [USRP-users] USRP B 210 vs USRP X 310

2019-10-30 Thread Marcus Müller via USRP-users
Hello Padorin,

both are pretty good; the presentation can't fully represent the
differences; the UBX alone costs about as much as an B210, and you'll
need an X310 and two UBX to have as many channels as the B210, so
there's a solid factor in price and size and weight and power
consumption that goes for the B210. So, "B2xx < X3xx" is a
simplification, but an *often* meaningful one.

So, whether or not the B210 is measurably better than the X310 + UBX-
160 *depends on your use case and constraints* and I'll refrain from
making a general statement here: the RF chain on the B210 is actually
pretty good, but very flexible, and thus, not overly selective.

So, yes, from most datasheet properties, the UBX's frontend simply
outshines the B210.

Now comes the problem: You say you want a "clean" signal. That's not an
term that I can use to advise you. What does "clean" mean to you, or
maybe, what's "unclean"? What is it that you need that signal for? What
will be the bandwidths? The powers? The frequency stability
requirements? The number of channels, the frequency agility?

There's just way to many things which can lead to the difference
between UBX-160 and B210 being negligible. So, please tell us about
what you want to build :) I don't want to "sell" you something more
expensive that you don't need.

Best regards,
Marcus
 
On Wed, 2019-10-30 at 17:17 +0900, Padorin Kurpinsky wrote:
> Hello, Marcus!
> 
> I'm new to the RF world and curious about the RF performance between
> USRP B210 and X310 (UBX-160). Especially, I'm wondering which device
> can transmit a *clear signal*, for example, less spur would be great.
> I'm not interested in Bandwidth or Phase synchronization or MIMO.
> 
> In the spec, the DAC resolution of B210 is 12 bit, while X310 is 16
> bit. So, from the point of view of sending a clean signal, only DAC
> resolution affects the RF performance?
> 
> This presentation ( 
> https://www.openairinterface.org/docs/workshop/3_OAI_Workshop_20170427/Session2_UE/Thomas_Tsou_-_ettus.pdf
>  ) says that RF performance is B200 < N200 < X300. What is the basis
> for this claim?
> 
> Thank you very much.
> 
> 


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


Re: [USRP-users] uhd example programs - weird environment variable issue?

2019-09-19 Thread Marcus Müller via USRP-users
Hi David, 


the version string printed by benchmark_rate shows that you've also got
an old UHD 3.10.3.0 installation on your system.

Make sure there's only one installation of UHD.

Best regards,
Marcus

On Thu, 2019-09-19 at 16:55 -0400, David Smay via USRP-users wrote:
> Hello,
> 
> I recently did a clean installation of UHD 3.14.1 and gnuradio
> 3.7.13.5 on Ubuntu 18.04 LTS, following the steps outlined in the
> Ettus knowledge base for installation from source.
> 
> The installation worked great, and I started experimenting with the
> example programs installed with UHD (located in
> /usr/lib/uhd/examples/).  At first they ran correctly and I was able
> to run the gpio and benchmark_rate programs without issue, getting
> the normal expected output for my b205mini-i.
> 
> Without making any changes to the system, and in the same shell
> session, all of a sudden the example programs all started
> consistently generating errors when I tried to run them:
> 
> dsmay4@UbuntuPrecision7530:/usr/lib/uhd/examples$ ./benchmark_rate --
> rx_rate 10e6
> linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-
> unknown
> 
> 
> 
> UHD Warning:
> EnvironmentError: IOError: Could not find path for image:
> usrp_b200_fw.hex
> Using images directory: 
> Set the environment variable 'UHD_IMAGES_DIR' appropriately or
> follow the below instructions to download the images package.
> Please run:
>  "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
> Creating the usrp device with: ...
> 
> UHD Warning:
> EnvironmentError: IOError: Could not find path for image:
> usrp_b200_fw.hex
> Using images directory: 
> Set the environment variable 'UHD_IMAGES_DIR' appropriately or
> follow the below instructions to download the images package.
> Please run:
>  "/usr/lib/x86_64-linux-gnu/uhd/utils/uhd_images_downloader.py"
> Error: LookupError: KeyError: No devices found for ->
> Empty Device Address
> 
> This is quite strange as my uhd_images_downloader isn't installed to
> that directory, but it does run just fine.  uhd_find_devices and
> uhd_usrp_probe run fine and indicate no problems with the radio
> itself.  Other sdr apps using the b205 work just fine - the problem
> seems to only impact these example programs.
> 
> I tried rebooting, as well as uninstalling and reinstalling UHD
> (which reinstalled the example programs) but the problem persists. 
> I'm mostly interested in figuring out what caused the spontaneous
> change in system behavior.  I can't for the life of me figure out why
> just these apps can't find the fpga images but everything else works
> just fine...
> 
> TIA,
> 
> 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] University of Saskatchewan N200 Rack

2019-09-17 Thread Marcus Müller via USRP-users
Hey Keith,

I quite enjoyed your email :) May I ask what the individual added SMAs
do?

I like the vertical mounting, and the additional LEDs :)

Best regards,
Marcus

On Mon, 2019-09-16 at 18:04 +, Keith k via USRP-users wrote:
> Hey all
> 
> I thought I would offer a break from the endless bugs and dev
> questions to share what our N200 rack looks like. These N200s are
> going to be used for a radar installation. We've made some custom
> modifications to each N200, such as adding brighter and more detailed
> ATR status LEDs, adding more SMA connector ports(1 in front, 4 in
> back with a dsub as well). 
> 
> The Ettus N200 rackmount is quite frankly not very well designed, so
> we designed our own. It allows for tool-less fasteners for quick
> install/release of the devices, vertical mount to allow for more room
> between devices, and several holes for better cable routing and
> management. 
> ___
> 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] Pybombs UHD install for development machine CMake version failure

2019-09-11 Thread Marcus Müller via USRP-users
Dear David,

I've seen that happen on specific Ubuntu versions, where they somehow
missed to clean up / mark conflict between CMake 2.x packages and newer
CMake (I'm perpetually disappointed by Canonical). Make twice as sure
that you only got one CMake installed - if this is actually Ubuntu,
"apt search cmake" might be the way to start.

Best regards,
Marcus

On Wed, 2019-09-11 at 16:42 +0100, David Scott via USRP-users wrote:
> Hi all,
> 
> I have recently acquired a USRP E312 and have been following the 
> quickstart guide at: -
> 
> https://kb.ettus.com/Software_Development_on_the_E310_and_E312
> 
> The relevant commands being: -
> 
>$ sudo pip install git+https://github.com/gnuradio/pybombs.git
>$ pybombs recipes add gr-recipes 
> git+https://github.com/gnuradio/gr-recipes.git
>$ pybombs recipes add ettus 
> https://github.com/EttusResearch/ettus-pybombs.git
>$ sudo dpkg-reconfigure dash # select NO
>$ pybombs prefix init ~/prefix -R e3xx-rfnoc -a e300
> 
> Everything proceeds well up until the CMake is carried out at which
> it 
> complains that the installed version of CMake is below the minimum.
> The 
> output log is : -
> 
> 
> 1511750 kB / 1511750 kB 
> (100%
> 
> 
> [INFO] Installing SDK 
> `e3xx-release4-
> sdk'
> 
> The directory "/home/david/prefix" already contains a SDK for this 
> architecture.)))
> 
> If you continue, existing files will be overwritten! 
> Proceed[y/N]?Y))Extracting 
> SDK...done)))
> )
> 
> Setting it 
> up...done
> )
> 
> SDK has been successfully set up and is ready to be 
> used.
> 
> [INFO] Cleaning up 
> files...)
> )
> 
> [INFO] Prefix Python version is: 
> 2.7.15)))
> )))
> 
> [INFO] Installing default packages for 
> prefix...)
> 
> [INFO] 
> )
> ) 
> - uhd)
>- gnuradio
>- gr-ettus
> [INFO] Install python-apt to speed up apt processing.
> [INFO] Phase 1: Creating install tree and installing binary packages:
> Install tree:
> \- gr-ettus
> |
> +- uhd
> |
> \- gnuradio
>|
>\- uhd
> [INFO] Phase 1 complete: All binary dependencies installed.
> [INFO] Phase 2: Recursively installing source packages to prefix:
> [INFO] Installing package: uhd
> [WARNING] A source build for package uhd was requested, but binary 
> install was found!
> Install uhd from source despite binary install available Y/[N]?
> [INFO] Install python-apt to speed up apt processing.
> [WARNING] Build dir already exists:
> /home/david/prefix/src/uhd/host/build
> Configuring: (100%) 
> [
> ==]
> [WARNING] Configuration failed. Re-trying with higher verbosity.
> CMake Error at CMakeLists.txt:13 (cmake_minimum_required):
>CMake 3.5.1 or higher is required.  You are running version
> 2.8.12.2
> 
> -- Configuring incomplete, errors occurred!
> 
> Running cmake --version on my system shows: -
> 
>cmake version 3.10.2
> 
>CMake suite maintained and supported by Kitware
> (kitware.com/cmake).
> 
> I have no idea why pybombs thinks I am running cmake 2.8. I have 
> searched online and can find no reference to the issue. Has anyone
> else 
> encountered this issue or does anyone know of a solution?
> 
> Thanks,
> 
> David
> 
> 
> ___
> 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] UHD sink transmit at 100 MSPS

2019-09-11 Thread Marcus Müller via USRP-users
Hi Josh,

maybe https://kb.ettus.com/USRP_Host_Performance_Tuning_Tips_and_Tricks
 is of relevance to you?

Best regards,
Marcus

On Wed, 2019-09-11 at 10:50 -0400, Josh via USRP-users wrote:
> Hello,
> 
> I'm looking to transmit a wideband signal from an X310 at 100 MSPS,
> so I'll start by posing the very general question of what tips and
> optimizations do I need to make to be able to do this reliably.
> 
> Here is what I already have set up (this is using a powerful server -
> 60 cores at 3.4GHz)
> GNU Radio 3.7, Ubuntu 16
> UHD 3.14.1.1
>   - have also downgraded to UHD 3.9 and get generally higher
> throughput, less buffer underruns
> MTU/frame size set to 8000
> 
> But no matter what I try - continuous stream, or TSB bursts, there is
> a string of U's when I first start transmitting.  With TSBs, there is
> also a string of Us on every burst I send to the UHD sink (with the
> newer UHD).  I've monkeyed around with parts of gr-uhd and uhd - but
> nothing of consequence.  
> 
> So any tips to get up to 100MSPS transmit would be greatly
> appreciated
> 
> Thanks,
> Josh
> ___
> 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 SVD Block

2019-09-11 Thread Marcus Müller via USRP-users
Thanks! I'm always curious about how our hard- and software
infrastructure is being used!

By the way, in case you want to test a verilog SVD implementation
within a signal processing framework: Bowen Hu did a very interesting
Google Summer of Code project this year, in which he made it possible
to just drop in a Verilog Module in a GNU Radio block and use that to
do signal processing in a pure host computer simulation. He'll be at
GRCon this year!

https://github.com/B0WEN-HU/gr-verilog


Best regards,
Marcus
On Wed, 2019-09-11 at 15:13 +, Quadri,Adnan wrote:
> Hello,
> 
> Thanks for your prompt response and sorry for my delayed one.
> 
> I have thought about the first option you have discussed, which is to
> use already implemented SVD but modify it to fit with the nocshell.
> 
> As we go down that way, I will update this thread with questions or
> any significant findings.
> 
> Thank you,
> Adnan
> From: Marcus Müller 
> Sent: Friday, September 6, 2019 4:00 PM
> To: Quadri,Adnan ; 
> usrp-users@lists.ettus.com 
> Subject: Re: [USRP-users] RFNoC SVD Block
>  
> Hello Adnan,
> 
> I'm currently not aware of anyone doing that.
> 
> However, since one of the typical applications of beefier FPGAs is
> math
> accelerators for linear algebra problems, it's more than likely
> someone
> did in fact implement an SVD before, and you might just need to
> connect
> it to a nocshell to make it work in RFNoC. There's a lot of
> interesting
> papers out there on SVD implementations for fixed point math on
> FPGAs,
> I think Drexel uni had some interesting stuff for SVD-based channel
> estimation for OFDM. I've not seen any code of them, though...
> 
> So, from an algorithmic point of view, an SVD isn't too hard. IIRC,
> sequential algorithms can work in-place, and thus (for a m×n matrix,
> n>m) don't need more than n² space for intermediate and final result
> (+2m for index and scale storage if you want to pivot elegantly).
> 
> Now, I've not ever implemented more than a C++ QR decomposition
> (which
> is the core algorithm for most EVD problems, which you typically
> householder-transform an SVD problem to), so I'm really not competent
> to comment on hardware implementations, but chances are you want to
> compute a lot of result values in parallel if you're doing it in the
> FPGA – because otherwise, you'd abhor doing much work in hardware
> (that
> being _hard_) in favor of doing it easier-to-debug and also free-to-
> have in the shape of LAPACK software. (Subtext message, more for
> future
> readers than for you: Evaluate whether something really should be
> done
> in hardware; it's not inherently better to do things in hardware.)
> But that parallelism might imply that in-place is not a feasible way
> of
> computing things, and your memory requirements might be much larger.
> Depending on the size of SVD you're planning to do, that might or
> might
> not be an issue.
> 
> Best regards,
> Marcus
> 
> On Fri, 2019-09-06 at 19:05 +, Quadri,Adnan via USRP-users wrote:
> > Hello,
> > 
> > We are trying to perform singular vector decomposition. The idea is
> > to work on an RFNoC block that takes in summation of samples from
> the
> > Radio source and will perform SVD.
> > 
> > Is anybody working on something similar? 
> > Currently, the RFNoC OFDM synchronizer block has timing constraint
> > issues and can't be used to build FPGA image.
> > 
> > Just asking around to get some suggestions/advice and idea if
> working
> > on that Verilog implementation of SVD is something doable and if
> > anybody tried anything similar.
> > 
> > Thank you,
> > Adnan
> > 
> > 
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.ettus.com_mailman_listinfo_usrp-2Dusers-5Flists.ettus.com=DwIDaQ=OAG1LQNACBDguGvBeNj18Swhr9TMTjS-x4O_KuapPgY=JoNl3b2Pn0MHhs668QvjpcSGl6s3MEmtJLBypH6x02U=k37R0Rl_g81NH-S6ItDZuzmUBw5LoTVhKicoMs7QquI=wNh-TuGTVEYzPNN0GRzBjYiBuFKVQfG5vjCSdYCEnPY=
>  
> 


___
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

2019-09-06 Thread Marcus Müller via USRP-users
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


Re: [USRP-users] RFNoC SVD Block

2019-09-06 Thread Marcus Müller via USRP-users
Hello Adnan,

I'm currently not aware of anyone doing that.

However, since one of the typical applications of beefier FPGAs is math
accelerators for linear algebra problems, it's more than likely someone
did in fact implement an SVD before, and you might just need to connect
it to a nocshell to make it work in RFNoC. There's a lot of interesting
papers out there on SVD implementations for fixed point math on FPGAs,
I think Drexel uni had some interesting stuff for SVD-based channel
estimation for OFDM. I've not seen any code of them, though...

So, from an algorithmic point of view, an SVD isn't too hard. IIRC,
sequential algorithms can work in-place, and thus (for a m×n matrix,
n>m) don't need more than n² space for intermediate and final result
(+2m for index and scale storage if you want to pivot elegantly).

Now, I've not ever implemented more than a C++ QR decomposition (which
is the core algorithm for most EVD problems, which you typically
householder-transform an SVD problem to), so I'm really not competent
to comment on hardware implementations, but chances are you want to
compute a lot of result values in parallel if you're doing it in the
FPGA – because otherwise, you'd abhor doing much work in hardware (that
being _hard_) in favor of doing it easier-to-debug and also free-to-
have in the shape of LAPACK software. (Subtext message, more for future
readers than for you: Evaluate whether something really should be done
in hardware; it's not inherently better to do things in hardware.)
But that parallelism might imply that in-place is not a feasible way of
computing things, and your memory requirements might be much larger.
Depending on the size of SVD you're planning to do, that might or might
not be an issue.

Best regards,
Marcus

On Fri, 2019-09-06 at 19:05 +, Quadri,Adnan via USRP-users wrote:
> Hello,
> 
> We are trying to perform singular vector decomposition. The idea is
> to work on an RFNoC block that takes in summation of samples from the
> Radio source and will perform SVD.
> 
> Is anybody working on something similar? 
> Currently, the RFNoC OFDM synchronizer block has timing constraint
> issues and can't be used to build FPGA image.
> 
> Just asking around to get some suggestions/advice and idea if working
> on that Verilog implementation of SVD is something doable and if
> anybody tried anything similar.
> 
> Thank you,
> 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] [Discuss-gnuradio] Clock rate change on x300

2019-08-07 Thread Marcus Müller via USRP-users
You can!

If you're using GRC to design your GNU Radio system, it's the "Clock
Rate" property of the UHD USRP Source / Sink blocks; if you're directly
coding, you want to call set_clock_rate() before doing anything else,
or supplying "master_clock_rate=184.32e6" with your device address.

Best regards,
Marcus

On Wed, 2019-08-07 at 14:30 +, Mitchell, Paul wrote:
> Oh I see.  Does that mean that I can use GNU Radio to change it?  If
> not, I’ll ask the USRP guys as you suggested.
>  
>  
> Paul Mitchell
> Engineering Technician IV
> paul.mitch...@testllc.com
> 256.716.9056 (Work)
> 256.289.3581 (Cell)
>  
> From: Marcus Müller
> Sent: Wednesday, August 7, 2019 9:27 AM
> To: Mitchell, Paul; Derek Kozel; discuss-gnura...@gnu.org
> Cc: usrp-users
> Subject: Re: [Discuss-gnuradio] Clock rate change on x300
>  
> Dear Paul,
> 
> I'd recommend taking this to the USRP-users mailing list (in CC),
> since
> it's not really GNU Radio-related.
> 
> Since that clock rate setting doesn't really "exist" until the device
> is operating, you can't query that from any program than the program
> currently using the USRP (but that program would know, anyway,
> because
> it either set the master clock rate to 184.32 MHz or it left it at
> 200
> MHz).
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-08-07 at 14:18 +, Mitchell, Paul wrote:
> > I’m fine using one of the supported rates.  That’s totally fine.  I
> > would just like to know how to check the clock rate and swap
> between
> > the two for experimentation purposes.  Is there a terminal string I
> > can run in Linux to do this?
> >  
> >  
> > Paul Mitchell
> > Engineering Technician IV
> > paul.mitch...@testllc.com
> > 256.716.9056 (Work)
> > 256.289.3581 (Cell)
> >  
> > From: Derek Kozel
> > Sent: Tuesday, August 6, 2019 1:56 PM
> > To: discuss-gnura...@gnu.org
> > Subject: Re: [Discuss-gnuradio] Clock rate change on x300
> >  
> > Hi Paul,
> > 
> > What rate do you want to adjust it to and for what purpose? The
> X300
> > supports a master clock rate of 200 MS/s and 184.32 MS/s. The built
> > in
> > DSP can convert to an integer divisor sample rate of one of those
> > two.
> > Adding support for another rate would require either a lot of
> > software
> > work or implementing a rational resampler in the FPGA in which case
> > you
> > would need a Vivado license.
> > 
> > https://files.ettus.com/manual/page_usrp_x3x0.html
> > 
> > Regards,
> > Derek
> > 
> > On 06/08/2019 19:09, Mitchell, Paul wrote:
> > > I need to adjust the clock rate on a USRP x300. Is there a simple
> > way to do this or do I need to use Vivado to access the FPGA image
> > somehow? I am using Linux for everything. 
> > >
> > > Paul Mitchell
> > > Engineering Technician IV
> > > paul.mitch...@testllc.com
> > > 256.716.9056 (Work)
> > > 256.289.3581 (Cell)
> > > ___
> > > Discuss-gnuradio mailing list
> > > discuss-gnura...@gnu.org
> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > discuss-gnura...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >  ___
> > Discuss-gnuradio mailing list
> > discuss-gnura...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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


Re: [USRP-users] USRP B2xx Tx Peak power mode

2019-08-07 Thread Marcus Müller via USRP-users
No, it doesn't have to, as I've explained: I don't know what A is, but
if A is leading to saturation or even clipping, and 8 is, too, then you
see no change in amplitude.

Best regards,
Marcus

On Wed, 2019-08-07 at 12:41 +0430, hossein talaiee wrote:
> Dear Marcus,
> 
> I use the same signal for NI-5672 and signal changes as expected, I
> change A from  2000 to 8 and it must drop 46 dB but does not!
> 
> On Tue, Aug 6, 2019 at 4:09 AM Marcus Müller <
> marcus.muel...@ettus.com> wrote:
> > Dear Hossein,
> > 
> > the B200 does NOT have a TX power control that would compensate
> > that.
> > 
> > Are you perhaps either not changing A very much, or are you perhaps
> > clipping? Driving your B200's TX amplifier into saturation would of
> > course mean that you'd not see much of signal power reduction when
> > reducing signal amplitude, until you cross the threshold where
> > things
> > become linear again.
> > 
> > Best regards,
> > Marcus
> > 
> > On Mon, 2019-08-05 at 17:00 +0430, hossein talaiee via USRP-users
> > wrote:
> > > Hi
> > > 
> > > I want to manually control output power of my USRP with signal
> > level
> > > not usrp gain,for example I want to generate a sinusoidal signal
> > with
> > > equation:
> > >  
> > >s(t) = A * sin(w*t);
> > > 
> > > and want to change A to control tx power, but when I change it,
> > > somehow USRP compensate my change and tries to hold tx power!
> > like it
> > > is trying to hold average power.
> > > 
> > > Using NI-5672 signal generator, I am able to control power with
> > > setting the power mode to "Peak Power mode" instead of "Average
> > Power
> > > mode". I think USRP has something like this to control power. How
> > can
> > > I disable it?
> > > ___
> > > 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] Clock rate change on x300

2019-08-07 Thread Marcus Müller via USRP-users
Dear Paul,

I'd recommend taking this to the USRP-users mailing list (in CC), since
it's not really GNU Radio-related.

Since that clock rate setting doesn't really "exist" until the device
is operating, you can't query that from any program than the program
currently using the USRP (but that program would know, anyway, because
it either set the master clock rate to 184.32 MHz or it left it at 200
MHz).

Best regards,
Marcus

On Wed, 2019-08-07 at 14:18 +, Mitchell, Paul wrote:
> I’m fine using one of the supported rates.  That’s totally fine.  I
> would just like to know how to check the clock rate and swap between
> the two for experimentation purposes.  Is there a terminal string I
> can run in Linux to do this?
>  
>  
> Paul Mitchell
> Engineering Technician IV
> paul.mitch...@testllc.com
> 256.716.9056 (Work)
> 256.289.3581 (Cell)
>  
> From: Derek Kozel
> Sent: Tuesday, August 6, 2019 1:56 PM
> To: discuss-gnura...@gnu.org
> Subject: Re: [Discuss-gnuradio] Clock rate change on x300
>  
> Hi Paul,
> 
> What rate do you want to adjust it to and for what purpose? The X300
> supports a master clock rate of 200 MS/s and 184.32 MS/s. The built
> in
> DSP can convert to an integer divisor sample rate of one of those
> two.
> Adding support for another rate would require either a lot of
> software
> work or implementing a rational resampler in the FPGA in which case
> you
> would need a Vivado license.
> 
> https://files.ettus.com/manual/page_usrp_x3x0.html
> 
> Regards,
> Derek
> 
> On 06/08/2019 19:09, Mitchell, Paul wrote:
> > I need to adjust the clock rate on a USRP x300. Is there a simple
> way to do this or do I need to use Vivado to access the FPGA image
> somehow? I am using Linux for everything. 
> >
> > Paul Mitchell
> > Engineering Technician IV
> > paul.mitch...@testllc.com
> > 256.716.9056 (Work)
> > 256.289.3581 (Cell)
> > ___
> > Discuss-gnuradio mailing list
> > discuss-gnura...@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
> 
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>  ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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


Re: [USRP-users] b210 USB detect problem

2019-08-06 Thread Marcus Müller via USRP-users
Hi Thomas,
The switching **should** be really smooth! Also, it shouldn't confuse
either USB end to stop working.
But since we're really debugging this by now, this would be reasonable
to check, yes. Do you happen to have an oscilloscope?

By the way, does the device work with the Vcc-cut USB cable and
external power? I've honestly never tried.

Best regards,
Marcus

On Tue, 2019-08-06 at 21:23 +0200, Thomas Fabricius via USRP-users
wrote:
> Hi Marcus
> 
> No detect = not in lsusb!
> 
> The suspision is (more or less) confirmed:
> Experiment 1:
> -Starting from total power off and no USB cable: Led off 
> -Turn on PC: Led off
> -Plug in USB cable: Led orange to indicate USB power 
> -Device is in lsusb list (ie. everything is good just from USB
> power!)
> -Plug in external power: Led change to blue indicating external power
> -Unplug USB cable: Led stays blue
> 
> Experiment 2:
> -Starting from total power off and no USB cable: Led off
> -Turn on PC: Led off
> -Plug in external power: Led off
> -Plug in USB cable: Led blue
> -Device is in lsusb list
> -Unplug USB cable: Led stays blue
> 
> Experiment 3:
> -Starting from total power off and no USB cable: Led off
> -Turn on PC: Led off
> -Plug in external power: Led off
> -Plug in USB cable without power cord (cut as suggested): Led off 
> -Unplug USB cable: Led off
> 
> Inrush can not be the problem, cause everything is fine just coming
> up with USB power only, it though could be the switch-over to
> external power ?!?!?
> 
> /thomas
> 
> 
> -Original Message-
> From: Marcus Müller  
> Sent: Tuesday, 6 August 2019 17.39
> To: Thomas Fabricius ; usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] b210 USB detect problem
> 
> Hi Thomas,
> 
> let me quickly address a few of these issues On Tue, 2019-08-06 at
> 15:40 +0200, Thomas Fabricius via USRP-users
> wrote:
> > Hi,
> > we have a number b210s that has USB detect problems. We have
> > equipment 
> > where the power can suddenly disappear, and then the system does
> > not 
> > come up right and there is (yet) no programmatic way to resolve
> > the 
> > problem, so we have to get in physical contact with the system.
> > Any one who knows of a workaround (pls. read below before
> > answering)…
> >  
> > *PC cannot detect B210 USB device on cold boot (after for instance
> > a 
> > power break)
> 
> I've seen that before on x86 industrial PCs. I think it might be a
> combination of overtasked on-board USB voltage supplies and USB host
> controller firmware.
> 
> > *The B210 USB device is simply not recognized by the PC.
> 
> That means it's not in `lsusb`?
> 
> > *The B210 has an attached GPSDO and external power attached.
> > 
> 
> That at least rules out power supply problems.
> 
> > *This happens on multiple systems and cannot be attributed to a
> > single 
> > PC type nor B210 device.
> 
> Ok, good to know!
> 
> >  
> > Steps to reproduce:
> > 1. Remove all power from PC and B210.
> > 2. Insert USB into PC.
> > 3. Apply power to the devices.
> > 4. Start the PC.
> > 5. The PC is after boot into linux to see the B210 board.
> > 6. Errors are displayed in the dmesg kernel log:
> >  
> > [   23.884317] usb 1-4: new high-speed USB device number 3 using
> > xhci_hcd [   29.024313] usb 1-4: device descriptor read/64, error
> > -110 [   44.640330] usb 1-4: device descriptor read/64, error -110
> > [   44.748356] usb usb1-port4: attempt power cycle [   45.400311]
> > usb
> > 1-4: new high-speed USB device number 4 using xhci_hcd
> > [   56.240225]
> > usb 1-4: device not accepting address 4, error -62 [   56.368230]
> > usb
> > 1-4: new high-speed USB device number 5 using xhci_hcd
> > [   66.992306]
> > usb 1-4: device not accepting address 5, error -62 [   66.992363]
> > usb
> > usb1-port4: unable to enumerate USB device
> >  
> > The "device descriptor read/64, error -110" means that USB power
> > drain 
> > was exceeded by the USB device.
> 
> OK, is the external power supply you use the stock ettus one, or are
> you using something different?
> 
> >  
> > 7. Our application prints:
> >  
> > Error: LookupError: KeyError: No devices found for -> Device
> > Address:
> > num_recv_frames: 512
> >  
> > 8. The device is totally absent, so its not possible to for
> > instance
> > run:  $UHD_INSTALL_PREFIX/utils/b2xx_fx3_utils --reset-device
> >  
> > Workarounds that works:
> > * Physically unplug the USB device and insert it again in the same
> > USB 
> > port. (sometimes it though seems like this does not work either,
> > and 
> > one need to switch to a new USB port on another USB HUB on the
> > PC)
> 
> There's a high probability that means that some polyfuse has been
> triggered, in my experience. I've seen that in systems where there
> was no shared ground between USRP supply and PC, and the powering of
> either device caused a significant inrush current (I guess, couldn't
> measure back then).
> 
> >  
> > * Physically press the reset switch (S700) on the B210.
> 
> That's interesting; 

Re: [USRP-users] Fwd: Configurating X300 "uhd_find_devices" No uhd devices found

2019-08-06 Thread Marcus Müller via USRP-users
Dear Edwin,

this usually fails because the USRPs reply with a "where are USRPs
broadcast" from uhd_find_devices with a "here I am broadcast", and
often, these get caught in the firewall or don't get routed through
e.g. NAT.

Since you're using a VM: the X300 can push through a WHOLE lot of data
per second.
 You'd typically really want to avoid that the host touches network
data going to and coming from the VM for computational reasons.
The most performant way to do that is to just bind your network card
completely to the VM; as soon as you achieve that, the host can't
filter out any replies anymore. You'll also need to make sure the VM's
firewall doesn't either.

Best regards,
Marcus

On Tue, 2019-08-06 at 17:40 -0500, Edwin Mauricio Barbosa Salinas via
USRP-users wrote:
> 
> 
> -- Forwarded message -
> De: Edwin Mauricio Barbosa Salinas 
> Date: mar., 6 ago. 2019 a las 17:37
> Subject: Configurating X300 "uhd_find_devices" No uhd devices found
> To: 
> 
> 
> regards,
> I am currently working with a USRP X300, following its UHD and
> GNURADIO installation guides, I am making the configurations from
> Ubuntu 14.04 with a VM VirtualBox virtual machine, when I execute the
> command "uhd_find_devices" it throws me a message saying "No UHD find
> devices" but when I execute the command "uhd_find_devices --args ="
> addr = 192.168.10.2 "" it executes it successfully, I want to know
> how to do so that when executing the command "uhd_find_devices" it is
> executed successfully.
> 
> 
> root@edwin-VirtualBox:/home/edwin# uhd_find_devices 
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.005-0-
> g32951af2
> 
> No UHD Devices Found
> 
> root@edwin-VirtualBox:/home/edwin# uhd_find_devices --
> args="addr=192.168.10.2"
> linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.009.005-0-
> g32951af2
> 
> --
> -- UHD Device 0
> --
> Device Address:
> type: x300
> addr: 192.168.10.2
> fpga: HGS
> name: 
> serial: 3124ED5
> product: X300
> 
> 
> -- 
> Edwin Mauricio Barbosa salinas
> Cod. 2172800
> INGENIERÍA DE TELECOMUNICACIONES
> 
> 
> ___
> 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] b210 USB detect problem

2019-08-06 Thread Marcus Müller via USRP-users
Hi Thomas,

let me quickly address a few of these issues
On Tue, 2019-08-06 at 15:40 +0200, Thomas Fabricius via USRP-users
wrote:
> Hi,
> we have a number b210s that has USB detect problems. We have
> equipment where the power can suddenly disappear, and then the system
> does not come up right and there is (yet) no programmatic way to
> resolve the problem, so we have to get in physical contact with the
> system.
> Any one who knows of a workaround (pls. read below before answering)…
>  
> *PC cannot detect B210 USB device on cold boot (after for instance a
> power break)

I've seen that before on x86 industrial PCs. I think it might be a
combination of overtasked on-board USB voltage supplies and USB host
controller firmware.

> *The B210 USB device is simply not recognized by the PC.

That means it's not in `lsusb`?

> *The B210 has an attached GPSDO and external power attached.
> 

That at least rules out power supply problems.

> *This happens on multiple systems and cannot be attributed to a
> single PC type nor B210 device.

Ok, good to know!

>  
> Steps to reproduce:
> 1. Remove all power from PC and B210.
> 2. Insert USB into PC.
> 3. Apply power to the devices.
> 4. Start the PC.
> 5. The PC is after boot into linux to see the B210 board.
> 6. Errors are displayed in the dmesg kernel log:
>  

> [   23.884317] usb 1-4: new high-speed USB device number 3 using
> xhci_hcd [   29.024313] usb 1-4: device descriptor read/64, error
> -110 [   44.640330] usb 1-4: device descriptor read/64, error -110
> [   44.748356] usb usb1-port4: attempt power cycle [   45.400311] usb
> 1-4: new high-speed USB device number 4 using xhci_hcd [   56.240225]
> usb 1-4: device not accepting address 4, error -62 [   56.368230] usb
> 1-4: new high-speed USB device number 5 using xhci_hcd [   66.992306]
> usb 1-4: device not accepting address 5, error -62 [   66.992363] usb
> usb1-port4: unable to enumerate USB device
>  
> The "device descriptor read/64, error -110" means that USB power
> drain was exceeded by the USB device.

OK, is the external power supply you use the stock ettus one, or are
you using something different?

>  
> 7. Our application prints:
>  
> Error: LookupError: KeyError: No devices found for -> Device
> Address:
> num_recv_frames: 512
>  
> 8. The device is totally absent, so its not possible to for instance
> run:  $UHD_INSTALL_PREFIX/utils/b2xx_fx3_utils --reset-device
>  
> Workarounds that works:
> * Physically unplug the USB device and insert it again in the same
> USB port. (sometimes it though seems like this does not work either,
> and one need to switch to a new USB port on another USB HUB on the
> PC)

There's a high probability that means that some polyfuse has been
triggered, in my experience. I've seen that in systems where there was
no shared ground between USRP supply and PC, and the powering of either
device caused a significant inrush current (I guess, couldn't measure
back then).

>  
> * Physically press the reset switch (S700) on the B210.

That's interesting; s700 really fully resets the USB controller, but I
don't think the full board (would have to check).

>  
> * Remove external power supply from B210 before cold boot.

<-- that's the workaround I'd go for, see below.

>  
> Workarounds that haven't worked:
> * Rebooting the PC, by software and/or by physically switching it off
> and then on (power cable off and on).
>  
> * Try to programmatically remove power from USB device:
>  
> lsusb
> echo suspend > sudo tee /sys/bus/usb/devices/usb1/power/level
> echo suspend > sudo tee /sys/bus/usb/devices/usb2/power/level
> lsusb
> echo on > sudo tee /sys/bus/usb/devices/usb1/power/level
> echo on > sudo tee /sys/bus/usb/devices/usb2/power/level
> lsusb
>  
> * Try to remove the highspeed USB driver:
>  
> lsusb
> echo ":00:14.0" | sudo tee
> /sys/bus/pci/drivers/xhci_hcd/unbind
> lsusb
> dmesg
> echo ":00:14.0" | sudo tee /sys/bus/pci/drivers/xhci_hcd/bind
> lsusb
>  
> * Remove and re-enumerate the USB controller PCI device:
>  
> lsusb
> lspci
> echo 1 | sudo tee /sys/devices/pci\:00/\:00\:14.0/remove
> lsusb
> lspci
> echo 1 | sudo tee /sys/bus/pci/rescan
> lsusb
> lspci
>  
Sad.

> Workarounds that haven't been tried:
> * Use an USB3 hub that is externally powered.
> * Install a larger capacitor in parallel with C716/S700 on the B210
> board to delay USB startup by the device. Somebody recall installing
> a 100uF capacitor. But this doesn’t seem like a root cause fix.

If its really about current draws, best guess is that this would
actually make it worse.

> * Circumvent power switching components (solder a short over Q600)
> such that external power is always used and not disconnected before
> any USB communication. Any side effects ?

Voiding a warranty.

What you could try: If you have a spare USB cable, gently circumsize
the plastic mantling in two places a couple 

Re: [USRP-users] USRP B2xx Tx Peak power mode

2019-08-05 Thread Marcus Müller via USRP-users
Dear Hossein,

the B200 does NOT have a TX power control that would compensate that.

Are you perhaps either not changing A very much, or are you perhaps
clipping? Driving your B200's TX amplifier into saturation would of
course mean that you'd not see much of signal power reduction when
reducing signal amplitude, until you cross the threshold where things
become linear again.

Best regards,
Marcus

On Mon, 2019-08-05 at 17:00 +0430, hossein talaiee via USRP-users
wrote:
> Hi
> 
> I want to manually control output power of my USRP with signal level
> not usrp gain,for example I want to generate a sinusoidal signal with
> equation:
>  
>s(t) = A * sin(w*t);
> 
> and want to change A to control tx power, but when I change it,
> somehow USRP compensate my change and tries to hold tx power! like it
> is trying to hold average power.
> 
> Using NI-5672 signal generator, I am able to control power with
> setting the power mode to "Peak Power mode" instead of "Average Power
> mode". I think USRP has something like this to control power. How can
> I disable it?
> ___
> 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] Short PCI Express link cable for X310

2019-08-05 Thread Marcus Müller via USRP-users
From the PCIe-8371 card documentation:

> > What connectors do the NI MXI-Express x4 copper cables use?
> The NI MXI-Express x4 copper cables use x4 PCI Express connectors.
> For more information about these connectors, visit Molex at
> www.molex.com and search for x4 PCIe iPass.


Best regards,
Marcus

On Mon, 2019-08-05 at 18:05 +0900, 福島幹雄 via USRP-users wrote:
> Hi
> 
> PCI express cable for X310 with PCI-Express Connectivity Kit is 3.0m
> long. often it's too long.
> Is there short cable or compatible cable?
> 
> 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] Help with GPS signal acquisition using USRP N210

2019-07-29 Thread Marcus Müller via USRP-users
Dear Zhao,

even with an active antenna, GPS signal power is usually below noise
floor. You can't "see" GPS without processing ain.

so, none of this is surprising.

Best regards,
Marcus

On Mon, 2019-07-29 at 14:40 -0400, Xu, Zhao via USRP-users wrote:
> Hello,
> 
> I have been struggling with trying to acquire GPS with an N210 for
> some time. I take the liberty of asking you for help that I can't
> find out the error. Here is my setup:
> 
> > Active GPS antenna (Voltage: 3-5V, current: 7-10mA, LNA Gain: 28dB,
> > Connector: SMA) 
> > T bias with 3.3 V DC power 
> > USRP N210 + daughter board CBX
> 
>  
> While experimenting, I found the logs are the same no matter the
> power of antenna is on or off. So it seems that the antenna doesn't
> work well or my configuration file is wrong. But How can I confirm
> the antenna's working status as it has no indicator light? 
> 
> Here is my configuration file (It is from this website: 
> https://gnss-sdr.org/conf/#setting-up-the-software-receiver). One
> thing to note is that I changed two
> parameters: Acquisition_1C.threshold and SignalSource.gain. The
> default value of the threshold is 0.01 which causes frequent loss of
> lock and when I set it to 0.05 the receiver can't maintain lock of
> satellite as the log shown below:
> 
> Acquisition_1C.threshold = 0.01 (Usually I run at least 2 minutes and
> here I just show 10-second log as the following logs are the same.)
> > Sampling Rate for the USRP device: 400.00 [sps]...
> > UHD RF CHANNEL #0 SETTINGS
> > Actual USRP center freq.: 157542.010133 [Hz]...
> > PLL Frequency tune error 0.010133 [Hz]...
> > Actual daughterboard gain set to: 38.00 dB...
> > Setting RF bandpass filter bandwidth to: 200.00 [Hz]...
> > Check for front-end LO: locked ... is Locked
> > Starting a TCP/IP server of RTCM messages on port 2101
> > The TCP/IP server of RTCM messages is up and running. Accepting
> > connections ...
> > [WARNING] [CORES] The requested decimation is odd; the user should
> > expect CIC rolloff.
> > Select an even decimation to ensure that a halfband filter is
> > enabled.
> > decimation = dsp_rate/samp_rate -> 25 = (100.00 MHz)/(4.00
> > MHz)
> > 
> > Current receiver time: 1 s
> > Tracking of GPS L1 C/A signal started on channel 5 for satellite
> > GPS PRN 06 (Block IIF)
> > Tracking of GPS L1 C/A signal started on channel 2 for satellite
> > GPS PRN 10 (Block IIF)
> > Loss of lock in channel 5!
> > Tracking of GPS L1 C/A signal started on channel 4 for satellite
> > GPS PRN 32 (Block IIF)
> > Tracking of GPS L1 C/A signal started on channel 1 for satellite
> > GPS PRN 18 (Block IIR)
> > Tracking of GPS L1 C/A signal started on channel 7 for satellite
> > GPS PRN 02 (Block IIR)
> > Tracking of GPS L1 C/A signal started on channel 5 for satellite
> > GPS PRN 22 (Block IIR)
> > Tracking of GPS L1 C/A signal started on channel 6 for satellite
> > GPS PRN 15 (Block IIR-M)
> > Tracking of GPS L1 C/A signal started on channel 3 for satellite
> > GPS PRN 29 (Block IIR-M)
> > Tracking of GPS L1 C/A signal started on channel 0 for satellite
> > GPS PRN 26 (Block IIF)
> > Current receiver time: 2 s
> > Current receiver time: 3 s
> > Current receiver time: 4 s
> > Current receiver time: 5 s
> > Current receiver time: 6 s
> > Loss of lock in channel 1!
> > Loss of lock in channel 7!
> > Tracking of GPS L1 C/A signal started on channel 1 for satellite
> > GPS PRN 11 (Block IIR)
> > Tracking of GPS L1 C/A signal started on channel 7 for satellite
> > GPS PRN 14 (Block IIR)
> > Loss of lock in channel 3!
> > Tracking of GPS L1 C/A signal started on channel 3 for satellite
> > GPS PRN 23 (Block IIR)
> > Current receiver time: 7 s
> > Current receiver time: 8 s
> > Current receiver time: 9 s
> > Current receiver time: 10 s
> 
>  
> Acquisition_1C.threshold = 0.05
> 
> > Initializing GNSS-SDR v0.0.10.git-next-08c57e2c7 ... Please wait.
> > Logging will be written at ./log
> > [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501;
> > UHD_3.15.0.git-100-gf6f2e961
> > [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] [CORES] Sampling Rate for the USRP device: 400.00
> > [sps]...
> > The requested decimation is odd; the user should expect CIC
> > rolloff.
> > Select an even decimation to ensure that a halfband filter is
> > enabled.
> > decimation = dsp_rate/samp_rate -> 25 = (100.00 MHz)/(4.00
> > MHz)
> > UHD RF CHANNEL #0 SETTINGS
> > Actual USRP center freq.: 157542.010133 [Hz]...
> > PLL Frequency tune error 0.010133 [Hz]...
> > Actual daughterboard gain set to: 38.00 dB...
> > Setting RF bandpass filter bandwidth to: 200.00 [Hz]...
> > Check for front-end LO: locked ... is Locked
> > Starting a TCP/IP server of RTCM messages on port 2101
> > The TCP/IP server of RTCM messages is up and running. Accepting
> > connections ...
> > [WARNING] 

Re: [USRP-users] USRP X310 send period

2019-07-18 Thread Marcus Müller via USRP-users
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


Re: [USRP-users] Command uhd_fft throwing seg fault (core dumped)

2019-07-17 Thread Marcus Müller via USRP-users
No. You'd need to rebuild it from source.

On Wed, 2019-07-17 at 16:27 -0400, Saeid Hashemi via USRP-users wrote:
> Can I modify it to link against the current version?
> 
> On Tue, Jul 16, 2019 at 5:18 PM Marcus D Leech <
> patchvonbr...@gmail.com> wrote:
> > Yes so it’s very likely a compatibility issue. 
> > 
> > Your GNURadio install would have installed uhd_fft and likely
> > linked against a different UHD version
> > 
> > 
> > Sent from my iPhone
> > 
> > On Jul 16, 2019, at 4:30 PM, Saeid Hashemi  
> > wrote:
> > 
> > > Hi Marcus,
> > > I appreciate your reply,
> > > 
> > > I did some digging, and it seems I only have this instance of UHD
> > > installed. How would I troubleshoot this?
> > > Would the best solution be to simply reinstall?
> > > 
> > > My setup is that I installed Open Air Interface, and UHD has been
> > > installed automatically by that.
> > > The other commands work, such as uhd_usrp_probe, as well as Open
> > > Air Interface's radio software, softmodem UE and eNB.
> > > 
> > > Regards,
> > > Saeid
> > > 
> > > On Tue, Jul 9, 2019 at 5:47 PM Marcus D. Leech via USRP-users <
> > > usrp-users@lists.ettus.com> wrote:
> > > > On 07/09/2019 04:41 PM, Saeid Hashemi via USRP-users wrote:
> > > > > To include context, the uhd_config_info command shows the
> > > > > following:
> > > > > 
> > > > > linux; GNU C++ version 4.8.4; Boost_105400;
> > > > > UHD_003.010.002.000-release
> > > > > 
> > > > > And uname -a:
> > > > > 
> > > > > Linux nuc03 3.19.0-61-lowlatency #69~14.04.1-Ubuntu SMP
> > > > > PREEMPT Thu Jun 9 10:15:00 UTC 2016 x86_64 x86_64 x86_64
> > > > > GNU/Linux
> > > > > 
> > > > > The command line output from uhd_fft only shows the
> > > > > following:
> > > > > 
> > > > > Segmentation fault (core dumped)
> > > > > 
> > > > > 
> > > >  My guess is that your uhd_fft was linked against a different
> > > > version of the UHD library than you currently have on your
> > > > system.
> > > > 
> > > > 
> > > > > On Tue, Jul 9, 2019 at 4:10 PM Saeid Hashemi <
> > > > > sae...@gmail.com> wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > Running the command "uhd_fft" has been giving this result
> > > > > > for me, would anyone have a recommendation on how to fix
> > > > > > the issue?
> > > > > > 
> > > > > > Thanks and regards,
> > > > > > Saeid
> > > > > > 
> > > > > 
> > > > > 
> > > > > ___
> > > > > 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] Fwd: How to escape from overflow error?

2019-05-30 Thread Marcus Müller via USRP-users
Hi Ivan,

now you've got two Marcuses having told you that the Python API is not
the way to go; I'm afraid that means that for the time being, I'll have
to remind you that, albeit being a mighty and complex programming
language, C++ will be the language of choice. UHD comes with quite a
few ready-to-use examples that you can modify. 

Regarding your problem imagining how to work without delays:
You have a device that supports timed commands. You need no delays at
all! Simply use timed commands to specify the time at which tuning
should take place, and the N210 will do that tuning for you. No matter
what you do, NEVER block in the recv() loop; you're the one personally
causing the overflows here!

Also, I think I've spent a whole email thread explaining that
NUM_AND_DONE does in fact not help you.

So, to conclude:

> Can you tell me some way out of this situation? 

* Use C++, not Python. This will require you to learn a new language.
* Use timed commands for tuning. You should probably move that to a
separate thread than the loop over recv()
* Don't expect NUM_SAMPS_AND_DONE to remove your program's
responsibility to call recv() as fast as it can until all samples are
received
* Use existing C++ examples
* Consider starting fundamentally simpler: your NUM_SAMPS_AND_DONE
doesn't alleviate any problem, so it just makes it harder for you to
build a working solution. Start with a continuous receive implemented
by START_CONTINUOUS and an infinite loop of recv() in one thread, and
tune with the other thread. 

As a matter of fact, there is already software that implements the last
point: The UHD USRP Source in GNU Radio. You could simply click
together a small GNU Radio flow graph consisting of nothing but a USRP
Source and a file sink, and add a python block that periodically sends
messages to the USRP Source instructing it to tune. 

Best regards,
Marcus M

On Thu, 2019-05-30 at 09:20 +0300, Ivan Zahartchuk via USRP-users
wrote:
> Unfortunately, Python is the only programming language I know. And I
> somehow difficult to imagine how without delay delays frequency
> tuning and continuous reading. I think that the NUM_AND_DONE mode
> will help me, but I do not know how to insist on it correctly and
> whether my reasoning on this is correct. Can you tell me some way out
> of this situation? I think I'm not the first to want to implement
> such a project on Ettus boards.
> 
> ср, 29 мая 2019 г. в 22:56, Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com>:
> > On 05/29/2019 03:29 AM, Ivan Zahartchuk via USRP-users wrote:
> > > 
> > > Yes, I expanded the buffer as suggested in the driver. I made a
> > > test file for working with the board, here is its code.
> > > import uhd
> > > import numpy as np
> > > from uhd import libpyuhd as lib
> > > import time
> > > import scipy.signal as signal
> > > import pyqtgraph as pg
> > > pw = pg.plot()
> > > import time
> > > 
> > > num_samps=363*5
> > > usrp = uhd.usrp.MultiUSRP('')
> > > usrp.set_rx_subdev_spec(uhd.usrp.SubdevSpec('A:0'))
> > > print(usrp.get_pp_string())
> > > usrp.set_rx_rate(25e6)
> > > print(usrp.get_rx_rate()/1e6)
> > > 
> > > stream_args=uhd.usrp.StreamArgs("fc32",'sc16')
> > > stream_args.channels=[0]
> > > rx_streamer=usrp.get_rx_stream(stream_args)
> > > stream_cmd=uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)
> > > stream_cmd.num_samps=num_samps
> > > stream_cmd.stream_now=False
> > > usrp.set_time_now(uhd.types.TimeSpec(0.0))
> > > stream_cmd.time_spec=uhd.types.TimeSpec(0.001)
> > > rx_streamer.issue_stream_cmd(stream_cmd)
> > > md = uhd.types.RXMetadata()
> > > buffer_samps = rx_streamer.get_max_num_samps()
> > > recv_buffer = np.zeros((len([0]), buffer_samps),
> > > dtype=np.complex64)
> > > result = np.empty((len([0]), num_samps), dtype=np.complex64)
> > > 
> > > 
> > > def fft_slices(x):
> > > #x = self.butter_bandpass_filter(x, -12.5e6, 12.5e6,
> > > 100e6, order=6)
> > > window = signal.hanning(363*5)
> > > fx = np.fft.fftshift(np.fft.fft(window[np.newaxis, :] * x,
> > > axis=1))
> > > 
> > > Pxx = np.abs(fx) ** 2 / (np.abs(window) ** 2).sum()
> > > Pxx[:, 1:-1] *= 2
> > > 
> > > Pxx = 20 * np.log10(Pxx ** 0.5)
> > > return Pxx
> > > def fft_test(x):
> > > 
> > > sample_freq,power=signal.welch(x,fs=25e6,window="hamm",
> > > nperseg=num_samps,scaling="spectrum")
> > > power=np.fft.fftshift(power)/1.5
> > > return 10 * np.log10(power)
> > > 
> > > 
> > > 
> > > 
> > > while True:
> > > 
> > > result = np.empty((len([0]), num_samps), dtype=np.complex64)
> > > k = uhd.types.TuneRequest(np.random.randint(900e6, 1000e6))
> > > usrp.set_rx_freq(k)
> > > while usrp.get_rx_sensor("lo_locked").to_bool() != True:
> > > continue
> > > #print(usrp.get_rx_freq())
> > > recv_samps = 0
> > > 
> > > while recv_samps < num_samps:
> > > 
> > > samps = rx_streamer.recv(recv_buffer, md)
> > > time.sleep(0.001)
> > > 
> > > if 

Re: [USRP-users] Running network mode on E310 and N300

2019-05-21 Thread Marcus Müller via USRP-users
Hm, if you have to provide a uniform interface, but need to use
different versions of UHD underneath: What about simply building two
identical libraries that use the two necessary versions of UHD, and
only runtime-link (plugin-style) either shared object at run time,
depending on which USRP you need to talk to?

Best regards,
Marcus
On Mon, 2019-05-20 at 12:45 -1000, MASDR GS wrote:
> Hi Marcus,
> 
> Thank you for your response. Unfortunately our N300s have Rev H
> motherboards so version 3.12 doesn't seem to be an option for us.
> 
> Regarding our application, we have been using the E310s for our
> waveform application development over the past few years and recently
> received two new N300s to provide improved performance in network
> mode.  We are currently working with one license for a software
> development tool that restricts us to network mode only due to
> licensing restrictions.  One of our project objectives is to develop
> portable, hardware agnostic waveform applications so that we can
> conceivably use our applications on various SDR platforms.  Therefore
> we'd like to have the flexibility to switch between both the e310 and
> N300 for development purposes and demonstrate software portability. 
> Appreciate any suggestions/feedback on alternative options you may
> have that would allow us to use both SDRs from one host machine.  
> 
> 
> 
> 
> 
> On Sun, May 19, 2019 at 8:34 AM Marcus Müller <
> marcus.muel...@ettus.com> wrote:
> > Hi!
> > 
> > Network mode on E310 was highly undesirable (reliable rates below
> > 2MS/s) and not compatible with RFNoC, and hence has been disabled
> > in
> > recent versions of UHD. I've always considered Network Mode on the
> > E310
> > to be a testing tool, not something you'd want to do for streaming,
> > to
> > be completely honest!
> > 
> > The N300's network interfacing is fundamentally different and
> > optimized
> > for network streaming. The typical use case for the N300 would use
> > one
> > of the (up to 10Gb/s) SFP+ ports for network sample streaming, and
> > the
> > 1Gb/s RJ45 ethernet port to "talk" to the ARM host inside, for
> > control. 
> > Versions of UHD supporting the N300 start at 3.12.0.0 (but only for
> > hardware revisions up to motherboard revision G; you'll need
> > 3.13.0.2
> > for that); starting with 3.13.0.0, there is no network mode on the
> > E310.
> > I'll be honest and say: while this sounds like you could be using
> > 3.12.0.0 to run your E310 in network mode and still use your N300
> > (given it's not rev G or later), that would be a suboptimal
> > solution
> > considering the N3xx improvements that were introduced with 3.13.
> > and
> > 3.14.0.0.
> > 
> > So, maybe you could elaborate on the application you're having for
> > the
> > E310 network mode in combination with N300? There might be an easy
> > way
> > around the obstacle you're encountering, but I don't really know
> > what
> > you're planning to do from here.
> > 
> > Best regards,
> > Marcus
> > 
> > On Wed, 2019-05-15 at 12:53 -1000, MASDR GS via USRP-users wrote:
> > > Would it be possible to run network mode on both E310 and N300
> > using
> > > the latest UHD driver v3.14.0?
> > > 
> > > The N300 requires v3.12.0 or greater to run host mode and I
> > currently
> > > have release-4 with a UHD version v3.9.2 on the E310. But the
> > > condition to run network mode is that the UHD drivers of radio
> > and
> > > host machine must match. I couldn't find any information on how
> > to
> > > update the E310 UHD drivers directly, but I have tried creating a
> > SDK
> > > version using release-4 building UHD v3.14.0 but wasn't
> > successful
> > > running network mode with E310. Any suggestions or help would be
> > > really appreciated.
> > > ___
> > > 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] Running network mode on E310 and N300

2019-05-19 Thread Marcus Müller via USRP-users
Hi!

Network mode on E310 was highly undesirable (reliable rates below
2MS/s) and not compatible with RFNoC, and hence has been disabled in
recent versions of UHD. I've always considered Network Mode on the E310
to be a testing tool, not something you'd want to do for streaming, to
be completely honest!

The N300's network interfacing is fundamentally different and optimized
for network streaming. The typical use case for the N300 would use one
of the (up to 10Gb/s) SFP+ ports for network sample streaming, and the
1Gb/s RJ45 ethernet port to "talk" to the ARM host inside, for
control. 
Versions of UHD supporting the N300 start at 3.12.0.0 (but only for
hardware revisions up to motherboard revision G; you'll need 3.13.0.2
for that); starting with 3.13.0.0, there is no network mode on the
E310.
I'll be honest and say: while this sounds like you could be using
3.12.0.0 to run your E310 in network mode and still use your N300
(given it's not rev G or later), that would be a suboptimal solution
considering the N3xx improvements that were introduced with 3.13. and
3.14.0.0.

So, maybe you could elaborate on the application you're having for the
E310 network mode in combination with N300? There might be an easy way
around the obstacle you're encountering, but I don't really know what
you're planning to do from here.

Best regards,
Marcus

On Wed, 2019-05-15 at 12:53 -1000, MASDR GS via USRP-users wrote:
> Would it be possible to run network mode on both E310 and N300 using
> the latest UHD driver v3.14.0?
> 
> The N300 requires v3.12.0 or greater to run host mode and I currently
> have release-4 with a UHD version v3.9.2 on the E310. But the
> condition to run network mode is that the UHD drivers of radio and
> host machine must match. I couldn't find any information on how to
> update the E310 UHD drivers directly, but I have tried creating a SDK
> version using release-4 building UHD v3.14.0 but wasn't successful
> running network mode with E310. Any suggestions or help would be
> really appreciated.
> ___
> 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] Noise Capture with B200mini

2019-05-14 Thread Marcus Müller via USRP-users
Hello Andre,

I suspect three things being at work here:

1. Spurs from the mixer / synthesizer: Plot the |FFT|² (i.e. simply
play back the file through a Qt GUI frequency sink) with a high FFT
length. Do you see peaks in there? With the PSD (assuming the signal is
WSS) being both the Magnitude square of the Fourier transform of the
signal AND the value of the Fourier transform of the autocorrelation
function, peaks here indicate a sinusoidal correlation, as you might be
observing.

2. The anti-aliasing filters of course convert a perfectly white signal
to a bandlimited signal: you should see "roundish" rolloff at the edges
of the nyquist zone. That of course (through the inverse FT)
corresponds to a non-dirac autocorrelation function, i.e. correlation. 

3. By overdriving the analog receive chain, you might be bringing it to
behave nonlinearly; a simple thought experiment shows that this might
be ruining the whiteness of your noise (i.e. the uncorrelatedness):
uncorrelated noise must have a zero mean.
Squaring zero-mean noise of any variance > 0 must lead to non-zero mean
noise.
Zero-mean noise means a dirac impulse in the PSD at f=0.
That means correlatedness.

Also, nonlinearity will lead to increased spurs and spur
intermodulation (see 1.).

So, make sure you're not overdriving your receive chain – it's a
delicate flower!

Best regards,
Marcus

On Tue, 2019-05-14 at 13:38 -0600, Andre Rosete via USRP-users wrote:
> Hello
> 
> I captured noise samples (from an attached noise diode) with the
> B200mini using GNU Radio Companion. I set the gain to 90 dB with the
> intention of minimizing the noise figure. However, this caused the
> noise samples to show correlation - as if they were samples of a
> signal, rather than AWGN, which should be uncorrelated. I used 40 MHz
> of bandwidth and 40 Megasamples per second, with center frequency at
> 5800 MHz.
> 
> Is this a known issue, and are there optimal settings that I can use
> to minimize noise sample correlation? For example, with respect to
> gain?
> 
> ___
> 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] Reading samples with b200 using num_sams_and_done

2019-05-12 Thread Marcus Müller via USRP-users
Hm, are you 100% sure that you really received as many samples as you
ordered before?


On Sun, 2019-05-12 at 12:41 +0300, Ivan Zahartchuk wrote:
> Good morning. Thanks for your answers, I fixed the record in the data
> array. But it did not help me. But I noticed that everything works
> for me when I add a cycle
>   while samps:
>  samps = self.streamer_rx.recv (self.recv_buff,
> self.metadata_rx)
> after
> self.stream_cmd = lib.types.stream_cmd
> (lib.types.stream_mode.stop_cont)
>  self.streamer_rx.issue_stream_cmd (self.stream_cmd).
> I don’t fully understand why this cycle after closing reads and
> besides it very much slows down the work of the program, which for me
> is a critical moment.
> 
> 
> def test_reciev_2(self, freq, bandwich):
> complex_buffs = np.empty((len([0]), self.samples * len(freq)))
> buffs = np.empty((len([0]), self.samples * len(freq)))
> result = np.empty((len([0]), self.samples), dtype=np.complex64)
> 
> for i, freqq in enumerate(freq):
> 
> recv_samps = 0
> # self.usrp.set_rx_rate(bandwich[i])
> k = uhd.types.TuneRequest(freqq)
> # k.args(uhd.types.device_addr("mode_n=integer"))
> self.usrp.set_rx_freq(k)
> self.stream_cmd =
> uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)
> self.stream_cmd.stream_now = True
> self.streamer_rx.issue_stream_cmd(self.stream_cmd)
> while self.usrp.get_rx_sensor("lo_locked").to_bool() != True:
> continue
> 
> samps = np.array([], dtype=np.complex64)
> while recv_samps < self.samples:
> 
> samps = self.streamer_rx.recv(self.recv_buff,
> self.metadata_rx)
> if self.metadata_rx.error_code !=
> lib.types.rx_metadata_error_code.none:
> print(self.metadata_rx.strerror())
> if samps:
> real_samps = min(self.samples - recv_samps, samps)
> result[:, recv_samps:recv_samps + real_samps] =
> self.recv_buff[:, 0:real_samps]
> recv_samps += real_samps
> # print (self.usrp.get_rx_sensor('rssi'))
> # print(self.streamer_rx.get_max_num_samps())
> 
> # self.stream_cmd.time_spec = lib.types.time_spec(0)
> self.stream_cmd =
> lib.types.stream_cmd(lib.types.stream_mode.stop_cont)
> self.streamer_rx.issue_stream_cmd(self.stream_cmd)
> 
> while samps:
> samps = self.streamer_rx.recv(self.recv_buff,
> self.metadata_rx)
> 
> #complex_buffs = np.append(complex_buffs, result).ravel()
> # correct_result=result
> #correct_result_1 = result - (np.mean(result.real) +
> np.mean(result.imag) * 1j)
> # correct_result.real=result.real-np.mean(result.real)
> # correct_result.imag = result.imag - np.mean(result.imag)
> 
> PSD = self.fft_test(result)
> 
> # PSD[8188:8202]=np.mean(PSD[8180:8188])
> 
> buffs[:, i * value.samples:value.samples * i + value.samples]
> = PSD[:, 0:value.samples]
> 
> return complex_buffs, buffs.ravel()
> 
> вс, 12 мая 2019 г. в 02:35, Marcus Müller :
> > Ah, I see you think that this burst can't be too hard on your
> > computer,
> > because it arrives "at once"? That's not the case.
> > On Sun, 2019-05-12 at 01:18 +0200, Marcus Müller wrote:
> > > Um, sorry, I don't understand your sentence. Of course we have to
> > > care
> > > about these samples. Otherwise, we get an overflow. That is
> > literally
> > > what overflow means: Samples not getting received by the program
> > > using
> > > UHD in time before a buffer overflows.
> > > 
> > > On Sat, 2019-05-11 at 22:29 +0300, Ivan Zahartchuk wrote:
> > > > No, I meant that all system performance is enabled only when we
> > > > make
> > > > a request and not all the time. And we no longer care what we
> > do
> > > > next
> > > > with these samples, they are just an array and the board does
> > not
> > > > require constant reading.
> > > > 
> > > > вс, 12 мая 2019 г. в 01:03, Marcus Müller <
> > marcus.muel...@ettus.com
> > > > >:
> > > > > I'm not quite sure how you come to the conclusion that we
> > > > > wouldn't
> > > > > be
> > > > > tied to system performance in that case: that number of
> > samples
> > > > > still
> > > > > needs to be received by the software running on the computer.
> > > > > 
> > > > > Best regards,
> > > > > Marcus
> > > > > 
> > > > > On Sat, 2019-05-11 at 20:39 +0300, Ivan Zahartchuk wrote:
> > > > > > Thanks for the help. I will try to fix everything tomorrow
> > and
> > > > > see
> > > > > > the result. But tell me, maybe I don’t fully understand how
> > > > > > num_sams_and_done works. If I understand correctly, this
> > method
> > > > > does
> > > > > > not send a continuous stream of data but simply gives a
> > certain
> > > > > > number of samples upon request. And in this case, we are
> > not
> > > > > > tied
> > > > > to
> > > > > > system performance. Maybe I do not understand this. Could
> > you
> > > 

Re: [USRP-users] Reading samples with b200 using num_sams_and_done

2019-05-11 Thread Marcus Müller via USRP-users
Ah, I see you think that this burst can't be too hard on your computer,
because it arrives "at once"? That's not the case.
On Sun, 2019-05-12 at 01:18 +0200, Marcus Müller wrote:
> Um, sorry, I don't understand your sentence. Of course we have to
> care
> about these samples. Otherwise, we get an overflow. That is literally
> what overflow means: Samples not getting received by the program
> using
> UHD in time before a buffer overflows.
> 
> On Sat, 2019-05-11 at 22:29 +0300, Ivan Zahartchuk wrote:
> > No, I meant that all system performance is enabled only when we
> > make
> > a request and not all the time. And we no longer care what we do
> > next
> > with these samples, they are just an array and the board does not
> > require constant reading.
> > 
> > вс, 12 мая 2019 г. в 01:03, Marcus Müller  > >:
> > > I'm not quite sure how you come to the conclusion that we
> > > wouldn't
> > > be
> > > tied to system performance in that case: that number of samples
> > > still
> > > needs to be received by the software running on the computer.
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Sat, 2019-05-11 at 20:39 +0300, Ivan Zahartchuk wrote:
> > > > Thanks for the help. I will try to fix everything tomorrow and
> > > see
> > > > the result. But tell me, maybe I don’t fully understand how
> > > > num_sams_and_done works. If I understand correctly, this method
> > > does
> > > > not send a continuous stream of data but simply gives a certain
> > > > number of samples upon request. And in this case, we are not
> > > > tied
> > > to
> > > > system performance. Maybe I do not understand this. Could you
> > > clarify
> > > > this?
> > > > 
> > > > сб, 11 мая 2019 г. в 23:19, Marcus Müller <
> > > marcus.muel...@ettus.com>:
> > > > > Dear Ivan,
> > > > > 
> > > > > On Sat, 2019-05-11 at 20:00 +0300, Ivan Zahartchuk wrote:
> > > > > > Sorry I did not specify. When working with the start_cont
> > > mode
> > > > > with a
> > > > > > frequency of more than 5 MHz, I have an overflow error. 
> > > > > 
> > > > > Which probably happens due to the inefficient way you handle
> > > the
> > > > > data;
> > > > > your program simply is too slow.
> > > > > 
> > > > > > That leads to a chaotic change in the spectrum. I agree
> > > > > > about
> > > the
> > > > > > wrong allocation of memory, but I created my own data array
> > > and
> > > > > ran
> > > > > > it through the whole chain of changes and additions and had
> > > what
> > > > > I
> > > > > > expected at the output. 
> > > > > 
> > > > > Huh? When using offline data, your computationally load
> > > > > doesn't
> > > > > matter;
> > > > > I'm not sure I'm understanding you correctly here! 
> > > > > 
> > > > > > Moreover, the data array was much more than what I get from
> > > the
> > > > > > board. In this regard, I decided that the matter is in the
> > > > > reading
> > > > > > from the board.
> > > > > 
> > > > > I'll allow myself to doubt that: Again, the fact that your
> > > > > data
> > > > > array
> > > > > runs through smoothly is no indication for your software
> > > > > being
> > > fast
> > > > > enough to keep up with the torrent of samples UHD will give
> > > you!
> > > > > When
> > > > > it doesn't keep up, you see exactly what you're describing:
> > > > > UHD
> > > > > reporting overflows due to your software not fetching samples
> > > fast
> > > > > enough. Overflows aren't UHD bugs, they are problems in the
> > > > > way
> > > you
> > > > > use
> > > > > UHD!
> > > > > 
> > > > > >  I have seen examples, but start_cont mode is used there
> > > > > > and
> > > > > there
> > > > > > are not so many frequency adjustments. Therefore, I decided
> > > to
> > > > > use
> > > > > > the num_sams_and_done mode, but there is also a problem
> > > > > > with
> > > it
> > > > > which
> > > > > > is described in the previous message. If you have more
> > > > > suggestions, I
> > > > > > will be very grateful to you.
> > > > > 
> > > > > Well, exactly what I wrote in my previous mail: you need to
> > > make
> > > > > your
> > > > > software fast enough. Preallocate the buffer; don't append to
> > > its
> > > > > end.
> > > > > 
> > > > > Aside from that, do some profiling. Under linux, `perf top
> > > > > -ag
> > > > > python
> > > > > yourscript.py` is your friend to figure out where your
> > > > > program
> > > > > spends
> > > > > its CPU cycles.
> > > > > 
> > > > > Best regards,
> > > > > Marcus
> > > > > 
> > > > > > сб, 11 мая 2019 г. в 22:27, Marcus Müller <
> > > > > marcus.muel...@ettus.com>:
> > > > > > > Dear Ivan,
> > > > > > > 
> > > > > > > it's not clear what you've modified. I'm not aware of any
> > > UHD
> > > > > > > function
> > > > > > > that restricts any frequency to 5 MHz.
> > > > > > > Could you elaborate on which code you're basing this on?
> > > > > > > 
> > > > > > > Also, while I really like the Python interface, if you're
> > > > > really
> > > > > > > after
> > > > > > > high-rate sampling, it might simply not be the optimal
> > > 

Re: [USRP-users] Reading samples with b200 using num_sams_and_done

2019-05-11 Thread Marcus Müller via USRP-users
Um, sorry, I don't understand your sentence. Of course we have to care
about these samples. Otherwise, we get an overflow. That is literally
what overflow means: Samples not getting received by the program using
UHD in time before a buffer overflows.

On Sat, 2019-05-11 at 22:29 +0300, Ivan Zahartchuk wrote:
> No, I meant that all system performance is enabled only when we make
> a request and not all the time. And we no longer care what we do next
> with these samples, they are just an array and the board does not
> require constant reading.
> 
> вс, 12 мая 2019 г. в 01:03, Marcus Müller :
> > I'm not quite sure how you come to the conclusion that we wouldn't
> > be
> > tied to system performance in that case: that number of samples
> > still
> > needs to be received by the software running on the computer.
> > 
> > Best regards,
> > Marcus
> > 
> > On Sat, 2019-05-11 at 20:39 +0300, Ivan Zahartchuk wrote:
> > > Thanks for the help. I will try to fix everything tomorrow and
> > see
> > > the result. But tell me, maybe I don’t fully understand how
> > > num_sams_and_done works. If I understand correctly, this method
> > does
> > > not send a continuous stream of data but simply gives a certain
> > > number of samples upon request. And in this case, we are not tied
> > to
> > > system performance. Maybe I do not understand this. Could you
> > clarify
> > > this?
> > > 
> > > сб, 11 мая 2019 г. в 23:19, Marcus Müller <
> > marcus.muel...@ettus.com>:
> > > > Dear Ivan,
> > > > 
> > > > On Sat, 2019-05-11 at 20:00 +0300, Ivan Zahartchuk wrote:
> > > > > Sorry I did not specify. When working with the start_cont
> > mode
> > > > with a
> > > > > frequency of more than 5 MHz, I have an overflow error. 
> > > > 
> > > > Which probably happens due to the inefficient way you handle
> > the
> > > > data;
> > > > your program simply is too slow.
> > > > 
> > > > > That leads to a chaotic change in the spectrum. I agree about
> > the
> > > > > wrong allocation of memory, but I created my own data array
> > and
> > > > ran
> > > > > it through the whole chain of changes and additions and had
> > what
> > > > I
> > > > > expected at the output. 
> > > > 
> > > > Huh? When using offline data, your computationally load doesn't
> > > > matter;
> > > > I'm not sure I'm understanding you correctly here! 
> > > > 
> > > > > Moreover, the data array was much more than what I get from
> > the
> > > > > board. In this regard, I decided that the matter is in the
> > > > reading
> > > > > from the board.
> > > > 
> > > > I'll allow myself to doubt that: Again, the fact that your data
> > > > array
> > > > runs through smoothly is no indication for your software being
> > fast
> > > > enough to keep up with the torrent of samples UHD will give
> > you!
> > > > When
> > > > it doesn't keep up, you see exactly what you're describing: UHD
> > > > reporting overflows due to your software not fetching samples
> > fast
> > > > enough. Overflows aren't UHD bugs, they are problems in the way
> > you
> > > > use
> > > > UHD!
> > > > 
> > > > >  I have seen examples, but start_cont mode is used there and
> > > > there
> > > > > are not so many frequency adjustments. Therefore, I decided
> > to
> > > > use
> > > > > the num_sams_and_done mode, but there is also a problem with
> > it
> > > > which
> > > > > is described in the previous message. If you have more
> > > > suggestions, I
> > > > > will be very grateful to you.
> > > > 
> > > > Well, exactly what I wrote in my previous mail: you need to
> > make
> > > > your
> > > > software fast enough. Preallocate the buffer; don't append to
> > its
> > > > end.
> > > > 
> > > > Aside from that, do some profiling. Under linux, `perf top -ag
> > > > python
> > > > yourscript.py` is your friend to figure out where your program
> > > > spends
> > > > its CPU cycles.
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > > 
> > > > > сб, 11 мая 2019 г. в 22:27, Marcus Müller <
> > > > marcus.muel...@ettus.com>:
> > > > > > Dear Ivan,
> > > > > > 
> > > > > > it's not clear what you've modified. I'm not aware of any
> > UHD
> > > > > > function
> > > > > > that restricts any frequency to 5 MHz.
> > > > > > Could you elaborate on which code you're basing this on?
> > > > > > 
> > > > > > Also, while I really like the Python interface, if you're
> > > > really
> > > > > > after
> > > > > > high-rate sampling, it might simply not be the optimal
> > thing to
> > > > > > use:
> > > > > > You'd have to be very careful in Pythonland to not run into
> > > > > > performance
> > > > > > problems once you've gotten the samples from UHD:
> > > > > > 
> > > > > >   
> >  complex_buffs=np.append(complex_buffs,result).ravel()
> > > > > > 
> > > > > > A very bad idea. You're constantly re-allocating buffers
> > here.
> > > > > > Don't do
> > > > > > that. No matter in which programming language you'd do
> > this,
> > > > you'd
> > > > > > make
> > > > > > sure that the buffer is large enough for your data

Re: [USRP-users] Reading samples with b200 using num_sams_and_done

2019-05-11 Thread Marcus Müller via USRP-users
I'm not quite sure how you come to the conclusion that we wouldn't be
tied to system performance in that case: that number of samples still
needs to be received by the software running on the computer.

Best regards,
Marcus

On Sat, 2019-05-11 at 20:39 +0300, Ivan Zahartchuk wrote:
> Thanks for the help. I will try to fix everything tomorrow and see
> the result. But tell me, maybe I don’t fully understand how
> num_sams_and_done works. If I understand correctly, this method does
> not send a continuous stream of data but simply gives a certain
> number of samples upon request. And in this case, we are not tied to
> system performance. Maybe I do not understand this. Could you clarify
> this?
> 
> сб, 11 мая 2019 г. в 23:19, Marcus Müller :
> > Dear Ivan,
> > 
> > On Sat, 2019-05-11 at 20:00 +0300, Ivan Zahartchuk wrote:
> > > Sorry I did not specify. When working with the start_cont mode
> > with a
> > > frequency of more than 5 MHz, I have an overflow error. 
> > 
> > Which probably happens due to the inefficient way you handle the
> > data;
> > your program simply is too slow.
> > 
> > > That leads to a chaotic change in the spectrum. I agree about the
> > > wrong allocation of memory, but I created my own data array and
> > ran
> > > it through the whole chain of changes and additions and had what
> > I
> > > expected at the output. 
> > 
> > Huh? When using offline data, your computationally load doesn't
> > matter;
> > I'm not sure I'm understanding you correctly here! 
> > 
> > > Moreover, the data array was much more than what I get from the
> > > board. In this regard, I decided that the matter is in the
> > reading
> > > from the board.
> > 
> > I'll allow myself to doubt that: Again, the fact that your data
> > array
> > runs through smoothly is no indication for your software being fast
> > enough to keep up with the torrent of samples UHD will give you!
> > When
> > it doesn't keep up, you see exactly what you're describing: UHD
> > reporting overflows due to your software not fetching samples fast
> > enough. Overflows aren't UHD bugs, they are problems in the way you
> > use
> > UHD!
> > 
> > >  I have seen examples, but start_cont mode is used there and
> > there
> > > are not so many frequency adjustments. Therefore, I decided to
> > use
> > > the num_sams_and_done mode, but there is also a problem with it
> > which
> > > is described in the previous message. If you have more
> > suggestions, I
> > > will be very grateful to you.
> > 
> > Well, exactly what I wrote in my previous mail: you need to make
> > your
> > software fast enough. Preallocate the buffer; don't append to its
> > end.
> > 
> > Aside from that, do some profiling. Under linux, `perf top -ag
> > python
> > yourscript.py` is your friend to figure out where your program
> > spends
> > its CPU cycles.
> > 
> > Best regards,
> > Marcus
> > 
> > > 
> > > сб, 11 мая 2019 г. в 22:27, Marcus Müller <
> > marcus.muel...@ettus.com>:
> > > > Dear Ivan,
> > > > 
> > > > it's not clear what you've modified. I'm not aware of any UHD
> > > > function
> > > > that restricts any frequency to 5 MHz.
> > > > Could you elaborate on which code you're basing this on?
> > > > 
> > > > Also, while I really like the Python interface, if you're
> > really
> > > > after
> > > > high-rate sampling, it might simply not be the optimal thing to
> > > > use:
> > > > You'd have to be very careful in Pythonland to not run into
> > > > performance
> > > > problems once you've gotten the samples from UHD:
> > > > 
> > > > complex_buffs=np.append(complex_buffs,result).ravel()
> > > > 
> > > > A very bad idea. You're constantly re-allocating buffers here.
> > > > Don't do
> > > > that. No matter in which programming language you'd do this,
> > you'd
> > > > make
> > > > sure that the buffer is large enough for your data collection
> > to
> > > > begin
> > > > with and then tell the UHD library to fill the appropriate part
> > in
> > > > that
> > > > buffer to avoid a) having to ask for a larger buffer regularly
> > and
> > > > b)
> > > > avoid copying data.
> > > > Asking for an appended version of your last buffer means that
> > > > something
> > > > has to allocate a larger buffer – which comes at very large
> > cost!
> > > > 
> > > > Best regards,
> > > > Marcus 
> > > > 
> > > > On Sat, 2019-05-11 at 21:31 +0300, Ivan Zahartchuk via USRP-
> > users
> > > > wrote:
> > > > > Hello. My task is to make a broadband spectrum analyzer on
> > the
> > > > usrp
> > > > > b200 board. For this, the standard functions for reading
> > samples
> > > > in
> > > > > python are not suitable for me. Therefore, I edited them.
> > When
> > > > > reading samples using the start_con method, I cannot specify
> > a
> > > > band
> > > > > greater than 5 MHz. Therefore, I use the num_sams_and_done
> > > > method.
> > > > > But I have problems with him. The fact is that my frequency
> > which
> > > > I
> > > > > know appears in the wrong place. For example, I generate a
> > 

Re: [USRP-users] Reading samples with b200 using num_sams_and_done

2019-05-11 Thread Marcus Müller via USRP-users
Dear Ivan,

On Sat, 2019-05-11 at 20:00 +0300, Ivan Zahartchuk wrote:
> Sorry I did not specify. When working with the start_cont mode with a
> frequency of more than 5 MHz, I have an overflow error. 

Which probably happens due to the inefficient way you handle the data;
your program simply is too slow.

> That leads to a chaotic change in the spectrum. I agree about the
> wrong allocation of memory, but I created my own data array and ran
> it through the whole chain of changes and additions and had what I
> expected at the output. 

Huh? When using offline data, your computationally load doesn't matter;
I'm not sure I'm understanding you correctly here! 

> Moreover, the data array was much more than what I get from the
> board. In this regard, I decided that the matter is in the reading
> from the board.

I'll allow myself to doubt that: Again, the fact that your data array
runs through smoothly is no indication for your software being fast
enough to keep up with the torrent of samples UHD will give you! When
it doesn't keep up, you see exactly what you're describing: UHD
reporting overflows due to your software not fetching samples fast
enough. Overflows aren't UHD bugs, they are problems in the way you use
UHD!

>  I have seen examples, but start_cont mode is used there and there
> are not so many frequency adjustments. Therefore, I decided to use
> the num_sams_and_done mode, but there is also a problem with it which
> is described in the previous message. If you have more suggestions, I
> will be very grateful to you.

Well, exactly what I wrote in my previous mail: you need to make your
software fast enough. Preallocate the buffer; don't append to its end.

Aside from that, do some profiling. Under linux, `perf top -ag python
yourscript.py` is your friend to figure out where your program spends
its CPU cycles.

Best regards,
Marcus

> 
> сб, 11 мая 2019 г. в 22:27, Marcus Müller :
> > Dear Ivan,
> > 
> > it's not clear what you've modified. I'm not aware of any UHD
> > function
> > that restricts any frequency to 5 MHz.
> > Could you elaborate on which code you're basing this on?
> > 
> > Also, while I really like the Python interface, if you're really
> > after
> > high-rate sampling, it might simply not be the optimal thing to
> > use:
> > You'd have to be very careful in Pythonland to not run into
> > performance
> > problems once you've gotten the samples from UHD:
> > 
> > complex_buffs=np.append(complex_buffs,result).ravel()
> > 
> > A very bad idea. You're constantly re-allocating buffers here.
> > Don't do
> > that. No matter in which programming language you'd do this, you'd
> > make
> > sure that the buffer is large enough for your data collection to
> > begin
> > with and then tell the UHD library to fill the appropriate part in
> > that
> > buffer to avoid a) having to ask for a larger buffer regularly and
> > b)
> > avoid copying data.
> > Asking for an appended version of your last buffer means that
> > something
> > has to allocate a larger buffer – which comes at very large cost!
> > 
> > Best regards,
> > Marcus 
> > 
> > On Sat, 2019-05-11 at 21:31 +0300, Ivan Zahartchuk via USRP-users
> > wrote:
> > > Hello. My task is to make a broadband spectrum analyzer on the
> > usrp
> > > b200 board. For this, the standard functions for reading samples
> > in
> > > python are not suitable for me. Therefore, I edited them. When
> > > reading samples using the start_con method, I cannot specify a
> > band
> > > greater than 5 MHz. Therefore, I use the num_sams_and_done
> > method.
> > > But I have problems with him. The fact is that my frequency which
> > I
> > > know appears in the wrong place. For example, I generate a
> > frequency
> > > of 910 MHz and it appears at 930 MHz (with a bandwidth of 20
> > MHz). I
> > > can not understand what caused it. Here are my reading functions
> > in
> > > two ways. I would be extremely grateful for the help.
> > > 
> > > 
> > > 
> > > 
> > > def test_reciev(self,freq,bandwich):
> > > complex_buffs=np.array([])
> > > buffs = np.array([])
> > > result = np.empty((len([0]), self.samples),
> > dtype=np.complex64)
> > > 
> > > for i, freqq in enumerate(freq):
> > > 
> > > recv_samps = 0
> > > #self.usrp.set_rx_rate(bandwich[i])
> > > k=uhd.types.TuneRequest(freqq)
> > > #k.args(uhd.types.device_addr("mode_n=integer"))
> > > self.usrp.set_rx_freq(k)
> > > self.stream_cmd =
> > > uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)
> > > self.stream_cmd.stream_now = True
> > > self.streamer_rx.issue_stream_cmd(self.stream_cmd)
> > > while self.usrp.get_rx_sensor("lo_locked").to_bool() !=
> > True:
> > > continue
> > > 
> > > samps = np.array([], dtype=np.complex64)
> > > while recv_samps < self.samples:
> > > 
> > > samps = self.streamer_rx.recv(self.recv_buff,
> > > self.metadata_rx)
> > > if 

Re: [USRP-users] Reading samples with b200 using num_sams_and_done

2019-05-11 Thread Marcus Müller via USRP-users
Dear Ivan,

it's not clear what you've modified. I'm not aware of any UHD function
that restricts any frequency to 5 MHz.
Could you elaborate on which code you're basing this on?

Also, while I really like the Python interface, if you're really after
high-rate sampling, it might simply not be the optimal thing to use:
You'd have to be very careful in Pythonland to not run into performance
problems once you've gotten the samples from UHD:

complex_buffs=np.append(complex_buffs,result).ravel()

A very bad idea. You're constantly re-allocating buffers here. Don't do
that. No matter in which programming language you'd do this, you'd make
sure that the buffer is large enough for your data collection to begin
with and then tell the UHD library to fill the appropriate part in that
buffer to avoid a) having to ask for a larger buffer regularly and b)
avoid copying data.
Asking for an appended version of your last buffer means that something
has to allocate a larger buffer – which comes at very large cost!

Best regards,
Marcus 

On Sat, 2019-05-11 at 21:31 +0300, Ivan Zahartchuk via USRP-users
wrote:
> Hello. My task is to make a broadband spectrum analyzer on the usrp
> b200 board. For this, the standard functions for reading samples in
> python are not suitable for me. Therefore, I edited them. When
> reading samples using the start_con method, I cannot specify a band
> greater than 5 MHz. Therefore, I use the num_sams_and_done method.
> But I have problems with him. The fact is that my frequency which I
> know appears in the wrong place. For example, I generate a frequency
> of 910 MHz and it appears at 930 MHz (with a bandwidth of 20 MHz). I
> can not understand what caused it. Here are my reading functions in
> two ways. I would be extremely grateful for the help.
> 
> 
> 
> 
> def test_reciev(self,freq,bandwich):
> complex_buffs=np.array([])
> buffs = np.array([])
> result = np.empty((len([0]), self.samples), dtype=np.complex64)
> 
> for i, freqq in enumerate(freq):
> 
> recv_samps = 0
> #self.usrp.set_rx_rate(bandwich[i])
> k=uhd.types.TuneRequest(freqq)
> #k.args(uhd.types.device_addr("mode_n=integer"))
> self.usrp.set_rx_freq(k)
> self.stream_cmd =
> uhd.types.StreamCMD(uhd.types.StreamMode.start_cont)
> self.stream_cmd.stream_now = True
> self.streamer_rx.issue_stream_cmd(self.stream_cmd)
> while self.usrp.get_rx_sensor("lo_locked").to_bool() != True:
> continue
> 
> samps = np.array([], dtype=np.complex64)
> while recv_samps < self.samples:
> 
> samps = self.streamer_rx.recv(self.recv_buff,
> self.metadata_rx)
> if self.metadata_rx.error_code !=
> lib.types.rx_metadata_error_code.none:
> print(self.metadata_rx.strerror())
> if samps:
> real_samps = min(self.samples - recv_samps, samps)
> result[:, recv_samps:recv_samps + real_samps] =
> self.recv_buff[:, 0:real_samps]
> recv_samps += real_samps
> #print (self.usrp.get_rx_sensor('rssi'))
> #print(self.streamer_rx.get_max_num_samps())
> #while samps:
> #samps = self.streamer_rx.recv(self.recv_buff,
> self.metadata_rx)
> 
> 
> #self.stream_cmd.time_spec = lib.types.time_spec(0)
> self.stream_cmd =
> lib.types.stream_cmd(lib.types.stream_mode.stop_cont)
> self.streamer_rx.issue_stream_cmd(self.stream_cmd)
> 
> complex_buffs=np.append(complex_buffs,result).ravel()
> #correct_result=result
> correct_result_1=result-
> (np.mean(result.real)+np.mean(result.imag)*1j)
> #correct_result.real=result.real-np.mean(result.real)
> #correct_result.imag = result.imag - np.mean(result.imag)
> 
> PSD =  self.fft_test(result)
> 
> 
> #PSD[8188:8202]=np.mean(PSD[8180:8188])
> 
> 
> buffs = np.append(buffs,PSD)
> 
> 
> 
> return complex_buffs,
> buffs#np.append(buffs[value.samples:],buffs[:value.samples])
> 
> 
> 
> def test_reciev(self,freq,bandwich):
> complex_buffs=np.array([])
> buffs = np.array([])
> result = np.empty((len([0]), self.samples), dtype=np.complex64)
> 
> for i, freqq in enumerate(freq):
> 
> recv_samps = 0
> #self.usrp.set_rx_rate(bandwich[i])
> k=uhd.types.TuneRequest(freqq)
> #k.args(uhd.types.device_addr("mode_n=integer"))
> self.usrp.set_rx_freq(k)
> 
> while self.usrp.get_rx_sensor("lo_locked").to_bool() != True:
> continue
> 
>
> while recv_samps < self.samples:
> 
> samps = self.streamer_rx.recv(self.recv_buff,
> self.metadata_rx)
> if self.metadata_rx.error_code !=
> lib.types.rx_metadata_error_code.none:
> print(self.metadata_rx.strerror())
> if samps:
> real_samps = min(self.samples - recv_samps, samps)
> result[:, 

Re: [USRP-users] B200 Overrun

2019-05-05 Thread Marcus Müller via USRP-users
So, what are the options with which you run usrp_spectrum_sense?


On Sun, 2019-05-05 at 19:23 +, Rensi Mathew via USRP-users wrote:
> Yes USB 3.0. 
> 
> The OS is Ubuntu 16.04 LTS 64-bit
> Intel® Core™ i5-4570 CPU @ 3.20GHz × 4 
> Disk 309.6 GB
> Memory 3.6 GiB
> 
> Could it because of memory problem?
> The yellow/orange light in the system blinks when USRP runs(showing
> heavily loaded).
> 
> Rensi
> On Saturday, 4 May, 2019, 10:09:03 am IST, Robin Coxe <
> robin.c...@ettus.com> wrote:
> 
> 
> Are you using USB 3.0?  USB 2.0 will max out at about 8 Ms/s.  
> 
> 
> 
> Robin Coxe | Chief R Program Manager, SDR | Santa Clara, CA |
> 408.610.6363
>  
> From: USRP-users  on behalf of
> Rensi Mathew via USRP-users 
> Sent: Friday, May 3, 2019 9:17 PM
> To: Vsr Ravi via USRP-users
> Subject: [USRP-users] B200 Overrun
>  
> Dear sir
> I am using B200 SDR to run the program usrp_spectrum_sense.py with a
> sampling frequency of 16e6.
> I think I am using a fairly low sampling rate.
> Still I am getting some ''.
> 
> Could someone tell me the possible reasons for the same? And how I
> can avoid the same?
> 
> Thanking you
> Rensi Sam
> 
> ___
> 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 Overrun

2019-05-04 Thread Marcus Müller via USRP-users
Dear Rensi, 

16 MS/s is actually pretty decent; modern PCs should be up to that,
yes, but considering that is 512 Mb/s in pure data, imperformant
hardware or OS parts might be a real showstopper here. 
So, what is your computer, its USB3 controller? What are the settings
of usrp_spectrum_sense that you use? FFTs aren't "free",
computationally...

Best regards
Marcus

On Sat, 2019-05-04 at 04:15 +, Rensi Mathew via USRP-users wrote:
> Dear sir
> I am using B200 SDR to run the program usrp_spectrum_sense.py with a
> sampling frequency of 16e6.
> I think I am using a fairly low sampling rate.
> Still I am getting some ''.
> 
> Could someone tell me the possible reasons for the same? And how I
> can avoid the same?
> 
> Thanking you
> Rensi Sam
> 
> ___
> 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 API about the recv() function

2019-05-03 Thread Marcus Müller via USRP-users
Hello,

when aiming for high IO throughput, Python is at the moment not the
language of choice.
You don't need to know much C++ to make an example work: the
rx_samples_to_files example that UHD installs can save directly to disk
in any CPU format.

But: honestly, a USB3 hard disk very likely won't sustain even 123
MB/s, in my experience. You need faster storage; an SSD is desirable
(as even fast internal hard disks bare exceed 200 MB/s even only in
short bursts), and USB3 isn't desirable at all. Do a benchmark with
your storage first – will it even theoretically achieve the write rate
you need?

For how long do you plan to record dual-channel record 30.72 MHz at
once? That will allow you/us to calculate whether using RAM buffering
might be a solution.

Best regards,
Marcus

On Sat, 2019-05-04 at 04:48 +0800, 应山川 via USRP-users wrote:
> Hello , I’m a beginner of the USRP and UHD software. I’m sorry l may
> deliver my question unclearly with my broken English.
> 
> 
> What I want:
> I need to receive the real-time radio signals with a B210 USRP
> device, according to my sample rate,I need an external hard disk to
> achieve at least 245.76MB/s using fc32 in my host.  But the USB3.0
> hard driver I  connecting to the host only get 180MB/s in write mode.
> Therefore,I want change the CPU_format from fc32 to sc16 to decrease
> the load in the USB3.0 transmission.
> 
> 
> What problem I confronted:
> I’m not familiar with CPP language, So I choose to drive the B210
> with python API.When I refer to the source code in Github/UHD , I
> find an example in /UHD/host/python/usrp.py. It tells me how to
> initialize a RX streamer and start receiving samples.These code are
>  
> ….
> st_args = lib.usrp.stream_args("fc32", "sc16”)
> ….
> 
> recv_buffer = np.zeros((len(channels), buffer_samps),
> dtype=np.complex64)
> ….
> 
> samps = streamer.recv(recv_buffer, metadata)
> ...
> 
> 
> I have some confusion as follow:
> 1、Must the recv_buffer be the numpy complex array? As far as I know,
> numpy only has the dtype complex64 and complex128. If I use the sc16
> as the cpu format, what kind  of numpy array should  I create to act
> as the ‘recv_buffer’?
> 
> 2、I try something workarounds, but I’m not sure the receive data are
> correct. 
> First:  st_args = lib.usrp.stream_args(“sc16", "sc16”)  # I
> change the CPU format to sc16
> Second:   recv_buffer = np.zeros((len(channels), buffer_samps*2),
> dtype=np.int16) # I create the array with double size
> buffer_samps, and  assign the ’np.int16’ to the dtype.
> Finally:   samps = streamer.recv(recv_buffer, metadata)   # receive
> the data in the int16 array
> 
> I guess the recv() function will return I and Q samples in pairs.I
> can print the integer from the array, but cannot confirm the
> correctness of this ‘method’.
> 
> 
> Please give me some suggestions about how to use ’sc16’ in python, I
> will appreciate it 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] uhd object file not found

2019-04-19 Thread Marcus Müller via USRP-users
You can't just take code from the main UHD source tree and compile it
out of that tree; you need to build them with the whole UHD repo's
build infrastructure, otherwise your linker won't know where to take
the functionality from that the program is using.

Also, you normally wouldn't use an ancient Matlab Mex compiler to build
modern UHD – that probably won't even work, because that compiler is
quite likely too old to support the modern(er) C++ that UHD is written
in.

Best regards,
Marcus

On Thu, 2019-04-18 at 16:57 +0200, VINAYAK KARANDIKAR via USRP-users
wrote:
> Hello,
>I am trying to mex compile(On MATLAB 2013b on a windows
> 10, 64 bit system) a file called  "rx_samples_to_file.cpp"
>which is obtained from 
> " 
> https://github.com/EttusResearch/uhd/blob/UHD-.10/host/examples/rx_samples_to_file.cpp
>  
> ;" 
> 
> This is to test USRP NI 2954R. (If compilation were to be successful,
> on connecting the device to laptop, i should be able to receive
> samples from USRP)
> 
> 
> I receive the error:
> "LINK : fatal error LNK1181: cannot open input file 'C:\Users\VINAYAK
> KARANDIKAR\Documents\MATLAB\MATLAB\Thesis\MATLAB_USRP_INTERFACE\UHD_s
> ample_programs_from_GitHub\uhd.obj' 
>  
>   C:\PROGRA~1\MATLAB\R2013B\BIN\MEX.PL: Error: Link of
> 'rx_samples_to_file.mexw64' failed. 
>  
> Unable to complete successfully."
> 
> 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] Gnuradio loopback TX and RX example

2019-03-25 Thread Marcus Müller via USRP-users
Hi Varban,

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

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

Best regards,
Marcus

On Mon, 2019-03-25 at 10:20 +0200, Varban Metodiev via USRP-users
wrote:
> Dear all,
> 
> For quite some time I have been trying to transmit a single byte in a
> loopback scenario. I have the following questions:
> 1) Could anyone help me with an example about this?
> 2) Right now I am sending the digital data directly to the USRP Sink
> block. Is this fine, or a one should send a digital description of an
> analog signal to it?
> 
> Thanks in advance,
> Varban
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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


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

2019-03-24 Thread Marcus Müller via USRP-users
I can fully understand that! You don't happen to have an estimate for
that frequency offset's magnitude? Is it always the same drift? I'm
trying to narrow down analog vs numerical accuracy issues here.

Best regards,
Marcus
On Sun, 2019-03-24 at 18:39 +, Freedman, Michael - 1008 - MITLL
wrote:
> It is not just a phase offset. It is a frequency offset. The phase
> drifts between the two. I can tolerate a phase offset at startup. A
> freq offset however is causing problems. 
> 
> Mike
> 
> Sent from my iPhone
> 
> On Mar 24, 2019, at 4:28 AM, Marcus Müller 
> wrote:
> 
> Can you elaborate on what "not coherent" means to you – the relative
> phase should be constant after each tune, but if you don't tune
> simultaneously, i.e. with timed commands, random at each tune.
> 
> Best regards,
> Marcus
> On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
> wrote:
> > Hello,
> > 
> > 
> > I have an issue where I tune both the TX and RX side of a UBX40
> > card
> > in 
> > an X310 to the same frequency and find that the transmitted signal
> > and 
> > what is received are not coherent.  I am using an external 10MHz 
> > reference and have tried the documented suggestions.
> > 
> > at 150MHz it is coherent.
> > 
> > at 155MHz it is NOT coherent.
> > 
> > 
> > I have tried setting the dboard_clock_rate to 20MHz.  This made
> > the 
> > problem appear at 150MHz as well.  I've tried integer_n tuning.
> > 
> > I have verified that the ref_lock and lo_lock are both true.
> > 
> > 
> > Any suggestions?
> > 
> > 
> > Mike
> > 
> > 
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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


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

2019-03-24 Thread Marcus Müller via USRP-users
Can you elaborate on what "not coherent" means to you – the relative
phase should be constant after each tune, but if you don't tune
simultaneously, i.e. with timed commands, random at each tune.

Best regards,
Marcus
On Sat, 2019-03-23 at 17:06 -0400, Michael R. Freedman via USRP-users
wrote:
> Hello,
> 
> 
> I have an issue where I tune both the TX and RX side of a UBX40 card
> in 
> an X310 to the same frequency and find that the transmitted signal
> and 
> what is received are not coherent.  I am using an external 10MHz 
> reference and have tried the documented suggestions.
> 
> at 150MHz it is coherent.
> 
> at 155MHz it is NOT coherent.
> 
> 
> I have tried setting the dboard_clock_rate to 20MHz.  This made the 
> problem appear at 150MHz as well.  I've tried integer_n tuning.
> 
> I have verified that the ref_lock and lo_lock are both true.
> 
> 
> Any suggestions?
> 
> 
> Mike
> 
> 
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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


Re: [USRP-users] Phase after Freq Hopping

2019-03-14 Thread Marcus Müller via USRP-users
That kind would be cool ;) .
But: since this is radar, the reason for all this is probably exceeding
the Nyquist bw of the DAC with the radar wave form :(

Cheers,
Marcus

On Tue, 2019-03-12 at 23:49 -0700, Ian Buckley via USRP-users wrote:
> > On Mar 12, 2019, at 3:05 PM, Marcus D. Leech via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> > 
> > On 03/12/2019 12:49 PM, Patscheider, Dominik via USRP-users wrote:
> > > Hello ,
> > >  
> > > For a Radar I´m transmitting and receiving with the USRP X310
> > > samples on different frequency steps.
> > >  
> > > For instance, after 4 frames I´m coming back to the first center
> > > freq and continue this a few times. Hope the following
> > > description helps…
> > >  
> > > f3   |phase4|   |…|
> > > f2  |phase3|   |…|
> > > f1   |phase2|   |phase6|   …
> > > f0|phase1|   |phase5|
> > > t -->
> > > According to the freq adjust every frame starts with a new phase.
> > > Phase 1 ≠ Phase 5
> > >  
> > > Is there any possibility to get the same phase after returning to
> > > the same center freq? Phase 1=Phase 5, Phase 2 = Phase 6,…
> > >  
> > > Thanks in advance.
> > > dominik
> > > 
> > Almost certainly not.  It would take a very special type of
> > frequency synthesizer to achieve that.
> > 
> You mean the sort of frequency synthesizer that might be implemented
> entirely in the digital domain within say a DUC or DDC with the
> ability to have a time coordinated update to the respective phase-
> increment registers? :-)
> ___
> 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] link led colour

2019-03-12 Thread Marcus Müller via USRP-users
Hi Koyel, Wade and Joe,

ah! My bad. I got my X310 out of the cupboard and was so concentrated
on figuring which red LED was meant that I really focused on the back
panel – and forgot there's literally a "LINK" LED on the front of the
USRP. My apologies!

You'll have to do a bit of a deeper dive, but you'll find out that the
LINK indicator basically shines whenever there's rx or tx active, far
as I read db_control.v.

Best regards, and again, my apologies,
Marcus

On Mon, 2019-03-11 at 17:27 -0500, Wade Fife wrote:
> As far as I can tell, the LED color hasn't changed. Page 13 has the
> SFP status LEDs, which show through the panel above the SFPs. These
> are green for link (left, above the SFP) and yellow for activity
> (right, above the SFP).
> 
> Page 14 has the "LINK" LED, which shows through on the opposite end
> of the USRP (next to the RF ports). This one is a RED/GREEN bicolor.
> I think this LED is a combination of the PCIe and Ethernet status.
> Orange is what you get when both RED and GREEN are on at the same
> time. I have an X310 on my desk and this LED varies between red,
> orange, yellow, and green, depending on how the LEDs are flashing.
> 
> I think the behavior Koyel is seeing is expected and just means
> there's data being transferred, assuming Koyel is looking at the LINK
> LED that's next to the RF ports.
> 
> Thanks,
> 
> Wade
> 
> On Thu, Mar 7, 2019 at 7:48 PM Joe Martin via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> > Interestingly, my X310 front panel LED occasionally, very briefly
> > shows red too.  Maybe the schematic isn’t current with what is
> > actually used in the unit these days(?).  
> > 
> > Regards, 
> > 
> > Joe
> > 
> > > On Mar 7, 2019, at 3:36 PM, Marcus Müller via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> > > 
> > > So that's built on an X3x0 platform. As said, no, the link leds
> > really
> > > just display link status, nothing about the data.
> > > Also, when you look at the schematic of the X300, PDF [1] page
> > 13,
> > > you'll find no red LED – only green and yellow, so I must admit
> > I'm a
> > > bit confused about what you witnessed?
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > [1] http://files.ettus.com/schematics/x300/x3xx.pdf
> > > On Thu, 2019-03-07 at 09:56 +, Koyel Das (Vehere) wrote:
> > >> I am using USRP 2955 R
> > >> 
> > >> Koyel Das 
> > >> Senior – Product Engineer
> > >> Vehere | Proactive Communications Intelligence & Cyber Defence
> > >> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> > >> www.vehere.com
> > >> 
> > >> 
> > >> 
> > >> Vehere is the proud recipient of the Fastest Growing Technology
> > >> Company Awards in India & Asia since 2012!
> > >> 
> > >> The content of this e-mail is confidential and intended solely
> > for
> > >> the use of the addressee. The text of this email (including any
> > >> attachments) may contain information, which is proprietary
> > and/or
> > >> confidential or privileged in nature belonging to Vehere
> > Interactive
> > >> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If
> > you
> > >> are not the addressee, or the person responsible for delivering
> > it to
> > >> the addressee, any disclosure, copying, distribution or any
> > action
> > >> taken or omitted to be taken in reliance on it is prohibited and
> > may
> > >> be unlawful. If you have received this e-mail in error, please
> > notify
> > >> the sender and remove this communication entirely from your
> > system.
> > >> The recipient acknowledges that no guarantee or any warranty is
> > given
> > >> as to completeness and accuracy of the content of the email. The
> > >> recipient further acknowledges that the views contained in the
> > email
> > >> message are those of the sender and may not necessarily reflect
> > those
> > >> of Vehere Interactive Pvt Ltd. Before opening and accessing the
> > >> attachment please check and scan for virus. WARNING: Computer
> > viruses
> > >> can be transmitted via email. The recipient should check this
> > email
> > >> and any attachments for the presence of viruses. The company
> > accepts
> > >> no liability for any damage caused by any viru

Re: [USRP-users] Py Threads

2019-03-10 Thread Marcus Müller via USRP-users
Speaking for the GNU Radio side: All GNU Radio Blocks run in their
separate, "real" thread and hence are actually fully concurrent. All
resulting thread-safety concerns do arise.

Best regards,
Marcus Müller

On Sun, 2019-03-10 at 11:56 +, Benny Alexandar via USRP-users
wrote:
> Hi All,
> 
> Its known that using Python threads won't result in teh concurrency
> for process oriented functions. Unless you use process instead of
> threads you won't get concurrency in Python. 
> 
> How it is managed in UHD or Gnu Radio ?
> 
> -ben
> ___
> 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] link led colour

2019-03-07 Thread Marcus Müller via USRP-users
So that's built on an X3x0 platform. As said, no, the link leds really
just display link status, nothing about the data.
Also, when you look at the schematic of the X300, PDF [1] page 13,
you'll find no red LED – only green and yellow, so I must admit I'm a
bit confused about what you witnessed?

Best regards,
Marcus

[1] http://files.ettus.com/schematics/x300/x3xx.pdf
On Thu, 2019-03-07 at 09:56 +, Koyel Das (Vehere) wrote:
> I am using USRP 2955 R
> 
> Koyel Das 
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> www.vehere.com
> 
> 
> 
> Vehere is the proud recipient of the Fastest Growing Technology
> Company Awards in India & Asia since 2012!
> 
> The content of this e-mail is confidential and intended solely for
> the use of the addressee. The text of this email (including any
> attachments) may contain information, which is proprietary and/or
> confidential or privileged in nature belonging to Vehere Interactive
> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you
> are not the addressee, or the person responsible for delivering it to
> the addressee, any disclosure, copying, distribution or any action
> taken or omitted to be taken in reliance on it is prohibited and may
> be unlawful. If you have received this e-mail in error, please notify
> the sender and remove this communication entirely from your system.
> The recipient acknowledges that no guarantee or any warranty is given
> as to completeness and accuracy of the content of the email. The
> recipient further acknowledges that the views contained in the email
> message are those of the sender and may not necessarily reflect those
> of Vehere Interactive Pvt Ltd. Before opening and accessing the
> attachment please check and scan for virus. WARNING: Computer viruses
> can be transmitted via email. The recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
> From: Marcus Müller 
> Sent: Thursday, March 7, 2019 3:21:40 PM
> To: Koyel Das (Vehere); 'USRP-users@lists.ettus.com'
> Subject: Re: [USRP-users] link led colour
>  
> The link LEDs on our USRPs don't indicate validness of data. It's
> highly likely this is normal. What USRP are you using?
> 
> Best regards,
> Marcus
> 
> On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users
> wrote:
> > Hi,
> > 
> > When I am receiving data using ethernet my link LED is orange most
> of
> > the times and blinking to red for momentarily, which is not so
> > noticeable. Am I receiving wrong data? It is not turning green.
> > 
> > Regards,
> > Koyel
> > 
> > Koyel Das 
> > Senior – Product Engineer
> > Vehere | Proactive Communications Intelligence & Cyber Defence
> > M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> > www.vehere.com
> > 
> > 
> > 
> > Vehere is the proud recipient of the Fastest Growing Technology
> > Company Awards in India & Asia since 2012!
> > 
> > The content of this e-mail is confidential and intended solely for
> > the use of the addressee. The text of this email (including any
> > attachments) may contain information, which is proprietary and/or
> > confidential or privileged in nature belonging to Vehere
> Interactive
> > Pvt Ltd and/or its associates/ group companies/ subsidiaries. If
> you
> > are not the addressee, or the person responsible for delivering it
> to
> > the addressee, any disclosure, copying, distribution or any action
> > taken or omitted to be taken in reliance on it is prohibited and
> may
> > be unlawful. If you have received this e-mail in error, please
> notify
> > the sender and remove this communication entirely from your system.
> > The recipient acknowledges that no guarantee or any warranty is
> given
> > as to completeness and accuracy of the content of the email. The
> > recipient further acknowledges that the views contained in the
> email
> > message are those of the sender and may not necessarily reflect
> those
> > of Vehere Interactive Pvt Ltd. Before opening and accessing the
> > attachment please check and scan for virus. WARNING: Computer
> viruses
> > can be transmitted via email. The recipient should check this email
> > and any attachments for the presence of viruses. The company
> accepts
> > no liability for any damage caused by any virus transmitted by this
> > email.
> > ___
> > 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] link led colour

2019-03-07 Thread Marcus Müller via USRP-users
The link LEDs on our USRPs don't indicate validness of data. It's
highly likely this is normal. What USRP are you using?

Best regards,
Marcus

On Wed, 2019-03-06 at 05:05 +, Koyel Das (Vehere) via USRP-users
wrote:
> Hi,
> 
> When I am receiving data using ethernet my link LED is orange most of
> the times and blinking to red for momentarily, which is not so
> noticeable. Am I receiving wrong data? It is not turning green.
> 
> Regards,
> Koyel
> 
> Koyel Das 
> Senior – Product Engineer
> Vehere | Proactive Communications Intelligence & Cyber Defence
> M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: 
> www.vehere.com
> 
> 
> 
> Vehere is the proud recipient of the Fastest Growing Technology
> Company Awards in India & Asia since 2012!
> 
> The content of this e-mail is confidential and intended solely for
> the use of the addressee. The text of this email (including any
> attachments) may contain information, which is proprietary and/or
> confidential or privileged in nature belonging to Vehere Interactive
> Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you
> are not the addressee, or the person responsible for delivering it to
> the addressee, any disclosure, copying, distribution or any action
> taken or omitted to be taken in reliance on it is prohibited and may
> be unlawful. If you have received this e-mail in error, please notify
> the sender and remove this communication entirely from your system.
> The recipient acknowledges that no guarantee or any warranty is given
> as to completeness and accuracy of the content of the email. The
> recipient further acknowledges that the views contained in the email
> message are those of the sender and may not necessarily reflect those
> of Vehere Interactive Pvt Ltd. Before opening and accessing the
> attachment please check and scan for virus. WARNING: Computer viruses
> can be transmitted via email. The recipient should check this email
> and any attachments for the presence of viruses. The company accepts
> no liability for any damage caused by any virus transmitted by this
> email.
> ___
> 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] Frequency resolution of UBX-160 with integer N mode

2019-03-07 Thread Marcus Müller via USRP-users
Good description!
If you look into uhd/host/lib/usrp/dboard/dboard_ubx.cpp (I think), you
should find that the constructor looks through all the rates the
motherboard (X310 in your case) has to offer and picks the highest one
that works with your UBX. That'd be 25 MHz for the 0. revision of the
UBX, and 50 MHz for any after that (which you extremely likely have).

Best regards,
Marcus
On Thu, 2019-03-07 at 10:14 +0100, Andreas Leuenberger via USRP-users
wrote:
> Hi Fabian
> 
> Thank you for your answer.
> I have check the schematics of the X310. The reference clocks to the 
> daughter boards and the 200 MHz sampling clocks are both generated 
> by the "clock jitter clean" chip (LMK0481). I did not have time yet
> to
> check the configuration of this chip, but probably you are right and
> the reference clock to the daughter boards is not 10 MHz (as I
> assumed).
> It could be 200 MHz or directly 50 MHz.
> 
> Best regards,
> andreas
> 
> 
> > Hi,
> >
> > please double check on that, as I am not 100% sure.
> > As far as I was able to figure out, the LO is generated from the 
> > Daughterboard internal 200 MHz reference (which is dirived from the
> 10 
> > MHz), but is divided by 4 for some reason, so you get multiples of
> 50 
> > MHz. This will also induce a random 90° phase shift between the
> signals, 
> > which is a big problem for MIMO stuff.
> > At least the TwinRX boards we used were able to share the LO
> between 
> > multiple channels, which fixed the problem for us.
> >
> > Best regards,
> > Fabian
> >
> > Am 04.03.2019 um 17:23 schrieb Andreas Leuenberger via USRP-users:
> > > Hello all,
> > > 
> > > I am using a USRP X310 with two daughter boards UBX-160 v2. To
> get a 
> > > stable phase difference of the two daughter boards, I use the RX
> LOs in 
> > > integer N mode ("mode_n=integer"). - I have noticed that the
> frequency 
> > > step of the LO is 50 MHz. As the frequency of the reference
> signal is 10 
> > > MHz, I would expect a step of 10 MHz.
> > > 
> > > Is there a way to reduce this frequency step?
> > > 
> > > Thanks for your help,
> > > andreas
> > > 
> > > 
> > > ___
> > > USRP-users mailing list
> > > USRP-users at 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] [Discuss-gnuradio] continous Tx voice transmission

2019-03-06 Thread Marcus Müller via USRP-users
I've had rather longish discussions on how to solve this; essentially:
for something that actually *solves* the issue (instead of postponing
it), as Ian said, you'd need to have clock domain crossing ability.

Assuming you do that in GNU Radio, you'd end up with the problem of
needing to know which end is a little faster than the other; and that's
where things tend to get hairy, because GNU Radio not only runs very
timing-undeterministically, but also consumes variable amounts of
samples per Work call.
You could try to estimate the average rate of samples going through a
flowgraph, but then you're estimating a hardware clock rate with a
software clock; I've got my doubts you'll get low enough estimator
variance in short enough time without a lot of parameter tuning! At
least, if you're in non-realtime userland (I'm told that Jack can do
something like that; I just haven't caught up on that).

Alternatively, you could take resampling action based on buffer
fillage, but just like with a rate estimate, you've got timing
uncertainties plus the fact that GNU Radio processes samples in uneven
blocks, so you get a lot of Jitter, if you will, that ruins short-term
estimates. For larger terms: If you can accept high latency, you can
use larger buffers, and your buffer should "ideally" be half full (or
whatever, constant fillage, just far away from completely empty of
full). A control loop observing the downstream buffer writter's fillage
(by simply looking at `noutput_items`) controlling a resampling ratio
might work well - I just haven't tried. Ideally, you'd do that at the
end with the high rate, to avoid seconds of audio buffers. But, that
increases CPU load and also relative timing quantization (and reduces
the "safety time" a larger buffer gives you).

Alternatively, I could imagine someone hacks together a hardware
frequency divider that one could feed from a software-superimposed Out-
Of-Band tone produced alongside with the radio signal by the B200mini.
Use that to generate the oscillator needed by an audio ADC. Would solve
the underlying 2-clock problem at its source, but isn't really a
flexible or generally applicable solution.

Best regards,
Marcus

On Wed, 2019-03-06 at 10:53 -0500, Marcus D. Leech via USRP-users
wrote:
> On 03/06/2019 10:48 AM, Ian Buckley via USRP-users wrote:
> > The elegant architectual solution (abstracted from GR) is to have a
> > FIFO cross those 2 real clock domains, monitor the fullness and do
> > closed loop sample rate adaption in reaction to the FIFO’s
> > fullness….
> > Now I can also think of reasons why that would be tricky to do well
> > in GR.
> 
> It's a tad surprising that nobody has done an elastic buffer 
> implementation for GR.
> 
> > 
> > > On Mar 6, 2019, at 1:47 AM, franz kurniawan via USRP-users <
> > > usrp-users@lists.ettus.com> wrote:
> > > 
> > > Hi all,
> > > 
> > > i have struggling for couple of weeks in my AM transmitter
> > > project.
> > > i use audio source (alsa) as input and USRP sink (B200mini) as
> > > output..
> > > i know that this making a "2 clock problem" and it will create
> > > either underflow "U" or building latency between microphone
> > > (audio source) and resulted radio transmission after several
> > > hours of continuous running..
> > > i have tried some solutions below but none is working well :
> > > 
> > > * set OK to Block to "No" in audio source to remove clock in
> > > audio source.
> > > Previously i have modified the source of alsa_source.cc since in
> > > the OK to block feature in alsa is ignored in current version of
> > > gnuradio.  But the problem still persists
> > > 
> > > * using tagged stream to enable the burst mode of USRP. But also
> > > the problem still persists
> > > 
> > > * manipulation of resampling rate with below formula:
> > > interpolation : int(samp_rate * 1.000)
> > > if i make the constant < 1.000 so that the consumer rate will be
> > > slightly faster than producer rate, it will lead to repeating "U"
> > > , but there is no latency.
> > > else if the constant > 1.000 , there will be no "U" , but there
> > > will be building latency..
> > > 
> > > 
> > > So, is there any proper solution to this kind of problem?
> > > 
> > > Regards,
> > > Franz
> > > 
> > > 
> > > 
> > > ___
> > > 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] UHD logging: Are errors not handled through std::clog the same way as infos are? Or: How to implement a custom logging facility when restricted to the UHD C API?

2019-03-04 Thread Marcus Müller via USRP-users
Dear Janos
On Mon, 2019-03-04 at 18:22 +0100, Janos Buttgereit via USRP-users
wrote:
> Hi,
> 
> I’m using the UHD C API from within a C++ application. The reason for
> that is that UHD is optionally loaded as dynamic library at runtime
> through dlopen in case the user wants to use an ettus device and has
> the uhd library installed and therefore I’m limited to only use
> functions declared as extern C.

No, that's not true – C++ functions are just as exported. They might
not have the naming you expect, but it really doesn't make a difference
to the underlying system whether your exposed functions are C or C++.
That is, AS LONG as you used the same compiler to compile UHD and your
main C++ program (C++ ABI isn't as canonical as I'd like it to be).
I haven't worked with it in a while, but Boost.DLL [1] might be quite
exactly what you're looking for.

> 
> I need some custom logging facility for my application as it is GUI
> based, e.g. certain errors should end up in alert windows and not in
> console prints. However I haven’t found any possibility to implement
> such logging when restricted to the C API only. So first question:
> Did I overlook something? Any pointer on how to get custom logging
> working without using the C++ API would be greatly appreciated.

The C API was never meant to give you the full C++-specific flexibility
– I doubt this will be reasonably complex when going through the C API.


> 
> In the meantime I tried to go a different way. This document 
> https://files.ettus.com/manual/page_logging.html tells me, that UHD
> uses std::clog for everything using the console logging backend. As
> no other part of my application makes use of std::clog I simply
> redirected std::clog to a custom std::streambuf instance where I
> handle the log strings. This works quite well for the [INFO] log
> messages, however [ERROR] messages seem to bypass std::clog and are
> still printed to the console. Is this intended behaviour or a bug as
> the document tells that all console logging goes through std::clog?

I must admit: a good question.

Best regards,
Marcus


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


Re: [USRP-users] Custom filesystems for N310: adding gnuradio

2019-02-10 Thread Marcus Müller via USRP-users
Hi Ali,

the "pwd" in that path makes me suspicious. In the original
documentation (on github) this read `pwd` and would have been executed
to be replaced with the current working directory; sorry for the copy-
and-paste error on our side; on our documentation page, the `…`
converts to code formatting. So, the full command line would be

TEMPLATECONF=/home/oe-builder/meta-ettus/conf/sulfur source ./oe-
core/oe-init-build-env ./build ./bitbake

Best regards,
Marcus

On Fri, 2019-02-08 at 14:19 -0800, Ali Dormiani via USRP-users wrote:
> Hello everyone,
> 
> I've spent a few hours trying to learn docker and get a N310
> filesystem with gnuradio on it.
> 
> So far no luck.
> 
> I followed the documentation:
> 
> https://files.ettus.com/manual/page_usrp_n3xx.html#n3xx_fsbuild
> 
> And got this output:
> 
> WARNING: unable to chmod /home/oe-builder/build
> Error: TEMPLATECONF value points to nonexistent directory 'pwd/meta-
> ettus/conf/sulfur'
> 
> Additionally, I have no idea how to compile gnuradio in the docker
> container. There are a lot of missing dependencies and there is no
> package manager. 
> 
> Am I supposed to compile gnuradio's dependencies from source?
> 
> Is it even reasonable to try to get gnuradio on a USRP SDIMG
> filesystem?
> I ask this last question because it seems strange the Ettus folks
> don't put gnuradio on the default filesystem. It's opensource, very
> useful, and there is plenty of free space (~7 Gb) in the stock
> partitions. Why not?
> 
> Thank you all for your time,
> 
> Ali
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


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


Re: [USRP-users] Phase Synchronization of two usrp b210's

2019-02-10 Thread Marcus Müller via USRP-users
Hi Aravind,

first of all, have you seen 
http://files.ettus.com/manual/page_sync.html ?

You'll find in the last paragraph that after each tuning, your phase
relationship between different B210s will be random, but constant for
the run (aside from minor PLL drift).

So, you need to tune, and then calibrate; how that can be done depends
on the system you're building.

Best regards,
Marcus

On Fri, 2019-02-08 at 17:03 -0800, Aravind Dhulipalla via USRP-users
wrote:
> Hi, 
> 
> Has anyone achieved phase synchronizing between two usrp b210's using
> external reference and pps? If yes I would appreciate any help that I
> can get.
> 
> Thanks
> Aravind.
> 
> The contents of this transmission are Ethertronics Inc. Confidential
> and may contain proprietary or legally privileged information which
> may not be disclosed, copied or distributed without the express
> written consent of Ethertronics Inc. The information is intended to
> be for the use of the individual or entity named on this
> transmission. If you are not the intended recipient, be aware that
> any disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you have received this transmission in
> error, please notify us by telephone immediately so that we can
> arrange for the retrieval of the original documents at no cost to
> you. Alternatively, notify the sender by replying to this
> transmission and delete the message without disclosing it. Thank you 
> 
> 
> 
> AVX_BSID: 99762491J
> ___
> 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] Unexpected (increasing) latency for set_rx_gain

2019-02-04 Thread Marcus Müller via USRP-users
Hi Brais,

On Mon, 2019-02-04 at 18:34 +0100, Brais Ares via USRP-users wrote:
> Hello,
> 
> I'm trying to implement an AGC software in our RF application. The
> setup is the following:
> B200mini
> master clock rate: 16 MSPS
> fs = 32 KSPS

Are you sure? That's a decimation of 500, 125 of which you're doing
with a CIC. 32 kS/s is really an extremely low sampling rate for SDR
applications, and there's little reason not to do the resampling with
"nicer" software filters on your host PC; even the slowest Linux
computer should have plenty CPU power to do that.

A higher sampling rate would also allow a much more fine-grained
examination of these delays. I'd ask you to examine this option.

Generally, in the interest of reproducability: how are you doing that
gain step detection, en detail?

Best regards,
Marcus

> Receive samples in blocks of 32k (1 second).
> I made a tiny program, where I change rx_gain every 1 seconds (just
> after rx_streamer->recv() returns) adding or substracting 30 dB.
> To find out when a change in rx_gain actually affects the received
> samples I implemented a simple detection algorithm.
> 
> Ignoring the non-deterministic latency, at least I would expect the
> time between changes to be 1 seconds as well (µ = 1 seconds, with
> some non-zero variance), the same periodicity they were invoked
> with. 
> 
> However, this change takes on average 1.016 seconds (see figure).
> This means for each set_rx_gain call the radio is taking longer and
> longer to apply the change (see figure). Example:
> 
> t = 1 s -> Recv previous block and change gain
> t = 2 s -> Recv previous  block and change gain
> t = 1.016 -> Change in gain detected in previous block (OK, latency
> to change gain is around ~0.016 ms)16 µs would indeed be a pretty *gp
> t = 3 s -> Recv previous nd change gain
> t = 2.032 s -> Change in gain detected in previous block  (I would
> expect ~2.016)
> t = 4 s -> Recv previous block and change gain  
> t = 3.048 s -> Change in gain detected in previous block (I would
> expect ~3.016)
> (...)
> t = 60 s -> Recv previous block and change gain  
> t = 59.96 s -> Change in gain detected in previous block (After 60th
> call to rx_gain, latency has increased to almost 1 second!)  
> 
> Is there any rational reason why this is happening?
> (I've tried longer periods, up to 10 seconds, with the same result).
> 
> Regards,
> Brais.
> 
> 
> ___
> 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] AM modulated signal using USRP2

2019-02-01 Thread Marcus Müller via USRP-users
Hi Afaq,

assuming you already know the math behind AM, this is really simple:
What you need to transmit is a modulated carrier. So, you just send the
audio signal with a DC offset to your USRP and let the USRP tune to the
frequency you want to use.

Easiest way would probably just installing GNU Radio and having flow
graph:

source of the data signal
-> add constant (so that all values are positive)
-> multiply const (so that all values are |·| < 1)
-> USRP Sink

Note that in general it's really a bad idea to do amplitude modulation
in the 2.4 GHz, because of fading.

Best regards,
Marcus

On Thu, 2019-01-31 at 21:03 +0100, Afaq Ahmed via USRP-users wrote:
> Hello fellows,
> I want to create an AM Modulator using USRP2. The setup is such that
> I want to use one USRP2 as AM Modulator (Transmitter) and another
> USRP2 to be the AM Demodulator (Receiver). Can you please point in
> the right direction ? May be some suggestions on how I can
> achieve this would be very nice?
> 
> OS: Xubuntu 18.04 LTS
> PC: RAM 4 GB, Core i3
> USRP2 with XCVR2450 daughterboard
> 
> Thanks a lot
> BR
> Afaq
> ___
> 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] Include files missing in and

2019-01-28 Thread Marcus Müller via USRP-users
Hi Rob,

On Fri, 2019-01-25 at 17:42 -0500, Rob Kossler wrote:
> Why do you compare two instances of "device" with one instance of
> "multi_usrp"?  Can't the device object have two IP addresses?

Nope, can't. That's what multi_usrp was designed for. Device is a
single device representation. It *should* be more internal. It's a
artifact from simpler times. Multi_usrp is the abstraction people
should be using.

>   I'm not aware of a performance issue that can only be achieved
> using multi_usrp as opposed to working directly with device, but
> perhaps I'm wrong.

As said, from the top of my head, there's differences in the way the
ADCs on multi-X300 is initialized.

> As an alternative example, consider the
> multi_usrp::get_usrp_rx_info()
> method.  This method requires  (one of the
> non-installed headers I mentioned) to get the typdef eeprom_map_t.

Internally, that might be. Externally, the API is a map.

> This is then used to read the daughterboard serial number and subdev
> id.  It seems to me that I should be able to access this information
> without going through the multi_usrp API. 

So, you're one of my favourite customers, and I'll hardly argue with
you about what you should or should not be doing with Open Source
drivers, but: If you take a step back and consider the *user*, the
*consumer* of UHD, then: you should go through the abstraction of
multi_usrp rather than assuming something about the way the device
knows "who" and "what" it is. Nobody's guaranteeing the next generation
of USRP will have any EEPROM, let alone one that is programmed in a way
compatible to what you see in eeprom_map_t. (This is not hypothetical.
E310 has a different type of EEPROM than all the other USRPs at the
point of introduction. That led to interesting abstraction clutches in
drivers.)
Again, what you're doing is working with internal things of UHD that we
don't consider API and thus have no mercy with – if anyone has a
productive reason to replace eeprom_map_t with a different type inside
UHD, they just might be without pushing more than the patchlevel
versioning. It's not API nor ABI of UHD.

> In fact, if I have a non-standard FPGA image, I am not even ABLE to
> use the multi_usrp API because legacy_compat will not "make" without
> an expected set of rfnoc blocks.

So, that's the pickle we're in :) RFNoC made it more likely than ever
that users become modifiers of UHD. And you're a prime example; so by
all means, do what you must to our code base (my recommendation is
still very strongly to modify in-tree, rather than out-of-tree); the
thing I'm trying to point out is that you've crossed the threshold from
API consumer to in-tree developer. The things you're using should never
be seen by a "normal" user of UHD.

So, that's where my sympathy for this case comes from, and why I'm
writing these epics in the shape of emails: while you're trying to do
something that no software/hardware company could reasonably support
(work with the driver internals externally), we still put you in a
position where you have to do it (work with driver internals). So,
let's keep this thread going, even though I'll still stress: if
anything, do this internally, not externally to UHD.

> But, without  include file, I don't have the needed
> eeprom_map_t typdef.

Yep, you're modifying multi_usrp, an internal component of UHD, so you
need internal things. Anyway, this again points out that you should be
modifying UHD, not trying to reimplement things out-of-tree.

Your presumption that it's easier to work externally and import these
private headers than to maintain a git branch with your modification is
a bit of a dangerous path, from my software architectural perspective.
Again, not stopping you, but I don't think it's the safest or quickest
way forward.

Best regards,
Marcus


___
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] USB driver on Ettus B200 mini

2019-01-27 Thread Marcus Müller via USRP-users
Dear Linda, 

this is unrelated to GNU Radio; so, the usrp-users mailing list would
be better suited to such discussion.

Knowing UHD and the USB driver: Bad news, with the way the device
works, you won't be able to improve the driver much. I doubt one can
significantly increase throughput short of re-designing the B200. The
interrupt load is directly related to number of USB packets, and those
are what transports your samples, and have a maximum size. A non-bulk
transfer mode might help, but unless someone demonstrates that's true,
I'd be doubtful. After all, there's been a couple of engineer work
years of knowledge in UHD's USB stack.

Chances are that what you do with the data is simply too much work for
your computer, and you need be cleverer about the application side of
things rather than the driver side. As said, unless things are really
GNU Radio-specific, the usrp-users@lists.ettus.com mailing list would
be the platform to discuss USRP applications!

Best regards,
Marcus

On Thu, 2019-01-24 at 18:11 -0500, Linda Ziemba wrote:
> Hi,
> 
> We are looking for expertise to create a custom USB driver for
> B200mini on Ubuntu 14/16/18 to be more suitable for streaming
> information off the card. The default driver is too slow for our
> needs. Anyone interested & available?
> 
> Thanks,
> 
> Linda Ziemba
> Founding CEO
> 
> 732.991.3605   |   @lziemba   |   
> https://www.linkedin.com/in/lindaziemba
> 
> 
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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


Re: [USRP-users] Include files missing in and

2019-01-25 Thread Marcus Müller via USRP-users
Hi Rob,
On Fri, 2019-01-25 at 15:02 -0500, Rob Kossler wrote:
> Thanks Marcus,
> Regarding the installation of the header files, 
> my hypothesis is that if they are located in the  tree, they
> are intended to be installed.

One could argue that, but historically this has not been the case. R
might be cleaning this up corrently.

>   If they are located in the  tree, they are not intended
> to be installed.  Otherwise, I don't understand the distinction of
> the two trees and why you would choose to locate a given header file
> in one tree rather than the other.

Yeah, but I'll be honest, these are still headers that describe
details. And you really shouldn't be using headers of C++ classes with
non-visible symbols; as said: linker errors waiting to happen

> and from a conceptual perspective, it seems to me that multi_usrp is
> a "convenience" class intended to make it easy to access device
> capability through access methods rather than directly manipulating
> the property tree.

Well, that's what drivers are, ain't they? Convenience wrappers to
abstract hardware interaction.

>   If that is true, then it seems to follow that there would be
> nothing in the multi_usrp API that I couldn't accomplish "manually"
> outside of that API.  

But it's not really true. For example, with two uhd::usrp::device
instances instead of a mulit_usrp with two IP addresses, you can't get
the same level of ADC phase sync on X3xx, IIRC.
 
> Given that the stock multi_usrp implementation "requires" the non-
> installed header files, this would tell me that there is certain
> functionality that can only be accomplished through the multi_usrp
> API and not otherwise.

indeed, that sounds like what UHD has become :)

> 
> Regarding my goal with multi_usrp, I want a "multi_usrp-like" object
> that can handle arbitrary rfnoc graphs.  

Ah, that sounds interesting! 

> A few remarks:
> the current multi_usrp implementation handles rfnoc FPGAs using
> "legacy_compat" to handle the rfnoc graph and rfnoc block details
> legacy_compat does not allow the user to specify a custom rfnoc graph
> (such as one containing an FFT block), but rather constructs a graph
> based on the notion of Tx looking like (host->fifo->duc->radio) and
> Rx looking like (radio->ddc->host).  You can "skip" various elements
> with the appropriate "arg" setting but otherwise your graph looks
> like multiple channels of this.

Yeah, that's how I'd describe a "classical" NoC flow graph. However,
there's technically actually nothing forcing NoC blocks to always send
their outputs to the same "downstream block"; that's a choice the
noc_shell does by default. But I disgress...

> legacy_compat also has the limitation that a "radio channel" is one-
> to-one with a "streaming channel".  Thus, you could not have a graph
> with a single streaming channel and two radio channels such as the
> following: host->SplitStream=>Dual DDC=>Dual Radio.
> So, in my current implementation, I have replaced "legacy_compat"
> with my own "rfnoc_chan_map" and so I copied and slightly modified
> "multi_usrp_impl" to interface with my "rfnoc_chan_map".  My
> implementation
> requires the user to specify a graph using a text file containing
> every "link" (starting node & ending node).  The graph filename is
> passed via make "args".

That's actually pretty nice, I like that approach. Martin?

> keeps track of all radio sink and source blocks (as well as duc/ddc
> blocks if directly attached to the radios) as Tx and Rx radio
> channels (e.g., for accessing radio settings)
> keeps track of all "host_tx" and "host_rx" "blocks" as Tx and Rx
> streaming channels (e.g., for getting tx/rx_streamers).
> Since my custom "mult_usrp" implementation is derived from
> "multi_usrp.hpp". I should be able to use it in most/all of my
> existing applications.
> As to why I don't just modify the stock multi_usrp, as you see, that
> is what I have done.  But, I have done so out-of-tree rather than in
> place. This just seems easier to me given the frequency of uhd
> updates that I pull and would need to modify if working in-tree.

Well, the problem with the out-of-tree in current UHD's includes (far
as I can tell), that you're also dependent on ever-changing includes.

Cheers,
Marcus

> Rob
> 
> On Fri, Jan 25, 2019 at 1:49 PM Marcus Müller <
> marcus.muel...@ettus.com> wrote:
> > Hi Rob,
> > 
> > you've got a point – in soft_register.hpp, there's classes that
> > contain
> > exported symbols, it should probably be installed.
> > 
> > component_file.hpp, dirty_tracked.hpp and eeprom.h really only
> > contain
> > implementation details;  I'm not the UHD maintainer, but I'd say
> > these
> > files shouldn't get installed, as the types defined therein are
> > only
> > used in non-public-API functionality, and thus are subject to
> > change
> > without notice. Don't depend on these types existing!  
> > 
> > In fact, they can change without the UHD ABI compat version being
> > bumped, as far as I'd set a 

Re: [USRP-users] Include files missing in and

2019-01-25 Thread Marcus Müller via USRP-users
Hi Rob,

you've got a point – in soft_register.hpp, there's classes that contain
exported symbols, it should probably be installed.

component_file.hpp, dirty_tracked.hpp and eeprom.h really only contain
implementation details;  I'm not the UHD maintainer, but I'd say these
files shouldn't get installed, as the types defined therein are only
used in non-public-API functionality, and thus are subject to change
without notice. Don't depend on these types existing!  

In fact, they can change without the UHD ABI compat version being
bumped, as far as I'd set a versioning policy. These are internals!

The problem you're setting yourself up, IMHO, is that even if you have
all the headers, the symbols (function bytecode) are still in libuhd.so
and not necessarily exported (that's what UHD_API does), so you might
end up coding something that compiles very fine and then fails to link
unless you start modifying default visibilities, at some surprising
point during development.

Hey, maybe there's an easy way out. Can you tell us what you're doing
in your custom multi_usrp, and why you're not simply modifying the
stock multi_usrp?

Best regards,
Marcus


On Thu, 2019-01-24 at 18:09 -0500, Rob Kossler via USRP-users wrote:
> While attempting to create a custom "multi_usrp" implementation
> (based on an arbitrary rfnoc graph), I found that the following files
> are not "installed"
> 
> 
> 
> 
> 
> I noticed this because I tried to compile a copy of "multi_usrp.cpp"
> out-of-tree. The compile failed because of missing include files (all
> of the above except component_file.hpp).  I then looked in the
> CMakeLists.txt files for these folders and sure enough, these files
> are not included.  I am wondering if this is intentional or a mistake
> - it seems the latter.
> 
> By the way, I also had an issue with needing
> , but this one is in the lib tree so I
> understand why it is not installed.  In any case, I just copied all
> of the needed include files out-of-tree and was able to compile.
> 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] Time synchronization between two USRPB210's

2019-01-14 Thread Marcus Müller via USRP-users
Yes!
Simply set the clock source (multi_usrp.set_clock_source) to "external"
on both devices, within one second set the same time on both, and then
specify the transmit start to be the same on both; you do that by
setting the time in the metadata you pass to the tx_streamer.send()
method.


Best regards,
Marcus

On Mon, 2019-01-14 at 11:46 -0800, Aravind Dhulipalla via USRP-users
wrote:
> Hello,
> 
> Is it possible to start transmitting from two different usrpb210's at
> the same time using? I am using an external 10MHz reference, 1PPS
> signal and c++ API.
> 
> Thanks.
> 
> The contents of this transmission are Ethertronics Inc. Confidential
> and may contain proprietary or legally privileged information which
> may not be disclosed, copied or distributed without the express
> written consent of Ethertronics Inc. The information is intended to
> be for the use of the individual or entity named on this
> transmission. If you are not the intended recipient, be aware that
> any disclosure, copying, distribution or use of the contents of this
> information is prohibited. If you have received this transmission in
> error, please notify us by telephone immediately so that we can
> arrange for the retrieval of the original documents at no cost to
> you. Alternatively, notify the sender by replying to this
> transmission and delete the message without disclosing it. Thank you 
> 
> 
> 
> AVX_BSID: 99762491J
> ___
> 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] UHD make stopped on 100% with error 1

2019-01-09 Thread Marcus Müller via USRP-users
That being said, I don't think UHD acutely requires anything not in
Ubuntu16.04 (though I agree, that feels ancient).
I'm running a test build, i.e. 

docker run -it ubuntu:16.04
$ apt-get update
$ # and of course, Canonical couldn't get their mess together, so they
$ # forgot to supply proper verfication keys for their updates repo...
$ # hence, the --allow-unauthenticated. Note: not a fan of Ubuntu.
$ # the package list is from 
https://kb.ettus.com/Building_and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_Radio)_on_Linux
$ apt-get --allow-unauthenticated -y install git swig cmake doxygen
build-essential libboost-all-dev libtool libusb-1.0-0 libusb-1.0-0-dev
libudev-dev libncurses5-dev libfftw3-bin libfftw3-dev libfftw3-doc
libcppunit-1.13-0v5 libcppunit-dev libcppunit-doc ncurses-bin
cpufrequtils python-numpy python-numpy-doc python-numpy-dbg 
python-scipy python-docutils qt4-bin-dbg qt4-default qt4-doc libqt4-dev 
libqt4-dev-bin python-qt4 python-qt4-dbg python-qt4-dev python-qt4-doc
python-qt4-doc libqwt6abi1 libfftw3-bin libfftw3-dev libfftw3-doc
ncurses-bin libncurses5 libncurses5-dev libncurses5-dbg
libfontconfig1-dev libxrender-dev libpulse-dev swig g++ automake
autoconf libtool python-dev libfftw3-dev libcppunit-dev
libboost-all-dev libusb-dev libusb-1.0-0-dev fort77 libsdl1.2-dev
python-wxgtk3.0 git-core libqt4-dev python-numpy ccache python-opengl
libgsl-dev python-cheetah python-mako python-lxml doxygen qt4-default
qt4-dev-tools libusb-1.0-0-dev libqwt5-qt4-dev libqwtplot3d-qt4-dev
pyqt4-dev-tools python-qwt5-qt4 cmake git-core wget libxi-dev gtk2-
engines-pixbuf r-base-dev python-tk liborc-0.4-0 liborc-0.4-dev
libasound2-dev python-gtk2 libzmq-dev libzmq1 python-requests
python-sphinx libcomedi-dev python-zmq python-setuptools
$ git clone https://github.com/EttusResearch/uhd
$ mkdir uhd/host/build
$ cd uhd/host/build
$ cmake ..
$ make -j8

and it runs right through. Hm.
But: my CMake says "cmake -version" is 3.5.1, not 3.4.1 like your error
message. A quick lookup on packages.ubuntu.com says Ubuntu 16.04 ships
my version, not your version of cmake.
The likeliest explanation I can come up with for that is that you
somehow manually installed an older version of CMake, and now you're
mixing current and old CMake files.

Best regards,
Marcus

On Tue, 2019-01-08 at 21:31 -0500, Marcus D. Leech via USRP-users
wrote:
> On 01/08/2019 01:21 PM, Roman via USRP-users wrote:
> > Hi,
> > 
> > I am trying to build UHD from current master branch on Ubuntu
> > 16.04.
> > Make is almost complete but breaks with error 1.
> > I would appreciate support for this issue from community.
> > Detailed log is below.
> > 
> > Best regards,
> > Roman
> > make[2]: Leaving directory '/home/gnuradio/uhd-master/host/build'
> > make -f python/CMakeFiles/pyuhd_library.dir/build.make 
> > python/CMakeFiles/pyuhd_library.dir/build
> > make[2]: Entering directory '/home/gnuradio/uhd-master/host/build'
> > [100%] Generating build/timestamp
> > cd /home/gnuradio/uhd-master/host/build/python &&
> > /usr/local/bin/cmake 
> > -E copy /home/gnuradio/uhd-master/host/python/__init__.py 
> > /home/gnuradio/uhd-master/host/ python/types.py 
> > /home/gnuradio/uhd-master/host/python/usrp.py 
> > /home/gnuradio/uhd-master/host/python/filters.py 
> > /home/gnuradio/uhd-master/host/build/python/uhd
> > CMake Error: cmake version 3.4.1
> > Usage: /usr/local/bin/cmake -E [command] [arguments ...]
> > Available commands:
> >   chdir dir cmd [args]...   - run command in a given directory
> >   compare_files file1 file2 - check if file1 is same as file2
> >   copy file destination - copy file to destination (either file
> > or 
> > directory )
> >   copy_directory source destination   - copy directory 'source' 
> > content to direc   tory 'destination'
> >   copy_if_different in-file out-file  - copy file if input has
> > changed
> >   echo [string]...  - displays arguments as text
> >   echo_append [string]...   - displays arguments as text but no new
> > line
> >   env [--unset=NAME]... [NAME=VALUE]... COMMAND [ARG]... - run
> > command 
> > in a modified environment
> >   environment   - display the current environment
> >   make_directory dir- create a directory
> >   md5sum file1 [...]- compute md5sum of files
> >   remove [-f] file1 file2 ... - remove the file(s), use -f to force
> > it
> >   remove_directory dir  - remove a directory and its contents
> >   rename oldname newname- rename a file or directory (on one
> > volume)
> >   tar [cxt][vf][zjJ] file.tar [file/dir1 file/dir2 ...]  - create
> > or 
> > extract a tar or zip archive
> >   sleep ... - sleep for given number of seconds
> >   time command [args] ...   - run command and return elapsed time
> >   touch file- touch a file.
> >   touch_nocreate file   - touch a file but do not create it.
> > Available on UNIX only:
> >   create_symlink old new- create a symbolic link 

Re: [USRP-users] B205 Mini gain Tables

2019-01-05 Thread Marcus Müller via USRP-users
Hi Arun,

no, as the B205 isn't a calibrated measurement device, we can not offer
any more accurate data.

Especially since wideband matching is a hard problem, I'd, even if I
had that data, would strongly recommend you measure for exactly the
frequencies and gains you're using.

Best regards, and my apologies,
Marcus Müller

On Sat, 2019-01-05 at 10:26 +, Arun kumar Verma via USRP-users
wrote:
> Dear Users
> 
> I have seen datasheet for B205 Mini and gain over frequency and gain
> index data is available there. As we are developing our software
> where we need to have exact gain value for that particular frequency
> and gain index. Is this data available in csv format for some tabular
> format so that we can just make a look-table and correct the gain. 
> 
> Regards,
> 
> Arun Verma
> 
> ___
> 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] UHD still errors after build installation

2018-12-16 Thread Marcus Müller via USRP-users
Hi Bernd,

I'm really not versed in the ways of Windows, but might it simply be
the case that the user you're currently running as simply has no
permissions to create files in C:\Program Files\?

Best regards,
Marcus

On Sun, 2018-12-16 at 16:12 +, Bernd Witzel via USRP-users wrote:
> To Sam Reiter  (I did not get the answer via email, i just saw it in
> the net.)
> 
> 
> I did not install now the Doxygen, but I get following errors now 
> 
> in cmake I got this,
> 
> when I compile it it is without error, when I install it with Build
> install I got one error, see file I have attached to the 
> email 
> 
> Configuring the python interpreter...
> Python interpreter: C:/Python27/python.exe
> Override with: -DPYTHON_EXECUTABLE=
> Python runtime interpreter: C:/Python27/python.exe
> Override with: -DRUNTIME_PYTHON_EXECUTABLE=
> CMake Warning at cmake/Modules/UHDVersion.cmake:65 (message):
> Could not detect git executable! Could not determine exact version of
> UHD!
> Call Stack (most recent call first):
> cmake/Modules/UHDPackage.cmake:9 (include)
> CMakeLists.txt:110 (include)
> 
> Using UHD Images Directory: C:\Program Files\UHD\share\uhd\images
> 
> Configuring Boost C++ Libraries...
> Looking for optional Boost components...
> Boost version: 1.68.0
> Found the following Boost libraries:
> Looking for required Boost components...
> Boost version: 1.68.0
> Boost include directories: C:/local/boost_1_68_0
> Boost library directories: C:/local/boost_1_68_0/lib64-msvc-14.1
> Boost libraries:
> 
> 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 - "import requests"
> failed
> 
> Python checking for numpy 1.7 or greater
> Python checking for numpy 1.7 or greater - found
> 
> Configuring LibUHD support...
> Dependency Boost_FOUND = 1
> 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 BOOST_PYTHON_FOUND =
> Dependency HAVE_PYTHON_MODULE_NUMPY = TRUE
> Dependency PythonLibs_FOUND = TRUE
> 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 PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
> Could NOT find LIBUSB (missing: LIBUSB_LIBRARIES LIBUSB_INCLUDE_DIRS)
> Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
> Could NOT find LIBGPS (missing: LIBGPS_LIBRARY LIBGPS_INCLUDE_DIR)
> Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
> Could NOT find LIBERIO (missing: LIBERIO_LIBRARY LIBERIO_INCLUDE_DIR)
> Could NOT find dpdk (missing: DPDK_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 = FALSE
> Disabling USB support.
> Override with -DENABLE_USB=ON/OFF
> 
> Configuring GPSD support...
> Dependency ENABLE_LIBUHD = ON
> Dependency ENABLE_GPSD =
> Dependency LIBGPS_FOUND = FALSE
> Disabling GPSD support.
> Override with -DENABLE_GPSD=ON/OFF
> 
> Configuring B100 support...
> Dependency ENABLE_LIBUHD = ON
> Dependency ENABLE_USB = OFF
> Disabling B100 support.
> Override with -DENABLE_B100=ON/OFF
> 
> Configuring B200 support...
> Dependency ENABLE_LIBUHD = ON
> Dependency ENABLE_USB = OFF
> Disabling B200 support.
> Override with -DENABLE_B200=ON/OFF
> 
> Configuring E300 support...
> Dependency ENABLE_LIBUHD = ON
> Disabling E300 support.
> Override with -DENABLE_E300=ON/OFF
> 
> Configuring USRP1 support...
> Dependency ENABLE_LIBUHD = ON
> Dependency ENABLE_USB = OFF
> Disabling USRP1 support.
> Override with -DENABLE_USRP1=ON/OFF
> 
> Configuring USRP2 support...
> Dependency ENABLE_LIBUHD = ON
> Enabling USRP2 support.
> Override with -DENABLE_USRP2=ON/OFF
> 
> Configuring X300 support...
> Dependency ENABLE_LIBUHD = ON
> Enabling X300 support.
> Override with -DENABLE_X300=ON/OFF
> 
> Configuring N230 support...
> Dependency ENABLE_LIBUHD = ON
> Enabling N230 support.
> Override with -DENABLE_N230=ON/OFF
> 
> Configuring 

Re: [USRP-users] GPS data acquisition with the X310

2018-12-14 Thread Marcus Müller via USRP-users
Hi Luz,

nice seeing you again!
So, as discussed before, I've made a custom VM image just for you
(reminder: it's at [0]) including GNSS-SDR and all the drivers you'd
need.

I'm a bit surprised you haven't tried to simply use it, following GNSS-
SDR's tutorial (the first page I think I've saved to the desktop of
that VM image), to receive GPS! You don't need a GPSDO clock to receive
GPS.

I'm confident the available documentation that I've linked to and the
explanations, especially given your specific deviations from standard
equipment, given during our extensive email conversations will allow
you to work your way through this.

Best regards,
Marcus Müller 

[0] http://marcus.hostalia.de/LinuxForGNSS-SDR.ova
[1] https://gnss-sdr.org/conf/

On Thu, 2018-12-13 at 21:34 +, Florez Manduca, Luz E CIV USARMY
(USA) via USRP-users wrote:
> Can any of you point me in the right direction in how to collect good
> GPS data with the X310 whether using the X310 internal 10 MHz
> reference, or external 10 MHz reference or GPSDO clock, depending on
> which one will work? How to use the PPS port with any of these
> choices and so on.
> 
> 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] MSVC + CMake

2018-12-08 Thread Marcus Müller via USRP-users
Hi Martin,

I'll simply answer although I'm definitely not a Windows developer, so
from my very small and selective set of windows dev experiences:

Oh, that sounds like the problem that you can't link release
executables to debug libraries, or vice versa. I was very surprised by
that, and it still bewilders me that it's a problem and MSVC doesn't
scream by itself. 

Hope that somehow helps; if someone more versed in MSVC could jump in,
I'd greatly appreciate that!

Best regards,
Marcus

On Fri, 2018-12-07 at 14:43 -0500, Martin K wrote:
> Marcus,
> Thank you. I ran the 'INSTALL' target in Visual Studio and it
> installed FindUHD.cmake successfully. Previously I had generated an
> installer with the NSIS tool and I don't think it installed
> FindUHD.cmake.
> 
> CMake now finds UHD. 
> 
> Is it normal that I cannot Debug a UHD client program in Visual
> Studio? 
> The init_usrp sample application works in Release configuration but
> crashes in Debug.
> 
> Exception thrown at 0x7FFAA1C02075 (uhd.dll) in init_usrp.exe:
> 0xC005: Access violation reading location 0x00462090
> 
> Thanks for your help,
> Martin Klingensmith
> 
> 
> 
> 
> On Fri, Dec 7, 2018 at 12:36 PM Marcus Müller <
> marcus.muel...@ettus.com> wrote:
> > Dear Mr. Klingensmith,
> > 
> > puh, it's been a while since I worked under Windows with CMake, but
> > do
> > try 
> > cmake -DCMAKE_MODULE_PATH=/path/to/where/FindUHD.cmake ..
> > 
> > or using ccmake to add that path to the CMAKE_MODULE_PATH list.
> > 
> > 
> > Best regards,
> > Marcus
> > 
> > On Thu, 2018-12-06 at 16:29 -0500, Martin K via USRP-users wrote:
> > > I just built UHD for my version of Visual Studio (15.5 == 2017)
> > > the examples, such as uhd_usrp_probe, execute normally.
> > > 
> > > I am trying to make a new project and build the init_usrp
> > example.
> > > The CMake GUI for Windows cannot find UHD:
> > > 
> > > CMake Error at CMakeLists.txt:33 (find_package):
> > >   By not providing "FindUHD.cmake" in CMAKE_MODULE_PATH this
> > project
> > > has
> > >   asked CMake to find a package configuration file provided by
> > "UHD",
> > > but
> > >   CMake did not find one.
> > > 
> > >   Could not find a package configuration file provided by "UHD"
> > > (requested
> > >   version 3.8.0) with any of the following names:
> > > 
> > > UHDConfig.cmake
> > > uhd-config.cmake
> > > 
> > >   Add the installation prefix of "UHD" to CMAKE_PREFIX_PATH or
> > set
> > > "UHD_DIR"
> > >   to a directory containing one of the above files.  If "UHD"
> > > provides a
> > >   separate development package or SDK, be sure it has been
> > installed.
> > > 
> > > 
> > > I tried setting UHD_DIR, UHD_INCLUDE_DIRS, UHD_LIBRARIES in the
> > CMake
> > > cache without any improvements.
> > > 
> > > What is the best way to get CMake to find UHD on Windows?  
> > > 
> > > Thank you,
> > > -- 
> > > Martin Klingensmith
> > > 
> > > ___
> > > 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] MSVC + CMake

2018-12-07 Thread Marcus Müller via USRP-users
Dear Mr. Klingensmith,

puh, it's been a while since I worked under Windows with CMake, but do
try 
cmake -DCMAKE_MODULE_PATH=/path/to/where/FindUHD.cmake ..

or using ccmake to add that path to the CMAKE_MODULE_PATH list.


Best regards,
Marcus

On Thu, 2018-12-06 at 16:29 -0500, Martin K via USRP-users wrote:
> I just built UHD for my version of Visual Studio (15.5 == 2017)
> the examples, such as uhd_usrp_probe, execute normally.
> 
> I am trying to make a new project and build the init_usrp example.
> The CMake GUI for Windows cannot find UHD:
> 
> CMake Error at CMakeLists.txt:33 (find_package):
>   By not providing "FindUHD.cmake" in CMAKE_MODULE_PATH this project
> has
>   asked CMake to find a package configuration file provided by "UHD",
> but
>   CMake did not find one.
> 
>   Could not find a package configuration file provided by "UHD"
> (requested
>   version 3.8.0) with any of the following names:
> 
> UHDConfig.cmake
> uhd-config.cmake
> 
>   Add the installation prefix of "UHD" to CMAKE_PREFIX_PATH or set
> "UHD_DIR"
>   to a directory containing one of the above files.  If "UHD"
> provides a
>   separate development package or SDK, be sure it has been installed.
> 
> 
> I tried setting UHD_DIR, UHD_INCLUDE_DIRS, UHD_LIBRARIES in the CMake
> cache without any improvements.
> 
> What is the best way to get CMake to find UHD on Windows?  
> 
> Thank you,
> -- 
> Martin Klingensmith
> 
> ___
> 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

2018-12-05 Thread Marcus Müller via USRP-users
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 list
> > > > > USRP-users@lists.ettus.com
> > > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > > > 
> > > > -- 
> > > > Follow us on Google+, LinkedIn, or Twitter!
> > > > 
> > > > 
> > > > ___
> > > > USRP-users mailing list
> > > > USRP-users@lists.ettus.com
> > > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > > 
> > > -- 
> > > Follow us on Google+, LinkedIn, or Twitter!
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com


___
USRP-users 

Re: [USRP-users] Segmentation fault commands to USRP with gnuradio

2018-12-05 Thread Marcus Müller via USRP-users
Hi Samuel,

cool! That's really helpful :)

I'm now cross-posting this to discuss-gr, because it's a GNU Radio-land 
issue. The maintainers of gr-uhd are active over there, too, so this
seems the smarter place to continue discussion. 


so, in medias res:

On Wed, 2018-12-05 at 12:43 +0100, samuel verdon wrote:
> #3  0x7f7f15906700 in pmt::dict_has_key (dict=..., key=...) at
> /usr/local/src/gnuradio/gnuradio-runtime/lib/pmt/pmt.cc:937

möp möööp. Our favorite (only) variadic type library leads to
segfaults.

I'll look into that and be back in a while.

Best regards,
Marcus


___
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

2018-12-05 Thread Marcus Müller via USRP-users
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_clock_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_src=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 list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> > 
> > -- 
> > Follow us on Google+, LinkedIn, or Twitter!
> > 
> > 
> > ___
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> 
> -- 
> Follow us on Google+, LinkedIn, or Twitter!
> ___
> 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] 回复: Compile error

2018-12-05 Thread Marcus Müller via USRP-users
Unless you're planning to compile UHD for Android, you should not be
using the compiler that you only installed (hopefully in a $prefix) for
android development. 
So, yes, please revert, and make sure you're not accidentally mixing
includes and headers from the standard libraries of GCC 4.8 and your
"real" GCC.


Best regards,
Marcus
On Wed, 2018-12-05 at 08:59 +0800, Philip_liu wrote:
> Hi,
> 
> I changed for compile the boost 1.53 for Android-ndk,which was said I
> have to change the default vertion of gcc
> and to 4.8,more precisely, it should be switch.
> 
> I did it by delete the old soft link file and build a new one.
> 
> Does this affect my compile error?I can switch back anytime.
> 
> Best Regard,
> Philip Liu
> 
> > --
> > 发件人:Marcus Müller 
> > 发送时间:2018年12月4日(星期二) 18:10
> > 收件人:Philip_liu ; usrp-users <
> > usrp-users@lists.ettus.com>
> > 主 题:Re: [USRP-users] Compile error
> > 
> > Why did you change the GCC to the ancient 4.8? How did you do that?
> > 
> > Best regards,
> > Marcus
> > 
> > On Tue, 2018-12-04 at 14:15 +0800, Philip_liu via USRP-users wrote:
> > > Hi all,
> > > 
> > > I download and update all the dependency packages bas
> > e on
> > > ubuntu 18.04LTS,but the UHD cannot compile successfully.I changed
> >  the
> > > gcc and g++ default vertion from 7 to
> > > 4.8,is this the reason that affects the result?Do I have to reins
> > tall
> > > ubuntu to solve it?
> > > 
> > > Error text:
> > > Scanning dependencies of target uhd_rpclib
> > > [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/dispatcher.cc.o
> > > [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/server.cc.o
> > > [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/client.cc.o
> > > [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/this_handler.cc.o
> > > [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/this_session.cc.o
> > > [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/this_server.cc.o
> > > [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/rpc_error.cc.o
> > > [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/detail/server_session.cc.o
> > > [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/detail/response.cc.o
> > > [  2%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.
> > dir/
> > > lib/rpc/detail/client_error.cc.o
> > > [  2%] Built target uhd_rpclib
> > > [  2%] Generating /home/corad/uhd/host/build/lib/transport/vrt_if
> > _pac
> > > ket.cpp
> > > [  2%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4
> > 350_
> > > regs.hpp
> > > [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4
> > 351_
> > > regs.hpp
> > > [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2
> > 870_
> > > regs.hpp
> > > [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2
> > 871_
> > > regs.hpp
> > > [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4
> > 360_
> > > regs.hpp
> > > [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad95
> > 10_r
> > > egs.hpp
> > > [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad97
> > 77_r
> > > egs.hpp
> > > [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad56
> > 23_r
> > > egs.hpp
> > > [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad79
> > 22_r
> > > egs.hpp
> > > [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2
> > 829_
> > > regs.hpp
> > > [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2
> > 118_
> > > regs.hpp
> > > [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2
> > 112_
> > > regs.hpp
> > > [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad98
> > 62_r
> > > egs.hpp
> > > [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad95
> > 22_r
> > > egs.hpp
> > > [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ads6
> > 2p44
> > > _regs.hpp
> > > [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ads6
> > 2p48
> > > _regs.hpp
> > > [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/tune
> > r_49
> > > 37di5_regs.hpp
> > > [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/tda1
> > 8272
> > > hnm_regs.hpp
> > > [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmk0
> > 4816
> > > _regs.hpp
> > > [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf5
> > 355_
> > > regs.hpp
> > > [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf5
> > 356_
> > > regs.hpp
> > > [  7%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmx2
> > 592_
> > > regs.hpp
> > > [  7%] Generating 

Re: [USRP-users] Segmentation fault commands to USRP with gnuradio

2018-12-05 Thread Marcus Müller via USRP-users
Hi Samuel,

luckily, these days, segfaults are rather rare in stock GNU Radio, and
UHD.

Can you share your exact flowgraph, or a GDB-generated backtrace, with
us?

Best regards,
Marcus
On Wed, 2018-12-05 at 10:31 +0100, samuel verdon via USRP-users wrote:
> Hello,
>  
> I’m trying to command my usrp B200mini via its command port. I used
> the documentation from here:
> https://www.gnuradio.org/doc/doxygen/page_uhd.html
>  
> here is my command:
>   pmt::pmt_t command = pmt::make_dict();
>   command = pmt::dict_add(command, pmt::mp("gain"),
> pmt::mp(gain));   // Specify gain
>   command = pmt::dict_add(command, pmt::mp("antenna"),
> pmt::mp("TX/RX")); // Switch antenna
>   command = pmt::dict_add(command, pmt::mp("chan"),
> pmt::mp(0));  // Specify channel
>   message_port_pub(pmt::mp("cmd") , command);
>  
> I connect my block to a debug message block, and I received this
>  
> MESSAGE DEBUG PRINT***
> ((chan. 0) (antenna, TX/RX) (gain, 63))
>  
> But when I connect to the “UHD: USRP sink” I get a segmentation
> fault… ☹
> I have tried different command always the same problem.
> Can someone show me an example working with tis command?
> I am quite deseparate..
>  
> Ubuntu 16.04
> Gnuradio 3.7.12
> UHD driver UHD_3.11
>  
> Thank you for your help
>  
> ___
> 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] Compile error

2018-12-04 Thread Marcus Müller via USRP-users
Why did you change the GCC to the ancient 4.8? How did you do that?

Best regards,
Marcus

On Tue, 2018-12-04 at 14:15 +0800, Philip_liu via USRP-users wrote:
> Hi all,
> 
> I download and update all the dependency packages base on
> ubuntu 18.04LTS,but the UHD cannot compile successfully.I changed the
> gcc and g++ default vertion from 7 to
> 4.8,is this the reason that affects the result?Do I have to reinstall
> ubuntu to solve it?
> 
> Error text:
> Scanning dependencies of target uhd_rpclib
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/dispatcher.cc.o
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/server.cc.o
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/client.cc.o
> [  0%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/this_handler.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/this_session.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/this_server.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/rpc_error.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/detail/server_session.cc.o
> [  1%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/detail/response.cc.o
> [  2%] Building CXX object lib/deps/rpclib/CMakeFiles/uhd_rpclib.dir/
> lib/rpc/detail/client_error.cc.o
> [  2%] Built target uhd_rpclib
> [  2%] Generating /home/corad/uhd/host/build/lib/transport/vrt_if_pac
> ket.cpp
> [  2%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4350_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4351_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2870_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2871_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf4360_
> regs.hpp
> [  3%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9510_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9777_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad5623_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad7922_r
> egs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2829_
> regs.hpp
> [  4%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2118_
> regs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/max2112_
> regs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9862_r
> egs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ad9522_r
> egs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ads62p44
> _regs.hpp
> [  5%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/ads62p48
> _regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/tuner_49
> 37di5_regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/tda18272
> hnm_regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmk04816
> _regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf5355_
> regs.hpp
> [  6%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/adf5356_
> regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmx2592_
> regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/lmk04828
> _regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/ic_reg_maps/magnesiu
> m_cpld_regs.hpp
> [  7%] Generating /home/corad/uhd/host/build/lib/convert/convert_gene
> ral.cpp
> [  7%] Generating /home/corad/uhd/host/build/lib/rfnoc/nocscript/basi
> c_functions.hpp
> [  8%] Generating /home/corad/uhd/host/build/lib/transport/nirio/lvbi
> tx/x300_lvbitx.cpp
> [  8%] Generating /home/corad/uhd/host/build/lib/transport/nirio/lvbi
> tx/x310_lvbitx.cpp
> Scanning dependencies of target uhd
> [  8%] Building CXX object lib/CMakeFiles/uhd.dir/types/device_addr.c
> pp.o
> [  8%] Building CXX object lib/CMakeFiles/uhd.dir/types/mac_addr.cpp.
> o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/metadata.cpp.
> o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/ranges.cpp.o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/sensors.cpp.o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/serial.cpp.o
> [  9%] Building CXX object lib/CMakeFiles/uhd.dir/types/sid.cpp.o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/time_spec.cpp
> .o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/tune.cpp.o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/types.cpp.o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/wb_iface.cpp.
> o
> [ 10%] Building CXX object lib/CMakeFiles/uhd.dir/types/filters.cpp.o
> [ 11%] Building CXX object lib/CMakeFiles/uhd.dir/types/byte_vector.c
> pp.o
> [ 11%] 

Re: [USRP-users] IOError: x300 fw poke32 - reply timed out

2018-12-04 Thread Marcus Müller via USRP-users
oh wow, that's interesting, though I have little idea how to
reconciliate storage backpressure with dropping out of networking.
My best guess is that the storage system pushing back on too much data
somehow causes additional CPU load (especially: interrupts/context
switches), and that worsens the situation somehow so much that network
stacks get confused.
But that's exactly that: a wild guess in the blue.

Thus: Happy to hear you've got it working!

By the way, what's your kernel's write buffer size? In a pinch, the
following (single line) command should spit out the size in Gigibytes:

echo $(( $(sed -n -e 's/^MemTotal:[[:space:]]*\([[:digit:]]*\).*/\1/p'
/proc/meminfo) * $(sysctl -n vm/dirty_ratio) / 100. / (2**20) ))

If that is less write buffer than you expected, try upping up the
vm.dirty_ratio (i.e. percentage of RAM pages allowed to get filled
before flushing the write cache to disk is enforced and file write
operations become blocking) to something more generous – if your
system's main purpose is to write stuff to disk, and it will still
function well with the remaining 10%, try `sysctl -w vm.dirty_ratio=90`
and see whether that "evens out" the write peaks a bit.

Best regards,
Marcus  

On Tue, 2018-12-04 at 08:19 +0100, Stefan van der Linden wrote:
> It tooks us a while, but we seem to have found the root cause of the 
> issue. The RAID array which was being fed the data was able to just
> cope 
> with the dataflow peaks, although the mean dataflow was not a
> problem. 
> Therefore, when some kind of additional process fired up or some
> other 
> imperfection, it caused the buffer being used to overflow in some
> cases. 
> We were able to prevent this from happening by adding an SSD-based
> write 
> cache.
> However, we still don't understand why this effectively caused the
> X300 
> and/or the NIC to lock up, although I'm glad the problem is gone.
> 
> Kind regards,
> 
> Stefan
> 
> On 27/09/2018 11:45, Stefan van der Linden wrote:
> > Hi Marcus,
> > 
> > we've gone and updated UHD (HEAD of remotes/origin/UHD-3.13) and 
> > changed the MTU to 8000, unfortunately the problem still persists.
> > A 
> > TCP dump as discussed before is downloadable via: 
> > https://we.tl/t-zTKY2iHAlK.
> > Note that 192.168.50.1 is the host and 192.168.50.2 is the X300.
> > The 
> > download also contains a dump of the shell output, just in case.
> > The 
> > program ran without problems for a good two hours or so.
> > Hope this helps in debugging!
> > 
> > Kind regards,
> > 
> > Stefan
> > 
> > 
> > On 24/09/2018 22:38, Marcus Müller wrote:
> > > Hi Stefan,
> > > 
> > > so I've talked to our main software sustainance hero, and we
> > > rather
> > > quickly came to the conclusion that it's pretty likely you should
> > > move
> > > on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are
> > > you
> > > building from source, or are you using binary packages?
> > > 
> > > Best regards,
> > > Marcus
> > > 
> > > On Mon, 2018-09-24 at 20:04 +0200, Marcus Müller wrote:
> > > > Hi Stefan,
> > > > 
> > > > I know it's not of great comfort when an engineer finds a
> > > > problem to
> > > > be
> > > > /interesting/, but yours certainly is.
> > > > So, first things first: if the computational power and memory
> > > > of the
> > > > host that your USRP is connected to allows, it might be good to
> > > > have
> > > > a
> > > > packet capture in some kind of a ring buffer, so that you can
> > > > infer a
> > > > bit on the state at the point where things go wrong:
> > > > 
> > > > tcpdump -n # no DNS lookups
> > > > -i 
> > > > -s 0 # don't stop after a finite amount of packets
> > > > -C 400 # 400 million bytes per capture file
> > > > -W 2 # rotate through three files of capturs
> > > > -w /tmp/rotate.pcap # make sure that you're using a file that's
> > > > on an
> > > > RAM filesystem; if in doubt, make one with `mount -t tmpfs
> > > > tmpfs
> > > > /path`
> > > > 
> > > > So, yes, using an MTU of 8000 would be the first thing that the
> > > > Ettus
> > > > hivemind would recommend, too, but if you say things still go
> > > > wrong,
> > > > we
> > > > might need to dig deeper.
> > > > 
> > > > I do know that we've improved the bus clocking, and that had
> > > > impact
> > > > on
> > > > the X300 firmware. Is trying the last 3.10 release an option
> > > > for you?
> > > > 
> > > > Best regards,
> > > > Marcus
> > > > 
> > > > On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via
> > > > USRP-
> > > > users
> > > > wrote:
> > > > > Hi,
> > > > > 
> > > > > We are in the process of prototyping a setup using an X300
> > > > > with two
> > > > > UBX-40 daughterboards to be used in the validation of an
> > > > > externally
> > > > > provided signal source. The daughterboards are each dedicated
> > > > > to
> > > > > one
> > > > > of two tasks: transmitting a pre-recorded reference signal in
> > > > > a
> > > > > loop
> > > > > at 50 MSps, and capturing that same signal again after
> > > > > passing
> > > > > 

Re: [USRP-users] 2955 multiple receivers not working together

2018-11-30 Thread Marcus Müller via USRP-users
UHD is installed on your computer. You hence *can* check the UHD
version that you've installed.

On Fri, 2018-11-30 at 09:33 +, Koyel Das (Vehere) via USRP-users
wrote:
> I am attaching the .grc file. I have installed gnuradio in windows.
> Our USRP has gone for repair so can't check the UHD version.
> 
> Regards,
> Koyel
> From: USRP-users  on behalf of
> Marcus D. Leech via USRP-users 
> Sent: Thursday, November 29, 2018 9:28:47 PM
> To: usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] 2955 multiple receivers not working
> together
>  
> On 11/29/2018 02:20 AM, Koyel Das (Vehere) via USRP-users wrote:
> > Hi,
> > 
> > I am trying to receive signals from antennas connected to two RX2
> > ports of USRP 2955 R.
> > But when the frequency sink pops up there is no signal. Also I want
> > to be able
> > to use 4 receivers of USRP 2955R together in a gnuradio by using 4
> > ports in a USRP source. Two 
> > or more not working but one is working fine. Please suggest
> > solutions. Also 2 for 2954R is working correctly.
> > 
> > Regards,
> > Koyel
> > 
>  Could you perhaps share the flow-graph that you're using.  What
> version of UHD are you using?
> 
> 
> 
> ___
> 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] Is there any method for X310 to support 122.88M Sampling rate?

2018-11-30 Thread Marcus Müller via USRP-users
Hi J. Jeffson,

to answer quickly: see below.
On Fri, 2018-11-30 at 11:36 +0800, 蒋逸凡 via USRP-users wrote:
> Hi all
> I'm trying to use USRP X Series (2943/2954) in my project. I
> want to try 122.88MHz sampling rate, but ettus.com says that only
> 200MHz and 184.32MHz and the corresponding integer divisor.
> 
exactly.

> Is updating fpga image by uhd_image_downloader.py helpful?
> 

no.

> Is there any way to re-write fpga image so that it can
> support? 

no. This is a restriction of the clocking architecture and analog
components. 


> Really appreciate if someone suggests me some solution to it.

Hm, if my head calculation doesn't betray me:
122.88 MHz = 2¹⁶ · 5⁴ · 3¹ Hz
   200 MHz = 2 · 10⁸ Hz 
   = 2⁹ · 5⁸ Hz
 
Hence, 200 MHz / 122.88 MHz = 2⁻⁷·5⁴·3⁻¹

So you could build a rational resampler that interpolates by 2⁷·3 = 384
and decimates by 5⁴ = 625.

That is not a nice filter!

Don't know if I'd generally recommend an MCR of 184.32 MHz but, let's
try:

184.32 MHz = 2¹⁵ · 5⁴ · 3² Hz

Hence, 184.32 MHz / 122.88 MHz = 2⁻⁶ · 5⁴ · 3⁻²
So you could build a rational resampler that interpolates by 2⁶·3² =
576
and decimates by 5⁴ = 625.

So, that's even worse.


So, I'd say, you're not going to implement this as a rational
resampler. 

So, either find some sampling rate close enough for your system to work
(for example, if your system can work with a 2% sample rate error, go
for 120 MHz sampling rate, and things become much easier! Interpolate
by 3, decimate by 5, done, you could implement that as an FPGA
resampler yourself, if you find your computer isn't up to doing that
conversion).
Or, implement an arbitrary resampler.
I can't really advise you on that based on the info you gave us:
Arbitrary resamplers can become quite computationally intense, and ugly
in error bounds, but can often be designed to fit your specific
application's needs.

So, what application requires a sampling rate of 122.88 MHz?

Best regards,
Marcus M
> 
> Best Regards,
> J.Jeffson
> ___
> 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] weird sample values when receiving on b200

2018-10-14 Thread Marcus Müller via USRP-users
Hi Mitch,

where/how do you create the rx_streamer, and which otw / cpu format
does that use?

Best regards,

Marcus
On Thu, 2018-10-11 at 11:53 -0400, Mitch Grabner via USRP-users wrote:
> I'm doing a loopback to check which sample a certain signal level is
> found. I'm transmitting in the main thread and I create a receiver
> thread to look for the rise in the input signal. Here is my receiver
> worker
> 
> void receive_worker(
>   uhd::usrp::multi_usrp::sptr usrp,
>   std::vector > rx_buff,
>   uhd::rx_streamer::sptr rx_stream,
>   size_t total_num_rx_samps,
>   double time_to_receive,
>   std::queue* edge_queue,
>   bool* stop_receive
> ){
>   io_mutex.lock();
>   std::cout << boost::format("Receive thread started!") << std::endl;
>   io_mutex.unlock();
> 
>   //set buffers same for all channels (if more than 1)
>   std::vector *> rx_buffs(rx_stream-
> >get_num_channels(), _buff.front());
> 
>   //setup streaming
>   uhd::stream_cmd_t stream_cmd((total_num_rx_samps == 0)?
> uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS:
> uhd::stream_cmd_t::STREAM_MODE_NUM_SAMPS_AND_DONE
>   );
> 
>   io_mutex.lock();
>   // if we are looking for a finite set of samples
>   if (total_num_rx_samps > 0){
> std::cout << boost::format(
> "Begin streaming in for %u samples starting at %0.9f device
> time"
> ) % total_num_rx_samps % time_to_receive << std::endl;
>   }
>   else{
> std::cout << boost::format(
> "Begin streaming in continuous samples starting at %0.9f
> device time"
> ) % time_to_receive << std::endl;
>   }
>   io_mutex.unlock();
> 
>   //set up the RX command
>   stream_cmd.num_samps = total_num_rx_samps;
>   stream_cmd.stream_now = false;
>   stream_cmd.time_spec = uhd::time_spec_t(time_to_receive);
>   rx_stream->issue_stream_cmd(stream_cmd);
> 
>   //meta-data will be filled in by recv()
>   uhd::rx_metadata_t rx_md;
> 
>   double rx_timeout = time_to_receive + 0.1;
>   size_t num_acc_samps = 0;
>   /* - Main While Loop --- */
>   while(not *stop_receive and (num_acc_samps < total_num_rx_samps or
> total_num_rx_samps == 0)){
> //rece  ive a single full otw packet
> size_t num_rx_samps = rx_stream->recv(
>   rx_buffs, rx_buff.size(), rx_md, rx_timeout, true
> );
> rx_timeout = 0.1f; //small timeout for subsequent recv
> 
> //error handling
> if (rx_md.error_code != uhd::rx_metadata_t::ERROR_CODE_NONE){
>   io_mutex.lock();
>   std::cout << boost::format(
> "Receiver Error %s ... Shutting down!"
>   ) % rx_md.strerror() << std::endl;
>   io_mutex.unlock();
>   //set stop receive signal
>   *stop_receive = true;
> }
> 
> //look for a single rising edge
> edge_offset_calc(rx_buff, num_acc_samps, edge_queue);
> 
> 
> //keep track of absolute sample number
> num_acc_samps += num_rx_samps;
> 
> //if we were streaming continuously, send a stop command
> if (*stop_receive and total_num_rx_samps == 0){
>   // Shut down receiver
>   std::cout << boost::format("Sending stop command...") <<
> std::endl;
>   stream_cmd.stream_mode =
> uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS;
>   rx_stream->issue_stream_cmd(stream_cmd);
> }
>   }//RX while
> 
>   boost::this_thread::sleep(boost::posix_time::seconds(0.2)); //wait
> 
>   io_mutex.lock();
>   std::cout << boost::format("Receive thread ended!") << std::endl;
>   io_mutex.unlock();
> }
> 
> I create the rx thread with:
> 
> //edge queue
>   std::queue edge_queue;
>   bool stop_receive = false;
> 
>   //start the thread
>   boost::thread_group transmit_thread;
>   transmit_thread.create_thread(
> boost::bind(
>   _worker, usrp, rx_buff, rx_stream, total_num_rx_samps,
>   time_to_receive, _queue, _receive
> )
>   );
> 
> the edge calc function simply iterates through the vector and pushes
> the sample location of the rise in signal level (2-norm of the
> complex float) to the queue. When debugging I sometimes get this kind
> of output after starting up the device
> 
> Setting device timestamp to 0...
> Transmitting 50 samples at 0.2 device time
> Receive thread started!
> Begin streaming in for 40 samples starting at 0.19000 device
> time
> Transmit burst success!
> max is 0.358725
> Edge found on sample 200164 packet offset of 164
> max is 2.0942e+34
> Edge found on sample 242000 packet offset of 2000
> max is 2.0942e+34
> Edge found on sample 244000 packet offset of 2000
> max is 2.0943e+34
> Edge found on sample 254000 packet offset of 2000
> max is inf
> Edge found on sample 262000 packet offset of 2000
> max is inf
> Edge found on sample 264000 packet offset of 2000
> max is 2.09449e+34
> Edge found on sample 272000 packet offset of 2000
> max is 2.09449e+34
> Edge found on sample 274000 packet offset of 2000
> Receive thread ended!
> 
> My spp is forced to 2000 using the stream args. and This is on UHD
> 3.010.03.
> 
> thanks for the help.
> 
> On Wed, Oct 10, 

Re: [USRP-users] B210 distributed MIMO with GPSDO

2018-10-09 Thread Marcus Müller via USRP-users
Works! 

Don't forget that PPS accuracy of a GPS receiver is theoretical best-
case some 50 ns; in reality, things can get a little worse than that.

Best regards,
Marcus

On Tue, 2018-10-09 at 09:32 +0200, Stephan Esterhuizen via USRP-users
wrote:
> Hi All,
> 
> I'm looking at using multiple B210s synchronized with GPSDO
> distributed over a few kilometers. The idea is to measure time-of-
> arrival of a signal source. I understand the limitations of the GPSDO
> 1pps & 10 MHz reference frequency/time stability.
> 
> What I'm curious about is whether anybody has done this, and whether
> it worked without too much trouble. The only references I see of
> distributed MIMO, is where NI recommends using the N210:
> 
> http://www.ni.com/tutorial/14705/en/
> 
> Any advice would be greatly appreciated.
> 
> Stephan
> ___
> 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] FPGA compatibility

2018-10-09 Thread Marcus Müller via USRP-users
Hey Corey,

yep, when updating your UHD you also need to update your fpga-src
submodule; `git submodule update`. If you have changes you want to
preserve: Standard git methods apply; just make a branch in the fpga-
src submodule to contain your changes, then update the submodule, then
merge in your branch. 

Best regards,
Marcus
On Mon, 2018-10-08 at 19:42 -0600, Corey Hahn via USRP-users wrote:
> I did notice that UHD went from 4.0 to 3.14  is this a problem?  Does
> the getting started wiki need an extra step to choose the
> branch/commit?
> 
> On Mon, Oct 8, 2018 at 2:33 PM Rob Kossler  wrote:
> > Perhaps you are using fpga-src on 'master' rather than on commit
> > 'ebf5eed' which is the one paired with UHD 'master'?
> > 
> > Rob
> > 
> > On Sun, Oct 7, 2018 at 10:22 PM Corey Hahn via USRP-users <
> > usrp-users@lists.ettus.com> wrote:
> > > Been using uhd/rfnoc for 9 months now with no comparability
> > > problems i couldn't fix.
> > > My last devel version was from the beginning of June.
> > > Upgraded rfnoc and rebuilt from scratch the pybombs rfnoc
> > > packages via the getting started wiki.
> > > I have an x310 USRP
> > > Redid the place and route with the new rfnoc build.  Now i get
> > > the dreaded comparability mismatch.  In the past this was fixed
> > > because i built the bit file or ran with uhd of two different
> > > versions.  This is on one machine and should not have this
> > > problem.  Where do i start debugging this problem?
> > > 
> > > root@optical-cuda1604-20181007-srn21:~/rfnoc# uhd_usrp_probe 
> > > [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> > > UHD_3.14.0.0-110-g6af6ac32
> > > [INFO] [X300] X300 initialization sequence...
> > > Error: RuntimeError: Expected FPGA compatibility number 35, but
> > > got 36:
> > > 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:
> > > 
> > >  "/root/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:
> > > 
> > > "/root/rfnoc/bin/uhd_image_loader" --
> > > args="type=x300,addr=192.168.40.2"
> > > 
> > > For more information, refer to the UHD manual:
> > > 
> > >  http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash
> > > root@optical-cuda1604-20181007-srn21:~/rfnoc# 
> > > 
> > > ___
> > > 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] timed burst problem on B200

2018-09-30 Thread Marcus Müller via USRP-users
OK, this is alarming; could you be as nice as making a minimum piece of
code that we can run locally to reproduce? I must admit I'm more or
less in an international flight boarding line, so I might not be able
to look at this for the next 72h.

Best regards,
Marcus
On Sun, 2018-09-30 at 18:34 -0400, Mitchell J Grabner wrote:
> I've been testing with a long time_spec of 2.0 seconds. The weird
> thing 
> is the device responds with an ack @ the specified 2.0 seconds that
> the 
> burst left at that time... even though it indeed when to the RFIC 
> immediately when the send() is called. This is on uhd 3.10 and 3.14-
> git.
> 
> thanks,
> Mitch
> 
> On 9/30/2018 4:49 PM, Marcus Müller wrote:
> > Shoot, there goes my hypothesis!
> > But: how much time do you leave between set_time_now and then using
> > md
> > in a send() call? Maybe the setting happens concurrently...
> > 
> > Best regards,
> > Marcus
> > 
> > On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:
> > > Hi Marcus,
> > > 
> > > I use set_time_now(). For my project the devices are assumed
> > > un-synchronized.
> > > 
> > > thanks
> > > 
> > > On 9/30/2018 1:11 PM, Marcus Müller wrote:
> > > > Hi Mitch,
> > > > 
> > > > this is but a shot in the blue, but:
> > > > How you're setting the device clock to 0? set_time_now() or
> > > > _next_pps(), or _unknown_pps()?
> > > > 
> > > > Best regards,
> > > > Marcus the other
> > > > On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-
> > > > users
> > > > wrote:
> > > > > I've used both 3.10.3 and 3.14 (latest git master)
> > > > > 
> > > > > double time_to_transmit = 2.0;
> > > > > 
> > > > > uhd::tx_metadata_t md;
> > > > > md.start_of_burst = false;
> > > > > md.end_of_burst = false;
> > > > > md.has_time_spec = true;
> > > > > md.time_spec = uhd::time_spec_t(time_to_transmit);
> > > > > 
> > > > > //then while loop through samples
> > > > > 
> > > > > //get burst ack
> > > > > 
> > > > > On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:
> > > > > > On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users
> > > > > > wrote:
> > > > > > > I set the device time stamp to zero and immediately send
> > > > > > > the
> > > > > > > packets
> > > > > > > to the device with a timestamp of 2.0 seconds. Also
> > > > > > > wouldn't
> > > > > > > a
> > > > > > > past
> > > > > > > timestamp give late packet error?
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Mitch
> > > > > > 
> > > > > > Could you show us how you're setting the metadata?  (Like,
> > > > > > the
> > > > > > code),
> > > > > > and what version of UHD you're using?
> > > > > > 
> > > > > > 
> > > > > > > On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users
> > > > > > > wrote:
> > > > > > > > On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users
> > > > > > > > wrote:
> > > > > > > > > Hello,
> > > > > > > > > 
> > > > > > > > > I'm trying to get a timed burst working on a B200 and
> > > > > > > > > it
> > > > > > > > > looks like
> > > > > > > > > the device is transmitting the samples the instant
> > > > > > > > > they
> > > > > > > > > reach
> > > > > > > > > the
> > > > > > > > > device (tested by listening on a second device)
> > > > > > > > > instead
> > > > > > > > > of
> > > > > > > > > holding
> > > > > > > > > them until the time specified in md.time_spec.
> > > > > > > > > I set up the first packet's metadata with
> > > > > > > > > start_of_burst,
> > > > > > > > > has_time_spec and give it time_spec =
> > > > > > > > > uhd::time_spec_t(time_to_send); The following packets
> > > > > > > > > have no
> > > > > > > > > burst
> > > > > > > > > metadata and the last has end_of_burst. I wait for
> > > > > > > > > packet
> > > > > > > > > ack
> > > > > > > > > with
> > > > > > > > > recv_async_msg and it is received after the time
> > > > > > > > > specified
> > > > > > > > > in
> > > > > > > > > time_spec even though the samples left immediately.
> > > > > > > > > There
> > > > > > > > > are
> > > > > > > > > no
> > > > > > > > > other errors like underflow, overflow or late
> > > > > > > > > packets.
> > > > > > > > > Has
> > > > > > > > > anyone
> > > > > > > > > had this issue or has any idea how to fix it? I must
> > > > > > > > > be
> > > > > > > > > missing
> > > > > > > > > something very simple.
> > > > > > > > > 
> > > > > > > > > Thanks for the help,
> > > > > > > > > Mitch
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Keep in mind that the time-to-send is from the
> > > > > > > > perspective
> > > > > > > > of
> > > > > > > > the
> > > > > > > > device, so you have to make sure that your own flow is
> > > > > > > > synchronized to
> > > > > > > > the same time as the device.
> > > > > > > > 
> > > > > > > > If a packet arrives with a time specified that is in
> > > > > > > > the
> > > > > > > > past,
> > > > > > > > it
> > > > > > > > gets sent immediately.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > ___
> > > > > > > > 

Re: [USRP-users] UHD occupying 100% CPU

2018-09-30 Thread Marcus Müller via USRP-users
Hi Vladica,

did you try the 3.13 release line, too? This might either solve your
issue or at least help us narrow down reasons. I don't think we'll put
out 3.10.X.X and 3.11.X.X releases for ever, since they're not the
current release branch.

Best regards,
Marcus

On Wed, 2018-09-26 at 14:18 +0200, Vladica Sark via USRP-users wrote:
> Hi folks,
> 
> I have a C/C++ code that transmits frames in a given time slots from
> 2x 
> X310. All 4 AFEs are used (2 on each X310). The duty cycle is
> relatively 
> low, 1 frame in each 10 ms. Frame duration is a few hundred 
> microseconds. The processing is not CPU intensive. The problem is
> that 
> all 4 cores on my laptop have 100% utilization during transmission.
> This 
> happens with all UHD 3.10 and 3.11 releases but not with 3.9. With
> 3.9 
> the CPU utilization is less than 10%.
> 
> I had this problem in the past but I was not using a release, but a 
> version under development. I switched to a release, as it was
> suggested 
> here, since the release should have less bugs. Unfortunately, these
> bugs 
> were not corrected in the coming 3.10 and 3.11 releases.
> 
> BR,
> Vladica
> 
> ___
> 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] timed burst problem on B200

2018-09-30 Thread Marcus Müller via USRP-users
Shoot, there goes my hypothesis!
But: how much time do you leave between set_time_now and then using md
in a send() call? Maybe the setting happens concurrently...

Best regards,
Marcus

On Sun, 2018-09-30 at 14:51 -0400, Mitchell J Grabner wrote:
> Hi Marcus,
> 
> I use set_time_now(). For my project the devices are assumed 
> un-synchronized.
> 
> thanks
> 
> On 9/30/2018 1:11 PM, Marcus Müller wrote:
> > Hi Mitch,
> > 
> > this is but a shot in the blue, but:
> > How you're setting the device clock to 0? set_time_now() or
> > _next_pps(), or _unknown_pps()?
> > 
> > Best regards,
> > Marcus the other
> > On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-
> > users
> > wrote:
> > > I've used both 3.10.3 and 3.14 (latest git master)
> > > 
> > > double time_to_transmit = 2.0;
> > > 
> > > uhd::tx_metadata_t md;
> > > md.start_of_burst = false;
> > > md.end_of_burst = false;
> > > md.has_time_spec = true;
> > > md.time_spec = uhd::time_spec_t(time_to_transmit);
> > > 
> > > //then while loop through samples
> > > 
> > > //get burst ack
> > > 
> > > On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:
> > > > On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users
> > > > wrote:
> > > > > I set the device time stamp to zero and immediately send the
> > > > > packets
> > > > > to the device with a timestamp of 2.0 seconds. Also wouldn't
> > > > > a
> > > > > past
> > > > > timestamp give late packet error?
> > > > > 
> > > > > Thanks,
> > > > > Mitch
> > > > 
> > > > Could you show us how you're setting the metadata?  (Like, the
> > > > code),
> > > > and what version of UHD you're using?
> > > > 
> > > > 
> > > > > On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:
> > > > > > On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:
> > > > > > > Hello,
> > > > > > > 
> > > > > > > I'm trying to get a timed burst working on a B200 and it
> > > > > > > looks like
> > > > > > > the device is transmitting the samples the instant they
> > > > > > > reach
> > > > > > > the
> > > > > > > device (tested by listening on a second device) instead
> > > > > > > of
> > > > > > > holding
> > > > > > > them until the time specified in md.time_spec.
> > > > > > > I set up the first packet's metadata with start_of_burst,
> > > > > > > has_time_spec and give it time_spec =
> > > > > > > uhd::time_spec_t(time_to_send); The following packets
> > > > > > > have no
> > > > > > > burst
> > > > > > > metadata and the last has end_of_burst. I wait for packet
> > > > > > > ack
> > > > > > > with
> > > > > > > recv_async_msg and it is received after the time
> > > > > > > specified
> > > > > > > in
> > > > > > > time_spec even though the samples left immediately. There
> > > > > > > are
> > > > > > > no
> > > > > > > other errors like underflow, overflow or late packets.
> > > > > > > Has
> > > > > > > anyone
> > > > > > > had this issue or has any idea how to fix it? I must be
> > > > > > > missing
> > > > > > > something very simple.
> > > > > > > 
> > > > > > > Thanks for the help,
> > > > > > > Mitch
> > > > > > > 
> > > > > > 
> > > > > > Keep in mind that the time-to-send is from the perspective
> > > > > > of
> > > > > > the
> > > > > > device, so you have to make sure that your own flow is
> > > > > > synchronized to
> > > > > >the same time as the device.
> > > > > > 
> > > > > > If a packet arrives with a time specified that is in the
> > > > > > past,
> > > > > > it
> > > > > > gets sent immediately.
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > ___
> > > > > > 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
> 
> 


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


Re: [USRP-users] Messaging the DDC

2018-09-30 Thread Marcus Müller via USRP-users
Hi Jason,

I was about to write code, but then realized: gr-ettus' Block impl
already has what you need, the message port "rfnoc", which'll accept
messages in the PMT dict format. You can extract the shape of
information you need to send in from the  tags in
uhd_rfnoc_ddc.xml.

I'm attaching what I hope will fix your problem as a patch (use with
`git apply` from within gr-ettus). We'll most likely upstream a more
general changeset.

Best regards,
Marcus

On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote:
> I have a block that outputs a message with a frequency.  I would love
> to be able to set the frequency adjustment in the RFNoC DDC, but I
> don't see a way to do it it automagically.
> 
> I am guessing that there is no way to do it even though it can be set
> from a variable slider easily. Is there an option I am missing?
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
From 72223fc4bc5ea039d156498686fd1be0c2912af0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Marcus=20M=C3=BCller?= 
Date: Sun, 30 Sep 2018 21:19:07 +0200
Subject: [PATCH] Adding a message port to the DDC block XML

Other blocks already have that. The DDC block shouldn't be an exception
to that!

Reference email: [USRP-users] Messaging the DDC
Date:	Wed, 26 Sep 2018 19:45:07 -0400 (09/27/2018 01:45:07 AM)
---
 grc/uhd_rfnoc_ddc.xml | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/grc/uhd_rfnoc_ddc.xml b/grc/uhd_rfnoc_ddc.xml
index bb5fdc0..02c2389 100644
--- a/grc/uhd_rfnoc_ddc.xml
+++ b/grc/uhd_rfnoc_ddc.xml
@@ -118,6 +118,12 @@ for chan in xrange($num_chans):
 $num_chans
   
 
+  
+rfnoc
+message
+1
+  
+
   
 out
 complex
-- 
2.17.1

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


Re: [USRP-users] Messaging the DDC

2018-09-30 Thread Marcus Müller via USRP-users
Hi Jason,

I'd agree, it'd be desirable if the block accepted messages; after all,
that'd be a good, threadsafe thing to have.
I'll be on a flight, and don't have an RFNoC device on me (I know, a
shame), so I won't be able to test, but adding a message handler to 
rfnoc_generic_impl.cc should involve little to no magic.
Then, you could use Tim O'Shea's message lambda block to transform your
message into exactly the shape of message that the message handler
would understand.

Best regards,
Marcus
On Wed, 2018-09-26 at 19:45 -0400, Jason Matusiak via USRP-users wrote:
> I have a block that outputs a message with a frequency.  I would love
> to be able to set the frequency adjustment in the RFNoC DDC, but I
> don't see a way to do it it automagically.
> 
> I am guessing that there is no way to do it even though it can be set
> from a variable slider easily. Is there an option I am missing?
> ___
> 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 Custom Filtering in Freq domain

2018-09-30 Thread Marcus Müller via USRP-users
Hi Rob,

it's been a while, but I've played around with an overlap-save FFT
filter in RFNoC. Sadly, I didn't keep the code myself, but I think I
can get it if I ask the right people; it's been my first stumblings in
RFNoC ... so, not quite sure how much help the code would be. Wouldn't
write the same code today, and there's no magic involved there. But a
couple of bugs were definitely created along the way.
It was a rather textbook implementation based on – I think– a 256-FFT.
But: I just had my multiplication done in the overlapping logic, IIRC.
Must've been complex, too, didn't have linear phase in the system I was
simulating with that.

Best regards,
Marcus

On Thu, 2018-09-27 at 13:44 -0400, Rob Kossler via USRP-users wrote:
> Hi,
> I am just getting started on some custom RFNoC development and trying
> to decide how to approach the problem.  Essentially, I want to
> implement a pair of filters in the frequency domain.  It is similar
> to a pair of FIR filters (on a block-by-block basis) but I want the
> capability for very long filters (equal in length to FFT size).  I
> expect that it is not possible to have so many taps using the
> existing FIR filter so that is why I want to apply in the freq
> domain.  
> 
> I noticed that there is a Window RFNoC block that could be used as
> part of my development, but it appears that this window uses "real"
> rather than "complex" coefficients.  Anyway, here are the steps I
> want to implement:
> FFT incoming stream
> Split FFT output into two streams
> Multiply Stream 1 by complex filter 1 (same length as FFT)
> Multiply Stream 2 by complex filter 2 (same length as FFT)
> IFFT Stream 1
> IFFT Stream 2
> I considered modifying the existing window.v to handle complex
> coefficients.  I also considered using the new "replay" NOC block to
> store the coefficients and stream them out in a circular fashion. 
> This might use the "multiply.v" component, but again it would need to
> be modified to handle complex multiplies.
> 
> Anyway, as I am just getting started, I am looking for any helpful
> advice.  Thanks.
> 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] timed burst problem on B200

2018-09-30 Thread Marcus Müller via USRP-users
Hi Mitch,

this is but a shot in the blue, but:
How you're setting the device clock to 0? set_time_now() or
_next_pps(), or _unknown_pps()?

Best regards,
Marcus the other
On Thu, 2018-09-27 at 18:47 -0400, Mitchell J Grabner via USRP-users
wrote:
> I've used both 3.10.3 and 3.14 (latest git master)
> 
> double time_to_transmit = 2.0;
> 
> uhd::tx_metadata_t md;
> md.start_of_burst = false;
> md.end_of_burst = false;
> md.has_time_spec = true;
> md.time_spec = uhd::time_spec_t(time_to_transmit);
> 
> //then while loop through samples
> 
> //get burst ack
> 
> On 9/27/2018 6:32 PM, Marcus D. Leech via USRP-users wrote:
> > On 09/27/2018 06:27 PM, Mitchell J Grabner via USRP-users wrote:
> > > I set the device time stamp to zero and immediately send the
> > > packets 
> > > to the device with a timestamp of 2.0 seconds. Also wouldn't a
> > > past 
> > > timestamp give late packet error?
> > > 
> > > Thanks,
> > > Mitch
> > 
> > Could you show us how you're setting the metadata?  (Like, the
> > code), 
> > and what version of UHD you're using?
> > 
> > 
> > > 
> > > On 9/27/2018 5:25 PM, Marcus D. Leech via USRP-users wrote:
> > > > On 09/27/2018 05:02 PM, Mitch Grabner via USRP-users wrote:
> > > > > Hello,
> > > > > 
> > > > > I'm trying to get a timed burst working on a B200 and it
> > > > > looks like 
> > > > > the device is transmitting the samples the instant they reach
> > > > > the 
> > > > > device (tested by listening on a second device) instead of
> > > > > holding 
> > > > > them until the time specified in md.time_spec.
> > > > > I set up the first packet's metadata with start_of_burst, 
> > > > > has_time_spec and give it time_spec = 
> > > > > uhd::time_spec_t(time_to_send); The following packets have no
> > > > > burst 
> > > > > metadata and the last has end_of_burst. I wait for packet ack
> > > > > with 
> > > > > recv_async_msg and it is received after the time specified
> > > > > in 
> > > > > time_spec even though the samples left immediately. There are
> > > > > no 
> > > > > other errors like underflow, overflow or late packets. Has
> > > > > anyone 
> > > > > had this issue or has any idea how to fix it? I must be
> > > > > missing 
> > > > > something very simple.
> > > > > 
> > > > > Thanks for the help,
> > > > > Mitch
> > > > > 
> > > > 
> > > > Keep in mind that the time-to-send is from the perspective of
> > > > the 
> > > > device, so you have to make sure that your own flow is
> > > > synchronized to
> > > >   the same time as the device.
> > > > 
> > > > If a packet arrives with a time specified that is in the past,
> > > > it 
> > > > gets sent immediately.
> > > > 
> > > > 
> > > > 
> > > > ___
> > > > 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


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


Re: [USRP-users] B205 External Reference issue

2018-09-30 Thread Marcus Müller via USRP-users
Hm, there's beauty to that, but also there's beauty in not letting the
oscillator drift of indefinitely after you've locked once.
So, the classical fastlock at startup/loss of reference lock, and then
increasingly reduced loop filter bandwidth would probably be even
better.
But that means relatively intrusive changes; you'd make `PFD_PERIOD_*`
adaptive, you adapt the `err` clip boundaries, `lock_margin` and so on;
the values used in b205_ref_pll are pretty certainly results of
physical-reality-based verification¹. That's the point where you'd
spend serious point characterizing the long-time behaviour of something
that probably depends a lot on the characteristics of your clock source
(unless that clock source is way superior to anything on the USRP).
Also, that'd probably be the point where one would have to think about
replacing the well-understood rational ratio PFD control loop with
something more complex (and thus harder to make meet timing at
acceptable resource usage and quantization loss) like an extended
Kalman that can take the nonlinearities of the system into account. 
To be perfectly honest, I don't see either happen very soon.

So, something like extending the state machine in b205_ref_pll to
another state that has a larger threshold until it drops back into an
adjusting state and adding a settings register to manually fiddle with
the state would be the quick and potentially hazardous solution here,
I'd guess.

Best regards,
Marcus

¹ a.k.a. experimentation  
On Sun, 2018-09-30 at 11:34 +0200, Sylvain Munaut via USRP-users wrote:
> Hi,
> 
> I didn't see the screenshots (not posted to the list ?)
> 
> But if absolute precision of the clock doesn't matter, you might be
> better off disabling the servo loop once it's "close enough". That
> will require fpga modifications to expose the refpll control though.
> Actually I think this would be a nice improvement in general for the
> b205 to have the DAC value exposed in UHD and allow to enable/disable
> the servo loop, just a thought :p
> 
> Cheers,
> 
> Sylvain Munaut
> ___
> 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] about boost::condition_variable

2018-09-30 Thread Marcus Müller via USRP-users
Hi Guangyao,

boost is a very large C++ project which isn't part of UHD, but a
dependency.
In case you're looking for documentation of anything in the boost::
namespace, https://www.boost.org is the place to look.

Usually, you wouldn't interact with the threading within UHD. What is
the specific thing you need to solve?


Best regards,
Marcus

On Sun, 2018-09-30 at 12:01 +, guangyao yu via USRP-users wrote:
> HI,
>I see boost::condition_variable is used for stream tx/rx data in
> UHD code, but I can't find the other thread code in the code.Someone
> can introduce it ? 
> 
> Thanks :)
> 
> guangyao
> 2018.9.30
> 
> 发自 Android 版 Yahoo 邮箱
> ___
> 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] DMA FIFO Resizing

2018-09-24 Thread Marcus Müller via USRP-users
Hello Brian,

so, the power-of-two FIFO sizes pretty much happen because you can only
divide addresses by full bit prefixes. That seems to be reflected in
noc_shell.v; not quite sure how deep the changes would have to go to
get rid of that restriction.

Best regards,
Marcus

On Mon, 2018-09-24 at 14:52 -0400, Brian Padalino via USRP-users wrote:
> I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the
> installation of UHD as of current master:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/include/uhd/rfnoc/CMakeLists.txt
> 
> It seems like this is just a simple oversight, so I modified it
> locally.  I've been running doing some latency experiments and
> modifying the size of the DMA FIFO using the resize() method:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L65
> 
> And it seems there's a bit of a restriction on the sizing associated
> with the FIFO:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L263
> 
> I see it currently says that the FIFO needs to be >8k, and it has to
> be a power of 2.  If either of those criteria fails, an exception is
> thrown.
> 
> A few requests:
> 
> (1) Can you not throw an exception, but print a warning and resolve
> the criteria?  For example, if I ask for < 8k, up it to 8k and print
> a warning it's been upped.  If I ask for a non-power of 2, can you
> print a warning and up to to the next supported power of 2?  Think of
> this like a request for a sample rate - if you can't get the exact
> one, you get what's close and the user can query the actual value?
> 
> (2) Speaking of powers of 2, why is this a requirement?  Can it be
> any value that is a multiple of a 4k page boundary?  Is there
> something inside the FPGA logic that doesn't allow this to happen? 
> Powers of 2 can be a large buffer size changes.
> 
> Thanks,
> 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] DMA FIFO Resizing

2018-09-24 Thread Marcus Müller via USRP-users
Hi Brian,

thanks! Quick update first: raised the CMakeLists omission internally,
should be fixed soon, far as I can tell.

Best regards,
Marcus
On Mon, 2018-09-24 at 14:52 -0400, Brian Padalino via USRP-users wrote:
> I noticed that the dma_fifo_block_ctrl.hpp file isn't included in the
> installation of UHD as of current master:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/include/uhd/rfnoc/CMakeLists.txt
> 
> It seems like this is just a simple oversight, so I modified it
> locally.  I've been running doing some latency experiments and
> modifying the size of the DMA FIFO using the resize() method:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/rfnoc/dma_fifo_block_ctrl_impl.cpp#L65
> 
> And it seems there's a bit of a restriction on the sizing associated
> with the FIFO:
> 
>   
> https://github.com/EttusResearch/uhd/blob/6af6ac32c30d2dc0efa6eab61e4a3920649e3e62/host/lib/usrp/cores/dma_fifo_core_3000.cpp#L263
> 
> I see it currently says that the FIFO needs to be >8k, and it has to
> be a power of 2.  If either of those criteria fails, an exception is
> thrown.
> 
> A few requests:
> 
> (1) Can you not throw an exception, but print a warning and resolve
> the criteria?  For example, if I ask for < 8k, up it to 8k and print
> a warning it's been upped.  If I ask for a non-power of 2, can you
> print a warning and up to to the next supported power of 2?  Think of
> this like a request for a sample rate - if you can't get the exact
> one, you get what's close and the user can query the actual value?
> 
> (2) Speaking of powers of 2, why is this a requirement?  Can it be
> any value that is a multiple of a 4k page boundary?  Is there
> something inside the FPGA logic that doesn't allow this to happen? 
> Powers of 2 can be a large buffer size changes.
> 
> Thanks,
> 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] PCIe driver frame size

2018-09-24 Thread Marcus Müller via USRP-users
Well, there *is* a bit of history on these package sizes. Now, having
had frequent communication with you: 4kB is an effect of system page
sizes. For more detail, see x300_impl.hpp's comments on
X300_PCIE_RX_DATA_FRAME_SIZE. But: you're right, this is a communicated
transport property, but since you basically know what you're doing (and
know what to revert when things break), go ahead and modify things
within the limits of what's stated in said comment.

Best regards,
Marcus

On Mon, 2018-09-24 at 20:20 +, Eugene Grayver wrote:
> Yep, that's what seems to be the case.  The whole point of PCIe is
> lower latency -- with a frame size that large I can get lower latency
> w/ 10 GbE and 500B frame size.  I can't imagine it is a large effort
> to get that fixed :)
> 
> 
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Eng.
> Tel: 310.336.1274
> 
> 
> -Original Message-
> From: Marcus Müller [mailto:marcus.muel...@ettus.com] 
> Sent: Monday, September 24, 2018 11:41 AM
> To: Eugene Grayver ; 
> usrp-users@lists.ettus.com
> Subject: Re: [USRP-users] PCIe driver frame size
> 
> Hi Eugene,
> 
> I'm not an expert on the PCIe transport, but as far as I can tell
> from 3.11.0.1's
> 
> uhd::transport::muxed_zero_copy_if::sptr make_muxed_pcie_msg_xport
> 
> the PCIe frame sizes seem to be immutable (4 kB, in fact, which,
> subtracting header and dividing by sample bitwidth, leads to 1020
> samples per frame).
> 
> Best regards,
> Marcus
> 
> On Fri, 2018-09-21 at 18:32 +, Eugene Grayver via USRP-users
> wrote:
> > Is there  a way to specify the frame size on the PCIe
> > interface?  I 
> > tried using the same keywords as for the NIC, but it had no effect.
> > I need low-latency and the default frame size is 5000 bytes (much
> > too 
> > large for my needs).
> >  
> > ___
> > Eugene Grayver, Ph.D.
> > Aerospace Corp., Principal Eng.
> > Tel: 310.336.1274
> > 
> >  
> > ___
> > 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: x300 fw poke32 - reply timed out

2018-09-24 Thread Marcus Müller via USRP-users
Hi Stefan,

so I've talked to our main software sustainance hero, and we rather
quickly came to the conclusion that it's pretty likely you should move
on to the head of the 3.13 branch (remotes/origin/UHD-3.13). Are you
building from source, or are you using binary packages?

Best regards,
Marcus

On Mon, 2018-09-24 at 20:04 +0200, Marcus Müller wrote:
> Hi Stefan,
> 
> I know it's not of great comfort when an engineer finds a problem to
> be
> /interesting/, but yours certainly is.
> So, first things first: if the computational power and memory of the
> host that your USRP is connected to allows, it might be good to have
> a
> packet capture in some kind of a ring buffer, so that you can infer a
> bit on the state at the point where things go wrong:
> 
> tcpdump -n # no DNS lookups 
> -i  
> -s 0 # don't stop after a finite amount of packets
> -C 400 # 400 million bytes per capture file
> -W 2 # rotate through three files of capturs
> -w /tmp/rotate.pcap # make sure that you're using a file that's on an
> RAM filesystem; if in doubt, make one with `mount -t tmpfs tmpfs
> /path`
> 
> So, yes, using an MTU of 8000 would be the first thing that the Ettus
> hivemind would recommend, too, but if you say things still go wrong,
> we
> might need to dig deeper.
> 
> I do know that we've improved the bus clocking, and that had impact
> on
> the X300 firmware. Is trying the last 3.10 release an option for you?
> 
> Best regards,
> Marcus
> 
> On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via USRP-
> users 
> wrote:
> > Hi,
> > 
> > We are in the process of prototyping a setup using an X300 with two
> > UBX-40 daughterboards to be used in the validation of an externally
> > provided signal source. The daughterboards are each dedicated to
> > one
> > of two tasks: transmitting a pre-recorded reference signal in a
> > loop
> > at 50 MSps, and capturing that same signal again after passing
> > through a chain of devices under test at 25MSps. This is to run
> > continuously up to 24 hours.
> > 
> > The X300 is connected to the (dedicated) host computer via a 10Gbps
> > connection to an Intel X520-DA2 NAC over SFP+. On the host, we are
> > currently using the kitchen_sink utility included with UHD to run
> > the
> > system in multi-channel mode. We are using UHD 3.11.0.1.
> > 
> > The system works flawlessly when performing short measurements
> > (say,
> > up to an hour or so). However, having recently started setting up
> > the
> > system for long 24 hour tests, we are seeing timeouts from which
> > UHD
> > is unable to recover. These timeouts occur randomly: sometimes they
> > occur after ~1 hours, other times they occur after ~18 hours and
> > everywhere in between. Naturally, this random behaviour makes it
> > difficult to debug.
> > 
> > The error message retrieved from UHD is as follows:
> > 
> > As previous messages on this list have mentioned varying the MTU
> > settings (for example: 
> > 
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html
> > ), this was the first thing we tried. Unfortunately, these timeouts
> > occur more often at lower MTU values.
> > 
> > Hopefully someone is able to point us in the right direction.
> > Perhaps
> > we are dealing with hardware issues here, but I'd I hope we are
> > able
> > to solve this through software.
> > 
> > Thanks,
> > Stefan van der Linden
> > ___
> > 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] PCIe driver frame size

2018-09-24 Thread Marcus Müller via USRP-users
Hi Eugene,

I'm not an expert on the PCIe transport, but as far as I can tell from
3.11.0.1's

uhd::transport::muxed_zero_copy_if::sptr make_muxed_pcie_msg_xport

the PCIe frame sizes seem to be immutable (4 kB, in fact, which,
subtracting header and dividing by sample bitwidth, leads to 1020
samples per frame).

Best regards,
Marcus

On Fri, 2018-09-21 at 18:32 +, Eugene Grayver via USRP-users wrote:
> Is there  a way to specify the frame size on the PCIe interface?  I
> tried using the same keywords as for the NIC, but it had no effect. 
> I need low-latency and the default frame size is 5000 bytes (much too
> large for my needs).
>  
> ___
> Eugene Grayver, Ph.D.
> Aerospace Corp., Principal Eng.
> Tel: 310.336.1274
> 
>  
> ___
> 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] How to transmit different signals simultaneously?

2018-09-24 Thread Marcus Müller via USRP-users
Hi Ge,

so, the UHD API lets you define streamers with multiple channels. Then
it's just a matter of calling send() with a list of multiple buffers to
be sent.

But: if you're new to all this, or want to use GNU Radio anyways, or
rather build DSP than writing driver interfacing C++ code:
GNU Radio's USRP sink can be set to two channels and will give you
exactly the ability you want: to stream two different signals to the
device.

If you want to learn about GNU Radio, the tutorials are pretty
certainly the way to go:

https://tutorials.gnuradio.org

Best regards,
Marcus

On Mon, 2018-09-24 at 11:29 -0700, ge wang via USRP-users wrote:
> Hi,
> 
> I write to ask some questions about USRP X310. I use two SBX daughter
> boards, but I do not know how to control them separately. For
> example, how to let them transmit different signals simultaneously? 
> Is there any published project that I can learn from? 
> 
> Best regard!
> 
> Ge
> -- 
> Ge Wang
> Ph.D Candidate of Xi'an Jiaotong University
> Visiting student at University of California, Santa Cruz
> ___
> 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 E313 | WBFM Issues

2018-09-24 Thread Marcus Müller via USRP-users
Hi Ryan,

hm, there's honestly quite a few things that can simply go wrong on a
demodulation/DSP/signal side of things without nothing misbehaving or
you doing any mistakes. Your single-tone test hence was very clever to
do!

So, my recommendation is this:
First of all, verify that the reception strength / SNR is actually
reasonably good. You said you saw the signal in a frequency plot – so
how many dB were between signal and noise floor? If it's worse than
let's say 20 dB, you might need more RX gain or a better antenna (FM in
cities typically is pretty strong).

If that is fine, *make a raw recording* (using either GNU Radio with a
file sink directly attached through a head block to the USRP source, or
with the rx_samples_to_file tool) of a few seconds worth of samples,
and try to demodulate them on your PC – if that doesn't work, we know
there's something else to fix.

Best regards,
Marcus
  
On Fri, 2018-09-21 at 15:28 -0400, Ryan Campiz via USRP-users wrote:
> 
> Ryan Campiz  
> Thu, Sep 20, 5:21 PM (21 hours ago)
> 
> to support 
> Greetings,
> 
> I'm having trouble with a basic Wide-Band FM (WBFM) demodulation
> tutorial. I am using the Ettus USRP E313. The Ettus USRP E313 is
> basically an enclosure with an Ettus E310 and Power/Ethernet PCB with
> the RF, DC Power, Ethernet, and USB ports.
> 
> FM DEMODULATION TUTORIAL
> In my application, as the host machine, I am using a Virtual Machine
> with Ubuntu 16.04 (64-bit). I downloaded all of the software as
> instructed in the AN-445 Ettus Application Note.
> 
> In my application, the tutorial that I am following is from the AN-
> 335 Application Note from Ettus. The tutorial is not complicated. I
> downloaded the Flowgraph files that the tutorial comes with. When I
> generate both python files and run them respectively on the E310 and
> the Host Machine, all I hear is static. I can see evidence of a
> received signal on the Frequency Spectrum graph, but I only hear
> static. What’s more, as I vary the radio frequency, I do see the
> Frequency Spectrum graph change, but I see no evidence of any FM
> Radio Stations.
> 
> DETOUR: DEMONSTRATING I COULD AT LEAST HEAR A 1KHZ TONE FROM THE E310
> Just to make sure that it was possible to hear anything from the
> E310, I created a simple flowgraph for the E310. All it did was
> generate a Signal Source: a tone of 1kHz. On the other end, with the
> VM, I had an Audio Sink and a Time Graph and Waterfall Diagram. I was
> able to hear the tune. But it was choppy. And there was latency with
> the controls. A system block diagram of this set-up can be seen
> below. 
> 
> 
> LAST EFFORTS AND SPECULATION
> After demonstrating that I could hear at least a tone, I moved back
> to the FM Demodulation Tutorial. I tried for a day to get it to run.
> After no success, I used other resources to try to find where the
> process could be going wrong. Once such resource is the YouTube video
> "How To Build an FM Receiver with the USRP in Less Than 10 Minutes".
> That YouTube video is made by Ettus Research.  It was well-produced
> and easy to follow. However, even after watching it several times I
> could not locate what could be going wrong in the RF Demodulation
> flowgraph.
> 
> I am so uncertain at this point that I am starting to wonder if
> either:
> 
> A.  the RF Front End is not working, or
> B.  the OS image on the Ettus E310 is very slightly corrupted, or
> C.  the FPGA is not programmed (built?) correctly.
> 
> What could be going wrong?
> 
> 
> 
> 
> 
> Ryan Campiz
> Electrical/RF Engineer
> AREA-I
> where ideas take flight
> 
> 1590 N. Roberts Rd., Ste 102
> Kennesaw, GA 30144
> 1590 N. Roberts Rd., Ste 102
> Kennesaw, GA 30144
> Direct: 470-481-4054
> Fax: 678-594-5228
> 
> PROPRIETARY AND CONFIDENTIAL: This message, including any attachment,
> is confidential information of Area-I, Inc. This message may contain
> information that is privileged and exempt from disclosure under
> applicable law and is intended only for the individual or entity to
> which it is addressed. If the reader of this message is not the
> intended recipient, or the employee or agent responsible for
> delivering the message to the intended recipient, you are notified
> that any use, dissemination, distribution or copying of this
> communication is strictly prohibited. If you have received this
> communication in error, please contact the sender immediately by e-
> mail and destroy all copies of the original message and any
> attachment.
> INTERNATIONAL TRAFFIC IN ARMS REGULATIONS (ITAR) NOTICE: Any
> drawings, specifications, or other proprietary data contained within,
> or associated with this correspondence, or any subsequent
> correspondence including, but not limited to U.S. Post, faxes, etc.,
> are considered controlled data. As such, this data/information is
> subject to U.S. Export Control under the Department of State,
> International Traffic in Arms Regulation (ITAR). These
> drawings/specifications may not be exported 

Re: [USRP-users] IOError: x300 fw poke32 - reply timed out

2018-09-24 Thread Marcus Müller via USRP-users
Hi Stefan,

I know it's not of great comfort when an engineer finds a problem to be
/interesting/, but yours certainly is.
So, first things first: if the computational power and memory of the
host that your USRP is connected to allows, it might be good to have a
packet capture in some kind of a ring buffer, so that you can infer a
bit on the state at the point where things go wrong:

tcpdump -n # no DNS lookups 
-i  
-s 0 # don't stop after a finite amount of packets
-C 400 # 400 million bytes per capture file
-W 2 # rotate through three files of capturs
-w /tmp/rotate.pcap # make sure that you're using a file that's on an
RAM filesystem; if in doubt, make one with `mount -t tmpfs tmpfs /path`

So, yes, using an MTU of 8000 would be the first thing that the Ettus
hivemind would recommend, too, but if you say things still go wrong, we
might need to dig deeper.

I do know that we've improved the bus clocking, and that had impact on
the X300 firmware. Is trying the last 3.10 release an option for you?

Best regards,
Marcus

On Mon, 2018-09-24 at 09:23 +0200, Stefan van der Linden via USRP-users 
wrote:
> Hi,
> 
> We are in the process of prototyping a setup using an X300 with two
> UBX-40 daughterboards to be used in the validation of an externally
> provided signal source. The daughterboards are each dedicated to one
> of two tasks: transmitting a pre-recorded reference signal in a loop
> at 50 MSps, and capturing that same signal again after passing
> through a chain of devices under test at 25MSps. This is to run
> continuously up to 24 hours.
> 
> The X300 is connected to the (dedicated) host computer via a 10Gbps
> connection to an Intel X520-DA2 NAC over SFP+. On the host, we are
> currently using the kitchen_sink utility included with UHD to run the
> system in multi-channel mode. We are using UHD 3.11.0.1.
> 
> The system works flawlessly when performing short measurements (say,
> up to an hour or so). However, having recently started setting up the
> system for long 24 hour tests, we are seeing timeouts from which UHD
> is unable to recover. These timeouts occur randomly: sometimes they
> occur after ~1 hours, other times they occur after ~18 hours and
> everywhere in between. Naturally, this random behaviour makes it
> difficult to debug.
> 
> The error message retrieved from UHD is as follows:
> 
> As previous messages on this list have mentioned varying the MTU
> settings (for example: 
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-November/039561.html
> ), this was the first thing we tried. Unfortunately, these timeouts
> occur more often at lower MTU values.
> 
> Hopefully someone is able to point us in the right direction. Perhaps
> we are dealing with hardware issues here, but I'd I hope we are able
> to solve this through software.
> 
> Thanks,
> Stefan van der Linden
> ___
> 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] B210 two channel capacity

2018-09-09 Thread Marcus Müller via USRP-users
to be a little more specific: The baseband data rate of the FPGA /
AD9361 interface limits the interface to a **cumulative** 61.44 in RX.
So, no, that modification is not possible.

Best regards,
Marcus M

On Sun, 2018-09-09 at 13:37 -0700, Neel Pandeya via USRP-users wrote:
> Hello Chintan:
> 
> Yes, on the B210, in 1x1 mode, the maximum sampling rate is 61.44
> Msps, and in 2x2 mode, the maximum sampling rate is 30.72 Msps.
> 
> The tweak/modification that you mention has not been implemented for
> the B210.
> 
> --Neel Pandeya
> 
> 
> 
> 
> On 9 September 2018 at 13:20, Chintan Patel via USRP-users  s...@lists.ettus.com> wrote:
> > Hi Marcus,
> > 
> > Thanks for the clarification.  So the max rate for two channels on
> > the B210 is 30.72Msps, right? Reading the 9361 manual, it seems
> > that if one wants to operate in RX-only (dual-port half-duplex)
> > mode, the 61.44Msps rate might be achievable (at the expense of no
> > TX). Any idea if this modification has been tried out on the B210?
> > It would be an invasive change since the AD9361 digital interface
> > in the FPGA would need tweaks, but any thoughts on if it was
> > theoretically possible or not.
> > 
> > Chintan
> > 
> > 
> > On Sun, Sep 9, 2018 at 11:33 AM Marcus D. Leech via USRP-users  > p-us...@lists.ettus.com> wrote:
> > > On 09/09/2018 11:21 AM, Chintan Patel via USRP-users wrote:
> > > > Hi,
> > > >
> > > > Two questions on the B210.
> > > >
> > > > 1. Generally speaking, are there are known issues transporting
> > > two RX 
> > > > channels at 61.44Msps over USB 3.0 on the B210. I know from a 
> > > > theoretical standpoint, the 5Gbps capacity of USB 3.0 has
> > > enough 
> > > > capacity to transport the dual-channel 16-bits i/q @ 61.44Msps.
> > > I also 
> > > > know that whether the host can keep up with this throughput
> > > depends on 
> > > > host configuration, load-balancing etc., but wanted to get a
> > > general 
> > > > sense of which bucket it falls under: a) i 
> > > > quite-typical-and-routine-scenario, b) 
> > > > possible-but-in-a-particular-context, or c) pushing-the-
> > > capabilities
> > > >
> > > > 2. Taking this thought a bit further - (our application needs
> > > 4 
> > > > channels), if we had a powerful dedicated host machine, how 
> > > > feasible/unrealistic is to to have a configuration where the
> > > host is 
> > > > connected to two B210, via separate USB 3.0s and ingesting 4
> > > channels 
> > > > worth of RX data at 61.44Msps. From a UHD driver standpoint, I
> > > am 
> > > > assuming this would just entail interfacing with two separate 
> > > > instances of streamers, but is there any pit-fall in the
> > > single 
> > > > host-to-two-B210 approach?
> > > >
> > > > Thanks,
> > > > Chintan
> > > >
> > > It's not a driver or host-beefiness issue with B210.  It's the
> > > way the 
> > > data clocks work on the AD9361 chip, and the interface to the
> > > FPGA.
> > > 
> > > There's simply no way to make the AD9361 chip move two channels
> > > of data 
> > > out of itself (or, into itself) at the maximum data rate.
> > > 
> > > 
> > > 
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co
> > > m
> > 
> > ___
> > 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] Can't change MTU on N310

2018-09-09 Thread Marcus Müller via USRP-users
Hi Mark,

eth0 is the management Gigabit management interface. As far as I know,
that won't support MTUs above 1500 – after all, it's only a management
interface, and not a high-rate data streaming interface.

You probably want to have the 8000 Byte MTU on sfp0 and sfp1; if I
remember correctly, however, systemd on the N310 sets that correctly by
default – can you check whether ifconfig doesn't already list sfp0 and
sfp1 as having a mtu of 8000?

Best regards,
Marcus


On Fri, 2018-09-07 at 10:21 -0700, Mark Wagner via USRP-users wrote:
> Hi,
> 
> Right now I'm trying to change the MTU on eth0 to be 8000 as
> suggested by the Hardware driver and USRP manual but I'm getting an
> error
> 
> I'll start my N310 with a 10Gbe connection, screen in as instructed,
> and type 
> 
> ifconfig eth0 mtu 8000
> 
> then get error message
> 
> eth0: Invalid MTU 8000 requested, hw max 1500
> 
> My understanding is that the N310 thinks it can't change the MTU past
> 1500, but this seems wrong. Has anyone else had this problem?
> 
> -Mark
> 
> ___
> 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] re-initialize multi usrp object

2018-08-31 Thread Marcus Müller via USRP-users
Hi Sanjoy,

> ubuntu 14.04

That is ancient, and Ubuntu's LTS isn't worth the "S" they have in its
name. Don't do this to yourself. Update to the recent LTS release,
18.04.

This is really more of a general UHD question than specific to GNU
Radio – you'll probably be better off discussing this on usrp-users (in
CC:, you need to sign up for that).

> If I use reset command, it gives error on the runtime. 
> 

Without you telling us what that error exactly is, it's going to be
hard to help you. Can you point me towards where you've found the
"reset command"?

Anyway, the multi_usrp class doesn't have a 'reset' method, but the
shared pointer does. Not quite sure what you want to achieve, so I'm
afraid that you'll have to tell us

* what exactly your code is supposed to do
* what it exactly does (and the error)
* how those differ, and optimally 
* a minimal full example that someone could compile and investigate.

The last step seems to be optional, but honestly, it's usually the most
helpful one, for yourself, because it requires you to think about what
exactly you need to do to trigger the unexpected behaviour and thus
gives you the ability to investigate yourself.

Best regards,

Marcus

On Fri, 2018-08-31 at 23:23 +0200, Sanjoy Basak wrote:
> 
> Hi All,
> I need to re-initialize multi usrp object in my (c++) application on
> the runtime. How should I reset the multi usrp object? 
> If I use reset command, it gives error on the runtime. 
> Could anyone tell me what is the correct way to re-initialize the
> multi usrp object?
> 
> uhd::usrp::multi_usrp::sptr usrp;
> string args="addr0=192.168.10.1,addr1=192.168.10.2";
> usrp = uhd::usrp::multi_usrp::make(args);
> uhd::usrp::subdev_spec_t subdev("A:0 B:0");
> 
> //receive and operate
> ...
> 
> //reinitialize usrp
> usrp.reset();
> string args="addr0=192.168.10.1,addr1=192.168.10.2";
> usrp=uhd::usrp::multi_usrp::make(args);
> uhd::usrp::subdev_spec_t subdev("A:0 B:0");
> 
> I am using usrp x310, ubuntu 14.04 and uhd 3.9 lts.
> 
> Best regards
> Sanjoy
> 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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


Re: [USRP-users] B205-mini GPIO

2018-08-30 Thread Marcus Müller via USRP-users
Hi Arun,

in the uhd/host/examples directory, you'll find gpio.cpp !

Note that you'll need to bitbang SPI that way from the host; that can
work, but it's going to be slow.

Alternatively, if you are familiar with FPGA development, implementing
another SPI host in the FPGA should be thoroughly possible. You'd then
need to find a smart way to talk to the SPI controller from the host,
which I'd say is the bigger challenge.

Honestly, if you just need *something* to talk SPI, getting an USB-to-
SPI adapter (of the popular FTDI variety, for example) is probably way,
way easier and faster. If you need timed execution of SPI transactions,
you could also combine the two: Use an easy-to-use SPI bridge or
microcontroller or … and just (de)assert the CS line of SPI using timed
commands and the standard GPIO.

From a bit of a long-time support perspective: 90% of people don't
actually need their GPIOs to talk full protocols; if your application
needs that, a minor adjustment to architecture is often easier.

Best regards,
Marcus
 
On Thu, 2018-08-30 at 18:43 +, Arun kumar Verma via USRP-users
wrote:
> Hi
> 
> We brought B205mini recently and we want to use three GPIO to control
> some external device which require SPI interface, in the schematics
> the header mentioned is J5 for GPIO while website USRP Hardware
> Driver and USRP Manual: USRP B2x0 Series is mentioning J6 as GPIO
> header. Can you please suggest some example source code for GPIO, so
> that we can incorporate in our software.
> 
> Arun Verma
> 
>USRP Hardware Driver and USRP Manual: USRP B2x0 Series   
> 
> ___
> 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] uhd_usrp_probe Daughterboard Manager (DBMGR) error.

2018-08-19 Thread Marcus Müller via USRP-users
Hi Bob,

I'm not ruling out we actually are dealing with a software bug here; I
remember that exact dict from somewhere else, but I can't find it
anymore :( We might cooperate to figure this one out, however!

Since this looks like a UHD built from git, we have a lot of options. 

first of all, try 

export UHD_LOG_LEVEL=0 ### 0 is the most verbose mode, "trace"
uhd_usrp_probe

if that doesn't give you a line like
"RFX tune: R=%d, BS=%d, P=%d, B=%d, A=%d, DIV2=%d"
we'll have to look deeper.

Run your source build's CMake step again with 

cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DUHD_LOG_MIN_LEVEL=0
  -your_OTHER_cmake_OPTIONS ..

build and install the new shiny UHD. You should be getting the above
debug line. My hypothesis is that P=0. Is that right?

Best regards,
Marcus

On Sat, 2018-08-18 at 18:16 -0700, Bob Conley via USRP-users wrote:
> I realize these are old USRP-1s with 2 RFX900 daughterboards (DBs)
> but I would like to keep them running and appreciate any help.  It
> may also point to more current issues as outlined below.
> 
> As in the following cases the uhd_usrp_probe command returns the
> correct DB ID but fails to return the name and operational parameters
> for the DB. See: transcript below.
> 
> If I replace the RFX900 with the BasicRX DB, as Riccardo did in the
> second thread below, the probe command returns the expected results
> with all parameters populated and the USRP functions perfectly.
> 
> As stated above, this error is similar to the apparently unresolved
> errors encountered in the January 2018 thread "[X300] UBX-40 v1
> compatibility issues." and the May 2017 "Daugther Board Manager Error
> - USRP2 - N210"
> see:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2018-Janu
> ary/055334.html
> and
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-May/
> 052779.html
> 
> I have a fresh install of the tool set on Ubuntu 16.04.3.
> conley@Ubuntu-16-4-3Dell:~/rfnoc$ uhd_config_info --version
> UHD 4.0.0.rfnoc-devel-702-geec24d7b
> 
> I also ran the uhd_images_downloader which included the usrp-1 code.
> The error is repeatable on other similarly configured USRP-1s and on
> another development PC.
> 
> Again, any help is greatly appreciated.
> 
> 
> Transcript
> _
> conley@Ubuntu-16-4-3Dell:~/workarea-uhd/uhd/host/utils$
> uhd_usrp_probe
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
> UHD_3.13.0.HEAD-0-g5b236772
> [INFO] [USRP1] Opening a USRP1 device...
> [INFO] [FX2] Loading FPGA image:
> /usr/local/share/uhd/images/usrp1_fpga.rbf...
> [INFO] [FX2] FPGA image loaded
> [INFO] [USRP1] Using FPGA clock rate of 64.00MHz...
> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable
> error in init.
> Loading the "unknown" daughterboard implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> LookupError: KeyError: key "0" not found in dict(i,
> N14adf4360_regs_t17prescaler_value_tE)
> [ERROR] [DBMGR] The daughterboard manager encountered a recoverable
> error in init.
> Loading the "unknown" daughterboard implementations to continue.
> The daughterboard cannot operate until this error is resolved.
> LookupError: KeyError: key "0" not found in dict(i,
> N14adf4360_regs_t17prescaler_value_tE)
>   _
>  /
> |   Device: USRP1 Device
> | _
> |/
> |   |   Mboard: USRP1
> |   |   serial: 4d76b228
> |   |   
> |   |   Time sources:  none
> |   |   Clock sources: internal
> |   |   Sensors: 
> |   | _
> |   |/
> |   |   |   RX DSP: 0
> |   |   |   
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX DSP: 1
> |   |   |   
> |   |   |   Freq range: -32.000 to 32.000 MHz
> |   | _
> |   |/
> |   |   |   RX Dboard: A
> |   |   |   ID: RFX900 (0x0025)
> |   |   | _
> |   |   |/
> |   |   |   |   RX Frontend: 0
> |   |   |   |   Name: Unknown (0x) - 0
> |   |   |   |   Antennas: 
> |   |   |   |   Sensors: 
> |   |   |   |   Freq range: 0.000 to 0.000 MHz
> |   |   |   |   Gain Elements: None
> |   |   |   |   Bandwidth range: 0.0 to 0.0 step 0.0 Hz
> |   |   |   |   Connection Type: IQ
> |   |   |   |   Uses LO offset: No
> |   |   | _
> |   |   |/
> |   |   |   |   RX Codec: A
> |   |   |   |   Name: ad9522
> |   |   |   |   Gain range pga: 0.0 to 20.0 step 1.0 dB
> |   | _
> |   |/
> |   |   |   RX Dboard: B
> |   |   |   ID: RFX900 (0x0025)
> |   |   | _
> |   |   

Re: [USRP-users] Update USRP E310

2018-07-20 Thread Marcus Müller via USRP-users
https://files.ettus.com/e3xx_images/README

On Fri, 2018-07-20 at 13:21 +0300, Ivan Zahartchuk via USRP-users
wrote:
> Hello tell me how to update the E310 to e3xx-release-4?
> 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] TDMA receiver on E310

2018-07-19 Thread Marcus Müller via USRP-users
Hi David,

so, NUM_SAMPS_AND_DONE sounds right for this application, and pre-
determining the time at when the observation will start with time_specs
sounds absolutely like what I'd recommend.

You say there's a "delay when leaving the recv function"; I'm not quite
sure I understand what you're referring to, here?

Recv() just takes the data coming in, takes it from the hardware
buffer, converts it to the number format you requested, and writes it
into the buffer you gave it, and repeats until the requested number of
items have been received (or some timeout or extranormal condition
happened). There's no delay that we added there!

Note that these calculations might actually take some time. Hence, it's
absolutely desirable to have two (or even more, but stick with two for
now) threads that just call recv() in endless loops – recv() is thread-
safe, and that way, you can already handle the next hardware buffer,
while the first is still being processed (subject to CPU limitations).

Best regards,
Marcus

On Thu, 2018-07-19 at 09:48 +0200, David Zamorano Fernández via USRP-
users wrote:
> Hi.
> 
> We have implemented a TDMA receiver on an E310. We have to receive
> slots of 40 ms duration and we must capture and process each of them.
> These capture instants must be very precise, so we have used GPS to
> discipline the internal clock of the E310.
> 
> What is the most appropriate stream mode for this task?
> 
> Currently, STREAM_MODE_START_CONTINUOUS is used but the first slot
> has too much delay when leaving the recv function (about 14 ms). It
> has also been tested with STREAM_MODE_NUM_SAMPS_AND_MORE, programming
> the next slot time_spec each time.
> 
> Thanks.
> --
> 
> 
>  
> 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
> 
>   
> 
> 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] GMSK Tx adn Rx of data

2018-07-05 Thread Marcus Müller via USRP-users
Hi Kevin,

"Packet Encoder" is buggy and therefore in the "deprecated" category in
 GNU Radio. It's no surprise it's not working! I mean, you even get a
warning about that in the console.

So, please adhere to one of the working examples we have that don't
rely on explicitly obsolete blocks. I'd recommend the examples in 
/usr/[local/]/share/gnuradio/examples/digital/packet, especially

packet_rx.grc, packet_tx.grc, (generate both), packet_loopback_hier.grc

as well as as soon you get the loopback in simulation to work, the
examples with "uhd" in their name.


Best regards,
Marcus

PS: while you're at it, don't use WX, but Qt. We (the GNU Radio
prokect) are kicking WX out of GNU Radio, because it hasn't been
maintained in years and we really wouldn't know how to. Also, its
performance is usually far worse than that of Qt.

On Thu, 2018-07-05 at 05:36 +0400, Kevin Grey via USRP-users wrote:
> I am new to this, and any help would be greatly appreciated.
> 
> I am trying to do the following:
> 
> Send text data from a USRP B210 to a HackRF, all done at 221 MHz,
> check the 2-minute video please:
> 
> https://www.youtube.com/watch?v=kZTo8-32mIg
> 
> As you can see, I am lost as to whether the signal is not received to
> begin with, or that the problem lies in storage of the data received.
> 
> Thank you for your replies,
> 
> Kevin
> ___
> 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 GRC Host Connectivity

2018-07-05 Thread Marcus Müller via USRP-users
Hi Walter,

allow me to quickly comment in-line:

On Thu, 2018-07-05 at 15:40 +1000, Walter Maguire via USRP-users wrote:
> Hi Derek,
> Thanks for getting back to me. 
> I had a look at the gr-ettus examples covering the X3XX series.  
> These all seem to use an embedded processor based UDP sink on the
> USRP side.

That's kind-of-true. So, yes, the FPGA image on the X3xx embeds a small
processor for all kind of housekeeping, and there's a protocol to speak
to it.
But no, it doesn't ever see the sample streams.
These are separated (based on UDP ports, actually) by hardware logic,
and directly streamed into the FPGA side of the streamer.

>I have not been able to locate a grc example where the RFNoC block
> to SFP stream exists such that the data can be sent directly to the
> SFPs without needing to pass via the PS or equivalent. 

So, that's the normal route of things:

1. UHD on the computer sends "control packets" (UHD protocol) to some
processing logic on the X3xx to set up everything, then
2. UHD uses CHDR and different ports to exchange sample packets
directly with the streamer fabric, which is not part of said processor
logic

> I suppose the GRC layer is somewhat abstracted from detailed
> transactions in the FPGA and associated embedded processing.   

Not that far. As said, UHD does two things, configuration and
streaming, and from a C++ perspective, there are UHD methods that
control every aspect but streaming, and then there's two methods
(recv() and send()) that actually stream data. 

The GNU Radio "USRP Sink", for example, just takes the configuration
you enter in the device properties, uses the former calls to set the
device up, and then uses the send() call to send the samples it got
through GNU Radio's sample processing logic to the FPGA as stream.

Now, how does RFNoC fit into this?

Well, implementation is that all these settings mentioned before are
effectively register writes; an RFNoC block, just like the UHD FPGA
Radio interface "entity" (which by now is also just an RFNoC block),
also has a streaming interface and can listen to a bus on which those
writes happen. What it then does with the knowledge of written
registers is up to the block: you can basically do anything within an
RFNoC block, and that includes having for example a fully blown
processor core in there – if you wanted to.

> Perhaps the UDP sink knows to use a SFP and sets up the DMAs on the
> RFNoC bus such that the SFPs are targeted directly via DMA.

I wouldn't call it DMA, but yes, the FPGA stock image comes with the
necessary logic to "talk" 10GigE, IP, UDP, and to tell ports apart and
map packet destinations to right RFNoC crossbar addresses.

>I can't tell at the GRC level of abstraction.  I see the following
> potential transport routes for sending RX samples from the RFNoC
> receiver over a SFP.
> 1. RFNoC (CE send) =>(DMA) => PS DDR memory, PS interrupted at end of
> DMA transfer, PS initiates DMA over SFP. // PS takes active part in
> DMA transactions.
> 2. RFNoC (CE Send)  =>(DMA) => PS DDR => (DMA chain (without PS
> intervention) => SFP //PS only used to setup the DMAs and Chains
> 3. RFNoC (CE Send) =>(DMA) => SFP  //PS only used to setup the DMAs
> and Chains
> Which one of the above or alternative is used?

3 is closest, but no DMA. 

> I am currently unclear as to how the SFP cores are targeted from
> within a GRC and how much processor intervention is required once the
> DMA transfers have been set up.  Does this operation need to be done
> using the UHD API instead of GRC?   Is there a SFP CE block?

The SFP interface is just "transport". Your CE doesn't need to know
anything about networking.
Technically: RFNoC crossbar sees packets, which contain addresses,
which tell the crossbar which packets to just route intra-FPGA to a
different block, or through the network interface into your computer
(where UHD picks them up). So, your CE just sets the right address.
Usually, you don't even care about that: UHD itself offers a "connect"
paradigm, where, if you're using the ettus-supplied verilog modules to
handle the packetization in your CE, you set a default destination in
all the packets you generate in your CE, meaning that all these packets
are sent to the endpoint you connect()ed to, be it another RFNoC block
on the same FPGA, or a streaming endpoint on your PC running UHD.

I'm not quite sure I'm helping you much here – feels a bit like y
ou're approaching RFNoC from "the harder side", and are working with
many hypotheses that need to be verified, to a "bottom-up"
understanding of the device. Maybe my email helped you get the "top-
down" perspective of things. 

Best regards,
Marcus

> Regards
> 
> 
> Walter
> 
>   
> 
> On 04/07/18 19:26, Derek Kozel wrote:
> > Hello Walter,
> > 
> > The N310's streaming architecture is much closer (nearly identical)
> > to the X310 for your use case of connecting it to a host computer.
> > It can stream full bandwidth of all channels out of the SFP+
> 

Re: [USRP-users] uhd latency test with b205mini

2018-07-04 Thread Marcus Müller via USRP-users
Hi Wael,

as someone who keeps processing samples during their days, I very much
second Neel's recommendation:
From a higher-up perspective, you're trying to do high-performance data
processing with low latency restrictions.

Using a slower-than-necessary bus is a bad position to start from, and
using a low-end computer with an expensive SDR very much is, too.
The same goes for a two-year-old OS with an outdated Linux kernel
(updating your Ubuntu to 18.04 would actually solve that problem for
free).

I can't of course guarantee that your latency requirements will be met
– but by at least trying what software you've already built on your
laptop on a faster computer, you could see whether a more modern CPU
and a more modern operating system help bring you forward.

I'd recommend this: Get a large current e.g. Ubuntu 18.04 *bootable USB
stick*, and set it up to have *persistent storage*. Install UHD on
that, and build your software on it, so that you can take that stick
and plug it into any PC, boot it, and try whether it runs better,
*without installing anything on that machine*.

Then, simply talk to colleagues with a better computer, and try it
there, or just walk to your computer store and be honest that you don't
know whether a faster PC helps you, but you'd like to try something to
learn whether or not you should be buying a new PC from them.  

Best regards,
Marcus

On Wed, 2018-07-04 at 08:23 -0700, Neel Pandeya via USRP-users wrote:
> Those values can be set through the device string on the command line
> with the "--args" option.
> 
> You would be better-served by using a more powerful laptop, one that
> uses USB 3.0, as your current laptop only supports USB 2.0.
> 
> --Neel Pandeya
> 
> 
> 
> On 4 July 2018 at 01:35, Wael Ali  wrote:
> > Thanks Neel,
> > 
> > I've already played with the following values:
> > 
> > recv_frame_size
> > num_recv_frames
> > send_frame_size
> > num_send_frames
> > 
> > in the /b200_impl.cpp file , but I still get the same number of
> > late packets in latency_test.
> > 
> > On Wed, Jul 4, 2018 at 6:57 AM Neel Pandeya  > > wrote:
> > > This system is an older low-power system. It's an Intel Core i5
> > > i5-2520M at 2.50 GHz, and is about six or seven years old.
> > > 
> > > You should definitely do some of the performance tuning steps,
> > > such as setting the R/W socket buffer sizes, and setting the CPU
> > > governors to "performance" mode, etc.
> > > 
> > > https://files.ettus.com/manual/page_transport.html#transport_udp_
> > > sockbufs
> > > 
> > > To reduce latency, I would suggest that you upgrade to a newer
> > > more-powerful laptop.
> > > 
> > > Also make sure that you are not seeing any underruns or overruns
> > > as your run any UHD programs. You should run "benchmark_rate" at
> > > the Tx and Rx sampling rates that your application requires to
> > > verify whether your system can reliably sustain those rates. The
> > > link below has some information about performance errors ("O",
> > > "U", "D", "S", "L").
> > > 
> > > https://files.ettus.com/manual/page_usrp_x3x0_config.html#x3x0cfg
> > > _hosthw_troubleshooting
> > > 
> > > --Neel Pandeya
> > > 
> > > 
> > > 
> > > 
> > > On 3 July 2018 at 20:14, Wael Ali  wrote:
> > > > Dear Marcus and Neel
> > > > I'm really appreciate your reply
> > > > I'm using Dell Latitude E6320, USB 2
> > > > the output of "sudu lshw -html" is attached
> > > > I didn't have any kind of tunning except of real-time
> > > > scheduling of the uhd
> > > > 
> > > > 
> > > > On Wed, Jul 4, 2018 at 2:28 AM Neel Pandeya  > > > .com> wrote:
> > > > > Your latency will be made up of the delay caused by the USB
> > > > > bus itself, which you can't do much about, and the processing
> > > > > delay in your host computer.
> > > > > 
> > > > > Have you profiled your application?
> > > > > 
> > > > > Have you done any performance tuning on your system (CPU
> > > > > governors, R/W socket buffer sizes, etc.)
> > > > > 
> > > > > What kind of hardware do you have? Could you attach the
> > > > > output of "sudo lshw -html"?
> > > > > 
> > > > > --Neel Pandeya
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > On 3 July 2018 at 14:57, Marcus D. Leech via USRP-users  > > > > -us...@lists.ettus.com> wrote:
> > > > > > On 07/03/2018 05:10 PM, Wael Ali via USRP-users wrote:
> > > > > > > Dear all, 
> > > > > > > please help me with this issue,
> > > > > > > 
> > > > > > > while I'm testing latency between uhd and b205mini with
> > > > > > > latency_test file provided with uhd examples gives me the
> > > > > > > following
> > > > > > > 
> > > > > > > Summary (test1)
> > > > > > > 
> > > > > > > Number of runs:   1000
> > > > > > > RTT value tested: 1 ms
> > > > > > > ACKs received:302/1000
> > > > > > > Underruns:0
> > > > > > > Late packets: 698
> > > > > > > Other errors: 0
> > > > > > > 
> > > > > > > Summary (test2)
> > > > > > > 
> > > > > > > Number of runs:   1000
> > > > > > > RTT value 

Re: [USRP-users] Transmitting 1 ms long packets every 1 ms with timestamp and SOB/EOB

2018-07-02 Thread Marcus Müller via USRP-users
I must admit it's been a while, but I remember building a system with
an RX/TX roundtrip time through the host of about 5ms using gigabit
ethernet and relatively small packets. 

What's your interface, what's the packet size you're using, and at
which sampling rate?

Also, how often do these burst happen? Maybe we're seeing a problem
getting control flow done fast enough.

Best regards,
Marcus

On Mon, 2018-07-02 at 21:55 +0200, Felipe Augusto Pereira de Figueiredo
wrote:
> Hi Marcus,
> 
> It is a x310 and we tried with different number of milliseconds in
> advance, we started with 2 ms in advance and went to 7 ms.
> 
> Thanks and Kind Regards,
> 
> Felipe
> 
> On Mon, Jul 2, 2018 at 9:48 PM, Marcus Müller  om> wrote:
> > Hi Felipe,
> > 
> > which USRP are we talking about?
> > and: how much in advance to the time of transmission do you send
> > your
> > packet to the USRP?
> > 
> > Best regards,
> > Marcus
> > 
> > On Mon, 2018-07-02 at 16:37 +0200, Felipe Augusto Pereira de
> > Figueiredo
> > via USRP-users wrote:
> > > Dear All,
> > > 
> > > I've got the following problem:
> > > 
> > > I transmit one 1 ms long packet at a specific time, lets say t0.
> > I
> > > also use SOB and EOB to delimit the packets.
> > > 
> > > What I want to do is to transmit the next 1 ms long packet at
> > t0+1ms,
> > > however, I'm seeing "L" being printed in the log, meaning the
> > packet
> > > is late.
> > > 
> > > To summarize, I have a scheduler that works for slots of 1 ms and
> > I
> > > would like to have the packets being transmitted in sequence when
> > I
> > > have then with timestamps 1 ms apart from each other.
> > > 
> > > Is it possible?
> > > 
> > > Thanks and Kind regards,
> > > 
> > > Felipe Augusto
> > > 
> > > 
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com
> > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.co
> > m
> 
> 

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


Re: [USRP-users] Transmitting 1 ms long packets every 1 ms with timestamp and SOB/EOB

2018-07-02 Thread Marcus Müller via USRP-users
Hi Felipe,

which USRP are we talking about?
and: how much in advance to the time of transmission do you send your
packet to the USRP?

Best regards,
Marcus

On Mon, 2018-07-02 at 16:37 +0200, Felipe Augusto Pereira de Figueiredo
via USRP-users wrote:
> Dear All,
> 
> I've got the following problem:
> 
> I transmit one 1 ms long packet at a specific time, lets say t0. I
> also use SOB and EOB to delimit the packets.
> 
> What I want to do is to transmit the next 1 ms long packet at t0+1ms,
> however, I'm seeing "L" being printed in the log, meaning the packet
> is late.
> 
> To summarize, I have a scheduler that works for slots of 1 ms and I
> would like to have the packets being transmitted in sequence when I
> have then with timestamps 1 ms apart from each other.
> 
> Is it possible?
> 
> Thanks and Kind regards,
> 
> Felipe Augusto
> 
> 
> ___
> 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


  1   2   3   >