Re: [USRP-users] Help with time synchronisation of two receiver boards in NI USRP 2954R

Hi Snehasish, That's a bit of an unusual requirement, as the 160 MHz of the UBX-160 daughterboard inside the USRP-2954R usually allows to capture both down- and uplink at once, with a single antenna and a single daughterboard. Anyway, when using a single USRP, the RX channels will inherently

Re: [USRP-users] C++ --> GRC(Socket PDU ---> QT Frequency GUI)

Hi Jack, PDUs are not just samples one after the other – they contain metadata. I can't really imagine what your flow graph looks like, so I'd be grateful for a screenshot (File->Screen Capture). Anyway, there'd be no obvious reason your UDP detour would make things faster – maybe the

Re: [USRP-users] N210 - pure (real) 50MHz sine output

Hi Alex, your application sounds cool :) So, amplitude stability over ten seconds isn't usually a design goal – how strong are these amplitude modulations? Also, I'd have a standard visualization that I'd usually share here: offset tuning $f_\text{RF}$ is the frequency of the actual

Re: [USRP-users] C++ --> GRC(Socket PDU ---> QT Frequency GUI)

be directly in control of my samples all > the way. > > Jack > > > > On Wed, Aug 2, 2017 at 10:45 PM, Marcus Müller via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > Hi Jack, > > PDUs are not j

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

Dear Konstantin, can you please rather copy and paste the text from the console than making screenshots? makes it easier to read, and research :) Anyway, in that debug output, there's nothing indicating that the problem is actually the USRP, and not e.g. a connection breakup by the virtualizer.

Re: [USRP-users] C++ --> GRC(Socket PDU ---> QT Frequency GUI)

>> The point of moving to C++ was that the flowgraph I /really/ want >> to use is just causing me huge problems - most notably that there >> are periods of a few seconds every now and again when the USRP >> drops a load of packets and then, after a while, the flow just

Re: [USRP-users] BasicTX daughterboard block diagram

Hi Ali, I'm a bit confused about the disconnect between your subject line and your question. The BasicTX is really just a transformer; see its schematic on https://files.ettus.com/schematics ; the schematic is so simple that we never cared to do a block diagram. The USRP1 (or: any device in

Re: [USRP-users] Uhd Python API rx and tx samples

Hi Ivan, I'm sorry, your question isn't very clear. You'll find all the documentation to the functions wrapped in python from our UHD manual on https://files.ettus.com/manual. Best regards, Marcus On 08/15/2017 08:49 PM, Ivan Zahartchuk via USRP-users wrote: > Hello.How to interrupt the

Re: [USRP-users] Half-Duplex Mode of X310

Hi John, what kind of switching do you mean? *Antenna switching:* that doesn't depend on the X310, but on the daughter board, since the microwave switch doing that resides on the individual daughterboards. Anyway, these times should be in the nanoseconds. You can use timed commands with UHD to

Re: [USRP-users] B210 - "GPS ANT" connector

Dear Luciano, you can buy[1] an add-on GPS receiver module for the B210, which you can plug into the board. Its purpose is being a GPS Discipline Oscillator (GPSDO), for special applications where you need that. The antenna for that GPSDO module would then be connected to the GPS ANT. If you

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

Oh! If that is the case, yes, please do make an example FG, and if you find the time, also open an issue on https://github.com/gnuradio/gnuradio/issues . Thanks! Marcus On 07/07/2017 07:19 PM, Anon Lister via USRP-users wrote: > FYI I've noticed a very similar issue, isolated it to non usrp >

Re: [USRP-users] Random errors while transmitting certain BPSK/QPSK types on x310s

Hi Michael, point is that having a magnitude too close to 1 can lead to problems in the FPGA side of DSP – not in GNU Radio. Best regards, Marcus On 07/07/2017 07:20 PM, Michael Carosino via USRP-users wrote: > Hi Marcus, > > you are correct, reducing the magnitude did seem to fix the issue.

Re: [USRP-users] Compatibility issues of UBX-160 with X310

