Re: [USRP-users] Rx streaming to alternate destination

Hi Rob, Often you can get around a complex solution with a little hack: I presume you want a "thin connection, lesser CPU" computer ("Smarts") to control the USRP, while you want a beefy machine ("Beef") to capture the stream. At least for the X310, it works to use a static route on Smarts

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

Hello Artjom, Is this the unmodified image? The error basically complains about too much logic to put on the FPGA, and that doesn't happen with our stock images. How are you building this? Best regards, Marcus On 19 May 2018 20:16:40 GMT+02:00, "Артем Асадчий via USRP-users"

Re: [USRP-users] USRP X310 Calibration error

Hi Kunal, How did you install UHD? is there a chance you've got conflicting uhd installations, or updated parts of your system since you've built UHD yourself (if you did that)? Best regards, Marcus On 17 May 2018 17:08:43 GMT+02:00, kunal sankhe via USRP-users

Re: [USRP-users] Clock rate of x310

Dear Ishai, only the 200 MHz clock rate is supported. 100 MHz is never supported; in LabVIEW configurations, 120 MHz might be the native rate, but it's not a rate that you can generally use. 184.32 MHz is no longer supported. May I ask what the reason for this inquiry is? Very often, flexible

Re: [USRP-users] Race Condition Issue?

Hi, this is really far-fetched, but I remember getting into trouble with Boost.asio when I was messing around with a different libc. Did you perhaps update Boost or your libc without relinking boost against the libc your system uses? Best regards, Marcus On Tue, 2018-05-22 at 08:17 -0600,

Re: [USRP-users] USRP to Spectrum Analyzer

Hi Yeo, On Tue, 2018-05-08 at 08:06 +, Yeo Jin Kuang Alvin (IA) via USRP- users wrote: > Hi all, > > Theoretically, in frequency domain, the spectrum for SQUARE wave > should be a SINC No. That's wrong. The spectrum of a periodic function, such as the square wave, must be discrete. In

Re: [USRP-users] how to know the number of losted samples when overflow occurs ?

Hi Matis, the time stamp of the first buffer after a disruption should indeed be accurate, and describe the time at the first sample in that packet. So, I'd say that, yes, you can use that to know how much you've lost. Thus, let me ask you why you came to the conclusion that it is false? Best

Re: [USRP-users] B210 GPSDO - stationary mode

Hi KF, Sorry, no, that's all we've got, aside from the Jackson Data brief. Best regards, Marcus Wed, 2018-05-23 at 12:26 +0200, kf via USRP-users wrote: > Hi > > I am currently using a GPSDO on a B210 board. The specific unit is > the > one listed on

Re: [USRP-users] Configuring FIR filters for b210

Hi Victor, the baseband filters are indeed real and thus symmetric in spectrum. Best regards, Marcus On Fri, 2018-04-20 at 11:47 +0300, Victor Petrescu via USRP-users wrote: > Hi all. > > I have a b210 device on which i want to make a transceiver. I managed > to replicate 15Mhz bandwidth, but

Re: [USRP-users] API C,USRP X300

Dear Joseph, sorry for missing your email! Now, this is a bit of a broad question: To make the C examples do what you want, you'd write appropriate C code. Now, I feel like you're really asking us how to get started with writing C code, but that might be an indication that you probably shouldn't

Re: [USRP-users] Transmit Latency Over N210

Dear Amirhosein! the time synchronization methods mentioned in http://files.ettus.com/manual/page_sync.html solve that: it doesn't matter when you put the data on Ethernet, the USRP will send it when the time set for transmission is reached. Best regards, Marcus On Tue, 2018-06-12 at 09:27

Re: [USRP-users] Reg: GNU_Radio_Help

Hello Siva, as this is a GNU Radio question, I don't think this is the perfect list to ask; the discuss-gnuradio list would be more appropriate. Anyway, please read the console output of your application: UHD will definitely inform you that 50 kHz isn't a possible sampling rate; so fix that

Re: [USRP-users] Using ZMQ