Dear Karan, could you share the verbatim output of uhd_usrp_probe (including the very first line)? Best regards, Marcus On 07/11/2017 09:00 PM, Karan Suri via USRP-users wrote: > Hi > I recently got two UBX160 daughter boards to work in the ISM band of > 5.8 GHz. I am not able to detect

Re: [USRP-users] RFNoC Data Scaling and Representation

No, it doesn't show dBm. It shows "dB", relative to an arbitrary chosen digital full-scale value. Best regards, Marcus On 07/11/2017 01:26 AM, Muhammad, Siraj wrote: > > Thank you very much, Marcus! > > But your fosphor RFNoC block does show data in dBm. Can you please > explain how is that

Re: [USRP-users] Input power limit for B2x0 series

s that > an attenuator will not have a dramatic influence on the noise figure. > > To Dan and others: The LNA is a high linearity LNA which automatically > implies that it can generate a lot of power (about 1/4W); that's where > my concern comes from. > > Sivan > > > On

Re: [USRP-users] ERROR_CODE_BAD_PACKET

Sounds like the header might have not been adapted 100% correctly. Check whether your noc shell has the right fields set. Cheers, Marcus On 10 July 2017 7:03:57 PM GMT+02:00, Jason Matusiak via USRP-users wrote: >I am splitting one of my RFNoC blocks into two

Re: [USRP-users] USRP E310 TX sample rate limit

Dear Boris, that's defined by how much of your CPU is used by the TX flowgraph, and where you get your data from that you transmit. Generally, 2MHz should definitely work, if you just generate a constant data stream. Best regards, Marcus On 07/10/2017 11:38 AM, Boris Isakanov via USRP-users

Re: [USRP-users] N210 GPSDO cables

Dear Usman, pretty much anywhere. There's nothing special about these cables, and they are specified in the datasheet on the N2xx GPSDO product page on our website. The serial cable is straight, and the power cable reduces a typical 2.54mm-pitched 3 pin (only outer 2 used) to simple 2 pin. Best

Re: [USRP-users] Overflows (D) when receiving nsamps more than once

Hi Adrian, in your modified version, are you calling recv() repeatedly, or are you trying to get all the samples you want at once? Best regards, Marcus On 07/09/2017 02:34 AM, Pope, Adrian P via USRP-users wrote: > > Hello, > > > > I have several x310s equipped with TwinRxs, and I’m having

Re: [USRP-users] Input power limit for B2x0 series

Hi Sivan, to add to what Dan already said: You're right, the -15 dBm limit is a bit overzealous (though I really must stress it's better to be safe than sorry on that side). We're actually in the process of relaxing the limits we're stating for this; compare [1], where we already spec a maximum

Re: [USRP-users] Centos 6.5 with X310??

Hi Mark, Hi Martin, nope, to my experience, the hassle of setting up PyBOMBS' requirements and then hand-fixing the non-working PyBOMBS recipes on CentOS6.5 is not compensated by the trouble saved. This starts with ancient python on Centos6, continues with under-circumstances-non-SSL-capable

Re: [USRP-users] ֻC API questions

Hello Sivan Toledo, I'm sorry I'm a bit late to react, but: since UHD internally still uses Boost, I'm a little afraid that using the C API is not a good solution here Best regards, Marcus On 07/15/2017 12:46 PM, Sivan Toledo via USRP-users wrote: > I'm converting a CPP code from UHD 3.8.5 to

Re: [USRP-users] 答复: frequency shift of B210

Dear John, at this point my recommendation is: Describe your measurement setup in more detail, and verify it's useful for measuring the clock quality of the B210, and not the of your CC11xx system. In fact, from what you've described, I can't really say I understand how this measures the clock

Re: [USRP-users] gcc5 Error when Rebuilding File System

Dear Alexander, ah, thanks for the error report! Philip has a nice page on how he circumvents such problems: http://www.opensdr.com/posts/using-docker-for-openembedded-builds/ Basically, he uses a docker container to have a controlled version of his OS, and does the build within. Only thing

Re: [USRP-users] Disabling CORDIC

Dear Altug, yes, POLICY_MANUAL and dsp_freq = 0 will disable, and POLICY_NONE will inhibit any change (so if you've not tuned the DSP before, it will remain at 0). Note that I'm still far from convinced that solves any of your problems! Best regards, Marcus On 26.07.2017 13:08, altuğ kaya via

Re: [USRP-users] frequency shift of B210

Hi John, the CC1120 is a cheap transceiver for GFSK. Unless you've driven it with an oscillator that is way better than that of the B210, I don't really see how your measurement could imply any clock drift on the B210's side? Best regards, Marcus On 21.07.2017 10:41, john liu via USRP-users

Re: [USRP-users] Sampling ADC/DAC at a different sampling rate compared to the FPGA-host data rate

Hi Karan, what USRP model are we talking about? Best regards, Marcus On 20.07.2017 07:51, Karan Suri via USRP-users wrote: > Hello USRP Users > I was able to develop an *FPGA based loop back which directs the raw > ADC data to the DAC* . The TX transmits whatever it sees on the > receive

Re: [USRP-users] how to use both subdevices from x310 together

rx_multi_samples On 5 August 2017 10:27:42 PM GMT+02:00, Snehasish Kar via USRP-users wrote: >Hello > > >Is there any example to use the two subdevices of usrp x310 parallely >and stream data. > > >BR > >Snehasish -- Sent from my Android device with K-9 Mail.

Re: [USRP-users] Having Installation Recognition Of Ettus E310

Hello Konstantin, So, the most important difference to be made here is that while the B210 is used as a peripheral to a PC, the E310 includes the host computer itself. So, the signal processing software doing whatever you want to do has to run on the E310 itself. So, what you'd normally do is a

Re: [USRP-users] When ssh'ing Getting prompt for Password Issue

Dear Konstantin, > Could the issue be that the ehternet cable that is in the unit is not > a crossover cable. no, that is usually not the case. If you're getting as far as being asked for a password, your SSH client is connecting to /something/. So, we can rule low-level network out. Best

Re: [USRP-users] Dynamic range of DAC

Dear Anders, sorry for the late reply! > We would like to know what the dynamic range of the DAC is, so that we can > determine a maximum difference in power between several different signals. So, technically, the 12 bit DAC would make ca 12·3 dB dynamic range. But: the device is typically used

Re: [USRP-users] B210 MIMO, 4 Channel s

Hi Masoud, no, the B2xx series is not capable of being grouped in multi_usrps. Best regards, Marcus On 08/07/2017 04:56 PM, Masoud Naderpour via USRP-users wrote: > Hi, > Is it possible to boost the number of MIMO channels of B210 by adding > multiple USRP B210 devices to the same host? > > >

Re: [USRP-users] x310 with twin rx uhd_usrp probe issue

Hi Mark, the daughterboard EEPROMs are read and return 0x93 and 0x92 as type, and that's the type of the rev. B version of TwinRX. Support for that was added in 3.10.1 ! Best regards, Marcus On 08/18/2017 05:49 PM, Mark Koenig via USRP-users wrote: > > I am currently running CentOS 7.2, UHD

Re: [USRP-users] clock outputs to GPIO?

Hi Dan, what's the order of frequency of the clock you're trying to drive? Three thoughts: * I agree, for anything beyond let's say 1kHz (don't nail me on this), using timed commands from the host to control the exact GPIO transition would only work in theory, but not in practice,

Re: [USRP-users] clock outputs to GPIO?

o configure >> the counter and polarity. >> >> >> >> Dan >> >> >> >> *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On Behalf >> Of *Marcus Müller via USRP-users >> *Sent:* Thursday, August 17, 2017 7:40 AM >>

Re: [USRP-users] Testing with single B200

You'll need an antenna that works for exactly the band that you want to observe, but if you happen to have one, you can receive a known signal. For example, if you're in possession of a 900 MHz band antenna, you might look for 2G signals. If you have an antenna that works around 100 MHz, look for

Re: [USRP-users] Quad channel receiver operation of B210

A single B210 has exactly two hardware receive channels. So, I'm afraid that no software update ever will change that! Best regards, Marcus On 09/15/2017 02:41 PM, Sumit Kumar via USRP-users wrote: > Hi, > > Apology if this is a redundant question. > > With the latest UHD version, is it