Hey Steve, so, how much sampling rate do you need? If this is a local network, directly using the USRP from Windows might just work. But: An X310 can generate significantly more data per second than fits through gigabit ethernet, so this can even theoretically only work if sampling rates are

Re: [USRP-users] UHD and process forking

Hello Keith, Sorry for the long silence - this problem really needed mulling over in my head, and then I postponed that... So, yes, I'd see why you want fine-tuned control over threading. Would modifying UHD be an option for you? I could imagine the following to be a viable approach: 1. in

Re: [USRP-users] IQ transmission using grc

ed IQ file and > creates the connection > and runs. > > How do I change this python code so that it can loop over all IQ > files in the folder, any example python code available ? > > Please help me in setting it up. > > -ben > > > From: USRP-users on behalf o

Re: [USRP-users] IQ transmission using grc

Hi ben, On Sat, 2018-03-24 at 05:32 +, Benny Alexandar wrote: > on USRP N210 is 100 MHz / 2 = 50 MHz. Is that correct ? > Can USRP sample at such high rates ? Yes. But it's impossible to fit 50 MS/s · 32 b/S through a 1 Gb/s link, so you need to reduce the sample depth to 8 b, so that a

Re: [USRP-users] Using ZMQ

Hi Steve, That's a pretty network-centric question! So, first of all, you need to make sure you can actually send IP packets from one computer to the other - that will require figuring out the public IP address of the server end of the connection, making sure the firewall on that computer

Re: [USRP-users] Using ZMQ

Hi Steve, > Do you know what is the max rate of data possible to send via xmlrcp > / zmq / dpu socket? Speed is mostly a function of your connection , not of the protocol, so there can't be a definite answer. I'd recommend just considering the overhead of any sensibly packaged piece of samples

Re: [USRP-users] USRP E312 stops transmission when disconnected from computer

I've heard the hip guys these days use tmux, but I've never gotten warm with it, myself. On Tue, 2018-05-29 at 21:07 -0400, Marcus D. Leech via USRP-users wrote: > On 05/29/2018 09:03 PM, Philip Balister wrote: > > > > Us young guys might also use the screen command to create a long > > running

Re: [USRP-users] Cannot Install SDK on 32-bit Linux Machine - Is there work Around?

Hi Konstanti, the most common reason for that is actually a typo in the file name or in the path; can you verifying the file is actually readable (i.e. ls -l /home/rfnoc/rfnoc_tutorial/share/uhd/imagesusrp_e310_fpga_RFNOC_sg3.bit displays read privileges)? Best regards, Marcus On Thu,

Re: [USRP-users] PDU Socket Configuration (was: PDU Socket Configuration)

Hi Steve, this is really a GNU Radio issue, not a USRP issue – so I'm cross- posting my reply here and there, and I'd ask you to sign up for the dis cuss-gnura...@gnu.org mailing list[1] and follow up there. To make this short: [1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio On Sun,

Re: [USRP-users] Bits per sampling and oversampling

As Ian explained, oversampling happens both in the radio IC AND in the FPGA. So yes, this already is the case. Whether or not all 16 bits of the on-the-wire format are significant depends solely on a) your signal and b) the ratio between the sampling rate on the bus between radio IC and FPGA

Re: [USRP-users] Synchronized frequency hopping

Yes, that's absolutely possible with one caveat: These commands end up in queues. So, you need to send them in correct order, or, for example, if you send the commands for 120, 160 , 140, then the the 160 command will block the queue and the 140 command will be executed directly after the 160

Re: [USRP-users] Complex signal representation?

Hi Hojoon, well, the point is that USRPs deal with *complex baseband*, so, of course, all the samples are complex :) Q1 So, yeah, this is all due to complex signal representation. To understand this, there's no way around understanding complex equivalent baseband, but don't fret, any

Re: [USRP-users] RFNoC On B210

Hi Peter, hm, I do agree, this sounds like it would be an absolutely reasonable thing to do on a X310; the B210's master clock rates are way significantly lower (especially in dual-RX mode), so my hope is that the overwhelmingness of having software DDC is gone (or you just don't care about it