Re: [USRP-users] Quad channel receiver operation of B210

the perception that all 4 ports can be used as RX at a time! > >On Fri, Sep 15, 2017 at 6:23 PM, Marcus Müller via USRP-users < >usrp-users@lists.ettus.com> wrote: > >> A single B210 has exactly two hardware receive channels. So, I'm >afraid >> that no software

Re: [USRP-users] rfnoc developemnt

phase shift == multiply with unit-circle complex number. I think you can work up from that realization! Best regards, Marcus On 09/18/2017 04:08 PM, Snehasish Kar via USRP-users wrote: > > Hello > > > I just need to perform a phase shift. Is there any alternate of rotator? > > > BR > >

Re: [USRP-users] TXRX_loopback_to_file problem with USRP N210 and MIMO

Dear Sarah, with 50 dB attenuation in place, you'll definitely want some gain! Best regards, Marcus On 09/18/2017 02:36 PM, Sarah Tran via USRP-users wrote: > > Hello! > > > > I am trying to use 2 N210's connected by a MIMO cable to execute the > uhd example program txrx_loopback_to_file.

Re: [USRP-users] Using X310/UBX Tx/Rx antenna for single channel pulsed radar

Hey Rob, so, it's probably the good ol' radar bandwidth conundrum: For good range resolution, you'd typically want high TX and RX bandwidth, but at least on TX, it feels kinda bad to stream a full 200MS/s to the USRP, just to be able to turn a sine wave on and off again within a few nanoseconds.

Re: [USRP-users] Simple device question

I'd actually recommend doing `uhd_usrp_probe --tree` and figure out which value you need from that. We don't actually guarantee the stability of the output of the plain-text uhd_usrp_probe. Best regards, Marcus On 09/13/2017 10:01 PM, Marcus D. Leech via USRP-users wrote: > > You could run

Re: [USRP-users] Support with setting usrp sampling rate to 150MSPS

Hi Snehasish, knowing the roll-off of the halfband filters in the USRP, this is rather surprising. So, my best guess is that there's might be a problem with your software, but I can't really assess that. Best regards, Marcus On 09/13/2017 12:41 PM, Snehasish Kar via USRP-users wrote: I have

Re: [USRP-users] Simple device question

ave noticed that IQ will stream from unpopulated daughtercard > slots... Is this expected? > > > In testing my app I have only 1 card per x310, yet I got 2x100 MSA > streams from a single device... > >> On September 13, 2017 at 4:55 PM Marcus Müller via USRP-users >> <

Re: [USRP-users] High CPU load on UHD driver and Ether ISR

Dear Kobayashi-san, You want to make sure the size of the network packets is as large as possible to reduce overhead; UHD will print out the information of how many bytes are in a single packet during initialization. You might need to tell Linux that it needs to use a larger MTU (8000B should

Re: [USRP-users] warning on UDP buffer size when using Python API

Dear Oz, what's the different numbers you get? Also note that it's actually easier for us to read when you just copy and paste the text instead of making a screenshot. Thanks! Best regards, Marcus On 09/21/2017 07:12 PM, Osvaldo Alcala (Ozzie) via USRP-users wrote: > > Hi, I’m running with

Re: [USRP-users] Using 2 Tx channels on B210 board

Hi Rini, you can use both TX chains with different signals, of course! In fact, you can't use them with the same signal at all; you'd need to send the same signal to the USRP twice if you wanted to have the same waveform on both channels. > This would mean creating two USRP devices on 2

Re: [USRP-users] rfnoc blocks has no id

Snehasish, you're far too unspecific. What does "using a RFNOC block" mean? Which block? Whose block is that? What's the block's ID, is it correctly set? Does it come with a working block control class? Does the block work in test benches? Best regards, Marcus On 09/19/2017 01:18 AM,

Re: [USRP-users] Audio Control loop testing

Hi Ben, that's the old multi-clock problem we've been talking about multiple times – it's hard to even define what the "correct" clock is, so you usually just settle on recovering the transmitter clock and, if you were doing this in hardware, would derive the audio DAC's clock from that. In a

Re: [USRP-users] Trouble Connecting to N210 in VMWare

Hi Tellrell, we should probably change the manual to say "If you're not using NetworkManager, do …". If you're actually using NetworkManager inside that VM (chances are high!), instead of trxing to "sudo ifconfig…", just set up your network interface to a static IP Address with the right subnet

Re: [USRP-users] uhd python transmition

Hi Ivan, since you send the first samples with a timestamp of one, this is not a good idea: On 02.10.2017 21:46, Ivan Zahartchuk via USRP-users wrote: > metadata.time_spec = lib.types.time_spec(0) That basically forces the next packet to have 0 timestamp, i.e. to be more than 1s too

Re: [USRP-users] cannot ping

domain, they will not behave as intended (i.e., as a > pair of wireless CPEs, such as Ubiquiti Nanostations, to give an > example). > > On Tue, Oct 3, 2017 at 8:59 AM Marcus Müller via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> >

Re: [USRP-users] Buffer overflow tips

Hi Andrew, Your English is extremely fine, don't apologize! 270 MS/s is really *a lot* of data. You'd need a very capable computer even when just handling that amount of data internally, but with USB-connected devices, you also get a lot of interrupt handling. That will put additional load on

Re: [USRP-users] Trouble Connecting to N210 in VMWare

n Sunday, October 8, 2017 11:38 AM, Marcus Müller via USRP-users > <usrp-users@lists.ettus.com> wrote: > > > Hi Tellrell, > we should probably change the manual to say "If you're not using > NetworkManager, do …". > If you're actually using NetworkManager inside th

Re: [USRP-users] B205 Mini Problem

Hi! No, sorry, no Virtualization experience with Virtual Box myself – but: May I assume you're running Windows as the Host on that Surface? I vaguely remember at least one case, where a windows USB host controller driver update helped solve a virtualization-related issue, where USB devices where

Re: [USRP-users] uhd python transmition

Dear Ivan, please understand that both my insight on what goes wrong as well as my capability to make your application work through emails is limited. Anyway, you already got a few hints that you did not respect. * Don't use multiprocessing.Process * Don't try to constantly reset the

Re: [USRP-users] B210 input power supply

Though I'd really like to point out that different power supplies react differently to varying load – if your power supply tends to overshoot on voltage on a load change, be a bit careful to not put a 20V spike on the input all too often. We've seen devices fail due to overstressed input caps,

Re: [USRP-users] Fast synthesis of SDR's FPGA

Hi Shoor, instead of doing the build with our Makefile system, you can[1] also generate a ISE project (.xise) that you can load in ISE, and build using ISE: make PROJECT_ONLY=1 {yourtarget} In my experience, if anything, this doesn't change the build times drastically, even for minor

Re: [USRP-users] Removing DC offset on USRP B200

Hi Oliver, haven't quite thought through an understanding of what you're currently doing, but: Since the FPGA image already comes with a convenient-to-use DUC – why not just produce a constant, and tune digitally to a non-zero frequency? That way, the CORDICs inside the duc_chain will simply

Re: [USRP-users] ADC + DAC Compare of N200 and B200

Hi Kevin, it gets even a bit more complicated: While the samples coming out of the ADS62P4 are pretty raw (though that thing can FIR filter things itself, but IIRC we don't do anything fancy there), the AD9361 does have a multistage DSP chain – so, the bitwidth coming out of the AD936x might not

Re: [USRP-users] Error using coder.internal.errorIf (line 8) The input signal must be complex.

Hi Nur Qalbi, with that info, we can't really infer what's wrong with your Matlab program. You'll have to give a more comprehensive error description, and that means you'll probably have to investigate some more on your own. Apologies, Marcus On 08.09.2017 04:07, nur qalbi via USRP-users

Re: [USRP-users] Porting from x86 to armv7 (Ettus E310) - performance issues

high >>>> rate dsp calculations to RFNoC. >>>> >>>> I've also had luck with volk_profile. It seems to help with some >>>> workloads. >>>> On Wed, Sep 6, 2017 at 16:53 Philip Balister via USRP-users < >>>> usrp-users@lists

Re: [USRP-users] B210 overflow

o reduce > data rate ? > > On Tue, Aug 29, 2017 at 11:02 AM, Marcus Müller via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > 20 MS/s is already 80 MB/s, which is 0.64 Gb/s. It's not that > little data to shuffle a

Re: [USRP-users] B210 overflow

m/manual/structuhd_1_1stream__args__t.html> > > > On 08/29/2017 08:08 PM, Vladimir Rytikov wrote: >> will it help to change data type from float to complex16 to >> reduce data rate ? >> >> On Tue, Aug 29, 2017 at 11:02 AM, Marcus Müller via USRP-

Re: [USRP-users] B210 overflow

20 MS/s is already 80 MB/s, which is 0.64 Gb/s. It's not that little data to shuffle around! So you already need a halfway decent USB3 setup to do that. Also, your computer mustn't be very slow. What is your computer, in fact? Best regards, Marcus On 08/29/2017 05:07 PM, Cho, Daniel J (332C)

Re: [USRP-users] Capturing GSM downlink and uplink signal with USRP B210

Dear Erik, in general: No, but in a specific Up/Downlink scenario, it might work. To explain: The B210 indeed has two RX chains, but they are both mixed with the *same* LO. That means that the spectrum you get can only be within the analog bandwidth around that LO at f_RF: spectral aspects

Re: [USRP-users] How to connect single USRP N200 with two PCs?

unable to transfer data from one application to the >> other using TCP module of Gnuradio. >> Any suggestion would be appreciable >> >> Regards: >> Muhammad Munir >> >> On Sat, Aug 26, 2017 at 5:12 PM, Marcus Müller via USRP-users >&g

Re: [USRP-users] Is it safe to plug in UBX-160 on USRP N200/N210 (for intentional aliasing)?

Safe, yes, I think so – none of us has ever tried, but the connector pinouts are compatible – but be double sure you actually want what you get; obviously, Ettus can't give their OK for a combination that we never characterized, so your mileage might vary. Don't forget that the aliasing will

Re: [USRP-users] Capturing GSM downlink and uplink signal with USRP B210

re just fine for GSM bands with the typical 45 MHz > shift between uplink and downlink. Just handling the amount of data > may be a problem :) > > > > Ralph. > > > > *From:*USRP-users [mailto:usrp-users-boun...@lists.ettus.com] *On > Behalf Of *Marcus Müller via

Re: [USRP-users] X310 print U

Hi Jong, this can have a lot of reasons, but among these: Without starting and stopping both sink and source at exactly the same time, this flowgraph won't do what you probably think it'll do – there will be a random delay offset around your 1 s of delay. Instead of having the delay block, you

[USRP-users] No-Host operation of N210 (was: Re: USRP-users Digest, Vol 85, Issue 4)

Dear Jithesh, the first sentence in the mail you responded to is > When replying, please edit your Subject line so it is more specific > than "Re: Contents of USRP-users digest..." So, it'll really help if you write an email with a specific subject. Anyway, yes, that would require a complete

Re: [USRP-users] Porting from x86 to armv7 (Ettus E310) - performance issues

Hi Mr Hamilton, So, what you'd want to optimize first depends on what needs the most optimization. Your x86 program might be a good place to start looking into what the bottleneck is. If you're running Linux on your x86, I can heartily recommend `perf`, which is a tool that lets you display live,

Re: [USRP-users] help with RFNoC Polyphase channelizer

Overflows happen on your PC, and that's the software that you write, so we can't tell you whether that software is going to be fast enough, and whether your PC is going to be fast enough! Generally, for rates around 100MS/s, modern workstations usually are fast enough for simple capture signal

Re: [USRP-users] Understanding FFT spectrum

Hi Steve, yes, nonlinearities in amplifiers would be my interpretation, too. But I'd suspect that these might be (also) happening on the RX side – what's your gain there? What's the attenuation? My further approach would be: 1. Get the CBX performance data from [1] 2. From that, read/estimate

Re: [USRP-users] Signal Processing Block with Control Port

Hi Hafiz, this is a GNU Radio question, and not directly related to USRPs. I'd recommend you address this to the discuss-gnuradio list, to which you can sign up on [1], instead. Best regards, Marcus [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio On 02.10.2017 08:39, Hafiz Hashim

Re: [USRP-users] max input power B200

Marcus is right, but: Also, what is to be clarified? 20 dBm (or 10 dBm) is way more than 0dBm, true, but when would you ever expect a receive antenna to generate 1V, if you're not standing right next to a massive broadcast transmitter, or radar transmitter, or put your WiFi antenna in a microwave

Re: [USRP-users] Frequency synching USRP B210

Hi Daniel, I'm a bit confused by your wording: you say you set the clock source to O/B GPSDO and unknown PPS; but PPS has nothing to do with the clock source, but with the timing source. Can you confirm that both the time source and the clock source are set to the GPSDO? Also, you say you see a

Re: [USRP-users] cannot ping

Sorry, I still don't understand – what circle are we talking about? On 03.10.2017 06:50, seah chong wrote: > sorry about that, the coverage networking is weak. IP Address PC A is > 192.168.10.1 netmask 255.255.255.0. what i means with Omnidirectional > is actually the communication between the

Re: [USRP-users] polyphase clock sync eats 100% cpu once it gets samples

Hi Vladimir, synchronization is usually among the most CPU-intense things a receiver does (only, if at all, contested by channel decoding for complex codes). So, the 100% CPU utilization don't sound totally unreasonable, depending on your system. That being said, I don't want to rule out bugs,

Re: [USRP-users] polyphase clock sync eats 100% cpu once it gets samples

s comparing to the vanila example - Clock/Time > sources - I changed to Default instead of O/B GPSDO. > > -- Vladimir > > On Tue, Oct 3, 2017 at 4:57 AM, Marcus Müller via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > &

Re: [USRP-users] Gnu radio compatibility

Yes, as said, you must use the library version that was used at build time. You can't just install a new UHD version and retroactively make your GNU Radio work with that! As implied, I think it would be wisest to uninstall your GNU Radio and all but exactly the UHD version you plan to use,

Re: [USRP-users] Gnu radio compatibility

Hello, Ah that explains it. It's not that GNU Radio isn't generally compatible with your version of UHD. It's just that as with every other library, you have to use the same version that was used to build the application at run time. So, if you plan to use a GNU Radio that you installed as a

Re: [USRP-users] ADC Overflow - B205i

Dear Mr. Eyerly, Indeed, the AD9361 has an overload indicator register. (Ad9361 manual ug-570, page 76) We don't directly expose that, but with modifications in our host/lib/usrp tree's ad9361_driver, you could expose that by publishing a register reader in the property_tree. Does that sound

Re: [USRP-users] pyuhd signal generating

Dear Ivan, Hm, I can't test this here because it's not a complete verifiable example, but: as far as I can see, this *should* be giving you two tones, one `15.0/2048*band` below, and one `30.0/2048*band` above your `freq`. Note that your USRP can't just use any sampling rate. From the address

Re: [USRP-users] How to connect single USRP N200 with two PCs?

Hi Kyeong, hi Cladio, dear Muhammad so, let me confirm a few things: 1. yes, a USRP can only be "owned" by one host at a time. 2. yes, a USRP N2xx has one complex ADC and one complex DAC. It usually makes no sense to "split" these. They're really just one channel of complex signal. Exceptions

Re: [USRP-users] Multiple X310 (NI-2943R) configuration issues

Hello Jens, so, let's talk a short bit about architecture: The X3x0 is a very FPGA-centric architecture. There's a CPU inside the FPGA image (the ZPU) that is used for all kinds of "housekeeping", basic setup and such. After the FPGA is configured from flash, that CPU starts running the

Re: [USRP-users] ADC Overflow - B205i

Hi Dominik, proper PC now, so more freedom: There's two ways. One is what the UG-570 points [2] points to, which configures specific outputs to output ADC state info, and then react (including offering a readout from the host) to these outputs through FPGA modifications (because these signals

Re: [USRP-users] UHD USRP device address specification

Sure, just use serial=xxx as device address. You can find out the serial numbers of your USRPs with uhd_find_devices. Note that the USRP is full duplex, so you don't even need two b200mini to simultaneously RX and TX. Best regards, Marcus On 5 October 2017 8:59:35 PM GMT+02:00, Duixian

Re: [USRP-users] Removing DC offset on USRP B200

Hi Oliver, even just considering the time it takes to synthesize a single image for the B200's FPGA, not counting time needed to learn where to put your Verilog: Avoid doing things in the FPGA as far as possible. The 20 minutes it costs to go through the first two or three chapters of the GNU

Re: [USRP-users] N210 Genarate OOK Signal With LFTX/RX

Hi! So, you'll need to be a little more specific than "it didn't work". How did you configure your random source? Did you use pulse shaping? There's quite a bit, even to an OOK transmitter, that one can vary and do right or wrong. With the info you're giving, I'm afraid it's impossible to help

Re: [USRP-users] interpretation of received signal

Hi Nirmala, On 22.10.2017 18:22, Nirmala Soundararajan via USRP-users wrote: > Hi Marcus, > > I have no idea why you said that but I certainly did not mean to > directly take the values that Marcus L mentioned and straight away add > it in my report!. Since I am just learning about SDR, I just

Re: [USRP-users] interpretation of received signal

Hi Nirmala, I'm confused, so what *calibrated measurement device* did you use to get "-80 dbm to -100 dbm"? As Marcus L has pointed out, the values you get from the USRP are *not* relative to a physical unit. Please simply don't think the plots that *any* software gives you have something to do

Re: [USRP-users] Bug about for E312

Dear Jon, that first link points to your own GMail account. We can't do anything with that, I'm afraid. Please find the email you're referring to, cite it directly, or link to it on http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/ Thank you! Marcus M On 20.10.2017 03:20, liu Jong

Re: [USRP-users] Unexpected sample drift with X300 and X310

Dear Kai, to answer your explicit question first: > I assume that the drifting effect is caused by lost or added samples > on the Tx side. > Are my assumptions about the expected behavior correct? unless you're seeing "U" on the console, no, that's not the case: there's no lost samples. If it

Re: [USRP-users] Removing DC offset on USRP B200

Hi Oliver, yep, GNU Radio is just discrete signals, just like in an FPGA – but with software buffers between software functions :) That especially means that this is all complex baseband – so, to represent 20 MHz (= 0.5 MHz · 40), i.e. -10 to +10 MHz, you just need a sample rate of 20 MS/s.