Re: [USRP-users] USRP X310 Remote Configuration

Dear Fernaz, you can't cheat 10Gig bandwidth! If you time-share any medium, then it's bandwidth must be shared. Since ethernet is de facto a timesharing thing, anyway, no, this won't work: Since you need to push through all the data through a single 10GigE connection, your 10 gigabits per second

Re: [USRP-users] Streaming and storing signals of full BW of 2x UBX-160 cards to PC in file

Hi Tarik, I didn't try to continously stream to storage of dual-channel full-rate X3x0 recordings myself, but I do have some experience to share; hopefully it helps more than it scares. * Even NVMe SSDs aren't uniform in access latency and write speed. So, make sure your write rate is

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

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

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

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

Re: [USRP-users] New (soon) owner question (USB3 over Ethernet)

Ah! The situation is different then! Chances are that the same bandwidth will still fit through USB2, and since USB3 is backwards compatible: You don't even have a problem :) Just connect your B200 as you did your HackRF. Note that full-duplex might need more USB bandwidth than half, but I guess

Re: [USRP-users] How to define FIR RFnoc block with float taps

Dear Ishai, convert the taps to integers. This typically involves scaling with a power of two (pick one that would allow the matching signal to stay within numerical limits of your internal stream format) and rounding. No magic involved here :) Best regards, Marcus On Tue, 2018-05-01 at 14:31

Re: [USRP-users] New (soon) owner question (USB3 over Ethernet)

Hi Brian! It probably won't work great: since USB and ethernet are fundamentally different, the round-trip delay won't be of any fun, and I really don't see why you should spend your money on a network-connected USB3 hub (wasn't even aware something like that existed!) to couple a computer with

Re: [USRP-users] Time tagging in the FPGA

One time long ago, a friend of mine wrote a tool necessary to compensate for the TX / RX delay in USRP radar applications. What he basically did was test the delay of crosstalk. Best regards, Marcus On Sat, 2018-04-28 at 16:39 -0400, Marcus D. Leech via USRP-users wrote: > There's no example

Re: [USRP-users] [Discuss-gnuradio] Extra RF shielding?

Hi Bahkshi, just for understanding purposes: are the TX and the RX antenna on the _same_ USRP? Generally, I'd like to recommend you take this discussion to the usrp-users maling list (in CC:), because it's not really related to GNU Radio. Best regards, Marcus On 2017-10-26 07:45,

Re: [USRP-users] [X300] UBX-40 v1 compatibility issues.

Hi Steven, I don't see how the issue is resolved with the previous UHD version – the daughterboard still has ID 0x and isn't recognized. So, this is most likely a connection problem. Properly (but carefully) reseat the daughterboard, and make sure it's properly screwed into place. If that

Re: [USRP-users] DC USRP N210

Ha! That image looks very much like a copy of an image I did a couple of years ago to explain offset tuning :D Anyway, you're still not answering my core question. I can't help you if you don't do that, and since you're only repeating what you've already said, I'm afraid that means that we've

Re: [USRP-users] [Discuss-gnuradio] RuntimeError: fifo ctrl timed out looking for acks

Dear Bakshi, this error is from UHD, not GNU Radio; an appropriate mailing list would be usrp-users (in CC:). Please follow up *there* with information on which USRP you're using, what you're doing, and the full console output (not just the error). Best regards, Marcus On Tue, 2018-01-09 at

Re: [USRP-users] "Additional signa"l after a packet transmission

Hi! This might really be the fact that the amplifier takes some time to shut down. This, paired with the possibility of TX/RX crosstalk might be a contributing factor: That might actually change the DC offset on the receiving side, and trigger the step response of the DC offset cancellation

Re: [USRP-users] [Discuss-gnuradio] Connecting n210 via gigabit ethernet to usb3.0 connector to raspberry pi 3