Re: [USRP-users] Trouble compiling UHD on windows

Hi Miguel, I'm definitely not an expert on windows software building, but "the libuhd environment" actually sounds like it is what you want to build. You probably shouldn't try to link your build of libuhd against our build. Best regards, Marcus On 14 May 2018 06:16:12 GMT+02:00, Miguel P via

Re: [USRP-users] UHD and process forking

Hi Keith, in principle, you could continue using the multi_usrp in **one** of the processes. The real problem stems from the question of who inherits the sockets (in the case of network USRPs), the USB handles, or kernel ring buffer handles. In the end, only one process might react to packets

Re: [USRP-users] blocking one of channel in multi usrp

Go Harfan, It is internally assumed that a streamer during its life time has a fixed number of streams. What sampling rate are we talking about? Is continuity for the other channels a concern? What is the time scale we're switching channels on an off? Best regards, Marcus On 16 May 2018

Re: [USRP-users] RFNoC and MicroBlaze

Hello Alice, I'm myself not aware of an existing project (maybe I just forget, though) which puts a microblaze into an rfnoc block, but: Why not? You can put anything that you can instantiate in verilog into a block; I'd presume you might want to add a bus-independent clock to drive your

Re: [USRP-users] Build E310_sg3.bit problem

Interesting! What's your Vivado version? On 20 May 2018 13:44:28 GMT+02:00, Artyom Asadchy wrote: >Hello, Marcus. >Yes. this is the unmodified image. I clone it from >https://github.com/EttusResearch/fpga, checkout to rfnoc-devel (in my >case >commit

  1   2   3   4   >