Hi Brandon, As this isn't really a GNU Radio question, I'm including the usrp-users mailing list; if you could follow up there (you'll need to sign up first[1]), that would help us keep the lists clean :) So, there's a lot of things that might or might not be right here; I'm picking my "most

Re: [USRP-users] "Additional signa"l after a packet transmission

Hi Raphaël, not quite sure I get your problem, but this is rather hard to debug without knowing exactly what your transmitter does. For example, if you transmit something that isn't zero-mean, then the DC offset cancellation *in* the receiving end would start to cancel out. As that cancellation

Re: [USRP-users] Process IQ samples in real time using gnuradio

Hi Alejandro, so, if you want to process streams of data, Matlab alone really isn't the way to go, if you ask me. With simulink, you might put your matlab code into a processing block and stream your data through that. The SDRu toolbox that Mathworks offers has USRP support, so you wouldn't need

Re: [USRP-users] B200 USB high CPU usage

Hi Kasper, SIMD is fine and all, for sample processing in the end (for example, to convert the samples from on-the-wire format to something your CPU can calculate with), but it's really no "fix it all" for this kind of thing: Significant workload is handling the fact that your USB controller has

Re: [USRP-users] Control LO frequency by FPGA

Dear Xingjian, that won't be possible as is – the tuning happens in the AD9361, and the FPGA communicates with that over a serial link. There's timing accuracy requirements that we can't meet over that serial link, so that's why Ettus' AD936x-based device can't support timed commands on the

Re: [USRP-users] add more than 10 blocks in uhd_image_builder

Snehasish, no. Best regards, Marcus On Mon, 2018-02-12 at 11:03 +, Snehasish Kar via USRP-users wrote: > Hello > > Is it somehow possible to add more than 10 gnu-radio blocks in > uhd_image_builder. > > BR > Snehasish > > ___ > USRP-users

Re: [USRP-users] USING USRP Xseries as clock master

Hi Tarik, that REF out port is the 10 MHz clock, and you can choose the internal GPSDO as clock source[1]. Same goes for the PPS out port. Theoretically, you could "daisy-chain" your USRPs, but I wouldn't generally recommend that (we haven't characterized delay, and also, if you can, always avoid

Re: [USRP-users] I think my USRP2 is bricked, but how can I know for sure?

Hi Tim, You used the wrong device. Burn to the device as whole, not to a partition. Best regards, Marcus On Wed, 2018-01-31 at 11:39 -0700, Tim Sapio via USRP-users wrote: > Hello USRP-users, > > I have hit a snag uploading the images required to make my USRP2 > function. I will give a brief

Re: [USRP-users] Triggering between two transmitters

Hi Sumit, my first reaction would be to just merge the two flow graphs and do the collision in software – 100% isolated from changing environments and such. From a hardware perspective: you can use the PPS input on the B210 to set a synchronous time and then trigger transmitting on time stamps.

Re: [USRP-users] about extra hardware license in Matlab

Hi Evan, you simply install the USRP Hardware Support Package (as you did), and then you are displayed this license agreement which applies to you automatically. You are now able to use USRPs with Matlab! There's no further steps you need to take. Best regards, Marcus On Sat, 2018-02-24 at 17:39

Re: [USRP-users] Unable to load a custom FPGA image to USRP E312

Hi Jason, this just means that the loader can't even open the file you specified. It looks like you're missing the leading "/" of the absolute path you're specifying. Best regards, Marcus On Fri, 2018-02-23 at 13:46 -0500, Jason Meyer via USRP-users wrote: > Hi, > > I am trying to build a

Re: [USRP-users] "Additional signa"l after a packet transmission

Dear Raphael, > Don't you think that 40-60ms is a bit long fot the amplifier to shut down I didn't say it was the amplifier shutting down. I supposed it was the DC offset cancellation! Your recording is very interesting. I assume the "spike" you see happens exactly when you turn on the

Re: [USRP-users] "Additional signa"l after a packet transmission

Hi Raphael, don't think switching from GNU Radio to directly talking to UHD will change much – the GNU Radio USRP Sink is pretty much a thin wrapper around UHD. You might have already said that, but I can't find in this email chain: What's the daughterboards you're using in your TX USRP N210?

Re: [USRP-users] Get NMEA data from usrp in gnuradio

Yes: https://gnuradio.org/doc/doxygen/classgr_1_1uhd_1_1usrp__block.html#a41 9f5d60d9ca48d162c4001f79511c85 Compare the get_mboard_sensor method that's wrapping through GNU Radio SWIGging UHD's own method: https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a2d

Re: [USRP-users] USRP Timed command in GR (stream TX and command port RX) simulaneous

Hi Claude, there's only one FIFO per radio. "Tags" is a GNU Radio concept. GNU Radio's USRP blocks take these tags and messgaes, and issue UHD tune_request. So, yes, in the end, there's only one way to tune, and that goes through a FIFO. Best regards, Marcus On Thu, 2017-12-21 at 11:35

Re: [USRP-users] DC USRP N210

Hi Ivan, what's your sampling rate, what is the bandwidth of the signal you're interested in? Best regards, Marcus On Fri, 2017-12-22 at 14:10 +0200, Ivan Zahartchuk via USRP-users wrote: > > Hello. Please tell me how to remove the constant component in the > USRP N210 SBX. > I was recommended

Re: [USRP-users] USRP TwinRX Error UHD

Dear Alejandro, my guess is that you use an old version of UHD. Which version are you using? Best regards, Marcus On Thu, 2017-12-21 at 18:28 +0100, ALEJANDRO BLANCO PIZARRO via USRP- users wrote: > Dear community, > > I am trying to capture IQ samples with a USRP x310 with 2 twinRXs > using

Re: [USRP-users] General USRP Architecture question

Dear Jose, what Jeff says is right. As background info: the diagram you're referring to depicts a USRP2 or N2xx. The 40 MHz low pass filter is a *baseband filter*. It's part of one of the 40 MHz-bandwidth daughterboard (WBX,SBX,CBX). You could draw a vertical line between these filters and the

Re: [USRP-users] [X300] UBX-40 v1 compatibility issues.

U, marking that as a bug. It's a bit late here, can't test myself, but can you add "--slot A" to the command line arguments? Best regards, Marcus On Tue, 2018-01-02 at 14:45 -0800, Steven Chen wrote: > Hi Marcus, > > Running both of those commands returns this: > > linux; GNU C++ version

Re: [USRP-users] USRP Timed command in GR (stream TX and command port RX) simulaneous

Hi Claude, happy new year to you, too! So, indeed, this is a bit of a hard problem. So, which other commands are we referring to? The digital tuning happens within the DDC RFNoC block; there should be synchronicity. Generally, the fact that these FIFOs are strictly ordered, of very finite

Re: [USRP-users] [X300] UBX-40 v1 compatibility issues.

Hi Steven, to answer your question as quickly as possible: 1. Since 3.10.2 and your new version, a revision check was added to the source code (I just found out; the magic I did was running `git diff release_003_010_002_000..298a13 db_ubx.cpp` in the right directory). I preliminarily blame that.

Re: [USRP-users] Update USRP E310

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 >

Re: [USRP-users] TDMA receiver on E310

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

Re: [USRP-users] B205-mini GPIO

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

Re: [USRP-users] [Discuss-gnuradio] re-initialize multi usrp object

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

Re: [USRP-users] Can't change MTU on N310

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,

Re: [USRP-users] B210 two channel capacity

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: > >

Re: [USRP-users] GMSK Tx adn Rx of data

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

Re: [USRP-users] N3XX GRC Host Connectivity

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

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

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

Re: [USRP-users] How to change B210 10Mz from Output to Input?

Dear Sailor Jerry, I'm not sure I'm following here: The 10 MHz connector is hardware-wise connected only to inputs, not to anything that can output anything; compare the schematic[1] on page 1. So, I'm pretty certain your device can't be condigured to have the 10 MHz connector be an output for

Re: [USRP-users] Host synchronization within a continuous stream

Hi Yichao, Sorry, this is probably my fault. I apologize – I'm not quite sure how to help you most efficiently right now. I remember this being a relatively involved issue; just from reading your second-to-last email on this list, this becomes clear. I'm still a bit confused about the time

Re: [USRP-users] Help with uhd

Dear Shehasish, Marcus Leech already responded to your last mail. We can't help you without all your code, especially whatever sets up "args2954R". Best regards, Marcus M On Sat, 2018-03-17 at 06:22 +, Snehasish Kar via USRP-users wrote: > hello > > On trying to use an multi usrp shared

Re: [USRP-users] IQ transmission using grc

Hi ben, also, no USRP can directly deal with a sampling rate as low as 48 kHz – you'll first have to resample to a rate that your USRP can deal with. In case of the N210, these frequencies are integer fractions of 100 MHz i.e. 100 MHz / N, with the restriction that N be an integer 3 < n <= 128 ,

Re: [USRP-users] Help with uhd

Does the error also occur with a stock FPGA image? On Sun, 2018-03-18 at 16:19 +, Snehasish Kar wrote: > > does the error occur exactly in the "make" call, or in the > > get_device3 > > It occurs in the make. > > > call, or somewhere else? > > What is your UHD version? Are you running the

Re: [USRP-users] USRP E310 and its DC suppression

To expand on that: I might be overusing this figure but: If your b_sample is sufficiently smaller than the E310's maximum analog bandwidth (to be exact, smaller than half of 56 MHz, ie. smaller than 28 MHz, which it better be, because the storage nor network on the E310 really isn't up to working

Re: [USRP-users] USRP-users help needed

Hi Joseph, to avoid confusion, I'll directly comment within your text: On Thu, 2018-03-01 at 16:03 +, Stern, Joseph via USRP-users wrote: > I wanted to gain a general understanding of the process, > specific to our B200mini hardware, so my approach understandably > seems like the Y and not

Re: [USRP-users] Using pysdruhd

Hi Ivan, no, I haven't used pysdruhd myself, ever. But might I interest you in Ettus' own prerelease UHD Python API: https://kb.ettus.com/UHD_Python_API Best regards, Marcus On Sat, 2018-02-24 at 20:24 +0200, Ivan Zahartchuk via USRP-users wrote: > Hello. Prompt please, you used a package

Re: [USRP-users] B 200mini RX2 SMA

Dear Brad, wiggle-ability and subsequent change of properties point to a hardware defect. Can you please contact supp...@ettus.com with your device's serial number, if you have, your NI invoice number, and if possible, a closeup photo of the soldering or the plug, whatever seems wiggly? Thanks!

Re: [USRP-users] RFNoC On B210

To give an uplifting spin to all this: Now, also, although larger than the one on the B200, the B210's FPGA isn't really large unoccupied, so the amount of logic that you could even hypothetically put in there is limited. Why's that uplifiting? That FPGA was chosen for the board because there's

Re: [USRP-users] timed burst problem on B200

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

Re: [USRP-users] about boost::condition_variable

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

Re: [USRP-users] Messaging the DDC

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

Re: [USRP-users] B205 External Reference issue

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

Re: [USRP-users] Messaging the DDC

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

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

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

Re: [USRP-users] timed burst problem on B200

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

Re: [USRP-users] RFNoC Custom Filtering in Freq domain

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

Re: [USRP-users] weird sample values when receiving on b200

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

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

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

Re: [USRP-users] FPGA compatibility

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

Re: [USRP-users] timed burst problem on B200

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

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

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

Re: [USRP-users] How to transmit different signals simultaneously?

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

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

Re: [USRP-users] USRP E313 | WBFM Issues

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

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

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

Re: [USRP-users] PCIe driver frame size

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

Re: [USRP-users] DMA FIFO Resizing

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 >

Re: [USRP-users] DMA FIFO Resizing

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

Re: [USRP-users] B205 Mini gain Tables

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

Re: [USRP-users] Time synchronization between two USRPB210's

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

<    1   2   3   4   >