Re: [USRP-users] X310: is it possible to overcame 8000 frame size for ethernet?

Paolo, Thats a fundamental H/W limitation of the current FPGA design. Long story short, it would have been inefficient to support an MTU slightly larger than a 2^N size. It’s also a pretty conservative number in terms of a an MTU that works for 99% of Hosts and network gear. -Ian > On Aug 3,

Re: [USRP-users] B200-mini does not respond to fast frequency changes

David, Not a direct answer to your question but an idea for you to sidestep it. Setup your B200-mini to capture a big chuck of spectrum, say 56MHz, with the band center at 2022MHz. You are going to capture 56MHz of spectrum up front but only pass a 1MHZ sub-band of that at any one time to the

Re: [USRP-users] Ethernet over SFP+ in custom FPGA design (X3x0)

Christian, If memory serves me correctly the missing pages are due to that portion of the design using a proprietary NI ASIC that handles the PCIe interface and the flash storage of the FPGA config data. Since it handles config it would be reasonable to assume that circuit also supplies initial

Re: [USRP-users] Netgear 10GB switch XS728T

Kevin, Glad to hear you are up and running. Daisy chaining (aka stacking) switches is actually perfectly good practice. For you as an SDR user the only potential impact is potentially a latency increase…there’s one or two applications where that might be a factor. Report back if you ever get

Re: [USRP-users] Netgear 10GB switch XS728T

Kevin, I wouldn’t expend more effort at the moment on the dissector, the UDP ports and packet sizes pretty much tell you whats going on if you understand UHD. It may be that the dissector for the old UHD protocol was never complete/perfect. Interesting that it was the monitoring port that was

Re: [USRP-users] Netgear 10GB switch XS728T

Kevin, I glanced through Captures 0,1,2 and could see the general gist of where it all goes wrong, but it’s not really clear why. The dissector seems out of date, at least it isn’t decoding correctly but I can still follow it. Capture 0: Packets 2551 through 2606 are the actual sample data

Re: [USRP-users] Ethernet over SFP+ in custom FPGA design (X3x0)

Christian, CHDR packets are encapsulated in UDP/IP between Host and USRP. See the attachment. PHY+ MAC functionality live under the x300_sfpp_io_core. However these blocks do not encapsulate/decapsulate the network packets. All the ethernet/IP/UDP framing fields are added by chdr_eth_framer on

Re: [USRP-users] USRP2 schematic vs. FPGA source discrepancy

There’s a bit of history there. PHY_CLK was indeed originally connected to the FPGA. It wasn’t needed and so the S1 switch was added to that pin instead. That switch was never used and so the original signal name persists in the Verilog even though it connects to nothing. -Ian > On Nov 5,

Re: [USRP-users] UBX-160 with X310 communication issue

Mark, “Ping” (ICMP) is implemented using a micro-controller and (different) firmware in both the N210 and X310. It’s very much Control Plane functionality and not indicative of Data Plane performance (i.e radio data and control packets) which are handled very deterministically by different

Re: [USRP-users] USRP sample rate bound to signal bandwidth

As >> for reading from the file, I am just creating a small data set which gets >> loaded into memory and repeated. >> >> Thanks!! >> - >> Jacob Knoles >> >> >> >> On Wed, May 9, 2018 at 4:21 PM Ian Buckley via USRP-user

Re: [USRP-users] USRP sample rate bound to signal bandwidth

>> >>> >>> Ian, very interesting suggestion. I will have to give it a try. Thanks for >>> the input. And since I am doing all of the heavy processing prior to tx'ing >>> I don't image this change will create too great of a burden on the CPU. As >>> for

Re: [USRP-users] B200/ADI9361 - Influence of master clock rate on EVM

That’s strange, by default the analog filters should be being configured from the master_clock_rate to have optimal bandwidth for the master_clock_rate on the assumption your signal uses the bulk of that bandwidth. UHD version? > On May 19, 2018, at 2:37 AM, Sylvain Munaut via USRP-users >

Re: [USRP-users] N210 + WBX and X310 + TwinRXs sample alignment

This is purely speculative given how stale I am on X310…but could there be more than one device located to those IP addresses? I’d pull out Wireshark and see what MAC addresses’s I’m seeing on ping returns perhaps? > On May 25, 2018, at 12:36 PM, Marcus D. Leech via USRP-users >

Re: [USRP-users] B210 initial tickcount offset

There is a certain amount of (deterministic) latency incurred in the pipelining of H/W signals, both data and control. The tick count applied to the data will be accurate w.r.t the instant the data left the DDC and was packetized. -Ian > On May 23, 2018, at 2:26 AM, kf via USRP-users

Re: [USRP-users] Using X310 without RFNoC

Koen, Don’t feel bad….I designed the X310 Crossbar, and I had never heard the term RTR used until I read your email! So to summarize the RFNoC concept, (since I’m no longer involved with the current implementation): The “RTR” encompasses all the functionality that transports data between

Re: [USRP-users] IQ Calibration - CPU Performance Impact?

Dave, from what I remember the overhead will be incurred each time a (re)tune takes you to a different line of the IQ imbalance table…you can see the granularity of that from simply looking in the CSV file. The overhead is very minor I suspect, we are talking about updating two integer

Re: [USRP-users] two X310 synchronization

Dmitry , Yes that will cause you some pain. In this specific case the internal details of the X310 are important. The PPS is first sampled by a synchronizer (chain of registers) clocked with the REF_CLK. But then there is a secondary synchronizer to the DSP clock, which in the case of your

Re: [USRP-users] two X310 synchronization

Marcus, There is a potential ambiguity of one clock cycle (of the reference clock used to sample the PPS) if the PPS is generated from a different clock root as the phase of PPS w.r.t the REF_CLK slowly shifts. This is due to the possibility of a setup/hold violation at one or both of the

Re: [USRP-users] vita time

-users@lists.ettus.com> > Objet : Re: [USRP-users] vita time > > Hello Koen: > > As Ian requested, could you please provide additional detail on exactly what > you're trying to do? > > Are you merely trying to access the 64-bit FPGA VITA time from within the >

Re: [USRP-users] vita time

;> My block is a signal generator and each sample needs to be transmitted at an >> accurately known instant. The samples themselves do not need to hold this >> information. >> >> The device I am using is the X310. >> >> What Neel Pandeya is suggesting so

Re: [USRP-users] vita time

ng is the X310. > > What Neel Pandeya is suggesting sounds like exactly what I’m trying to do. > > Thank you for your responses. > > Regards, > > Koen Timmen > > > De : Neel Pandeya [mailto:neel.pand...@ettus.com > <mailto:to%3aneel.pand...@ettus.com

Re: [USRP-users] two X310 synchronization

arify source of FPGA_REFCLK_10MHz_p/n signals (pins AG24, AH24). I > have not found them in the schematic. Do they come from SY89547 or from > LMK04816? > > thanks, > Dmitry > > пн, 18 июн. 2018 г. в 22:27, Ian Buckley via USRP-users > mailto:usrp-users@lists.ettus.com>

Re: [USRP-users] N210 + WBX and X310 + TwinRXs sample alignment

Those N210 settings are broken also…bad subnet and gateway > On May 30, 2018, at 9:26 AM, Marcus D. Leech via USRP-users > wrote: > > On 05/30/2018 12:22 PM, Steve Gough via USRP-users wrote: >> Hi Neel and USRP mailing list, >> >> The uhd_usrp_probe returns as follows: >> >> For the N210

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

Miguel, By default UHD will always move samples to/from the B200 over USB in the so called SC16 format, which is a fixed point point representation with 1 sign bit and 15 fractional bits (-1<=x<1). You can also use SC12 and SC8, which have respectively 1 sign bit and 11/7 fractional bits if you

Re: [USRP-users] RFNoC On B210

Er no. B200 has approximately the same number of FPGA logic gates as E310, B210 twice that amount. The current design is simply larger than it needs to be because it shares all it’s code with X300, I could have made it much smaller had there been a good reason to. The FPGA was simply

Re: [USRP-users] Synchronizing multiple B205 mini radios

-sync>). > Theoretically, if one is able to rework the B205mini so that the sync_in pin > goes to the FPGA (not practical I know), I assume there will be a similar > routine needed for ad9364_multichip_sync. > > Thanks again for your continued guidance. > > Chintan >

Re: [USRP-users] SC8 Wireformat

On a USRP2 thats a harmonic of the on-board 100MHz clock. One excellent way to deduce when you are dealing with a spur thats LO related is to use offset tuning to move the LO relative to the center of your band of interest. See: https://files.ettus.com/manual/structuhd_1_1tune__request__t.html

Re: [USRP-users] Synchronizing multiple B205 mini radios

Robin, that ADI support thread is not applicable to B2x0, it’s for AD9361 external LO mode which isn’t used by Ettus products. In internal LO mode there is always a phase ambiguity in the RF synthesizers that requires higher level S/W to calibrate and correct for. The baseband synthesizer can

Re: [USRP-users] B200 clocking - Minimum master_clock_rate and DCM ?

That’s a little bit strange Silvain, I wonder if there has been a UHD regression. I eliminated the 5MHz limit in UHD when I did away with the DCM in 2015, and I don’t recall any gotcha’s that might bite you though you end up running the DSP at a crazy low clock frequency which has a knock on

Re: [USRP-users] B210 dual channel operation with length tag in GNU Radio

Felix,Are you adding an explicit “tx_time” tag( with associated identical time tuple value) in both streams at the same offset as the TSB tag you are adding?I don’t think you can safely assume the TSB tag (Which causes bursting behavior in the USRP, equivalent to the use of the sob/eob) tags will

Re: [USRP-users] B210 FPGA Code

Yeo Jin Kuang Alvin, In reply to your original question the data passing over the GPIF interface is packetized data; It contains sample data and control/status data with protocol overhead. It is 32bits due to the design constraints of the FX3. It is transformed to 64bits in the FPGA for maximum

Re: [USRP-users] B210 dual channel operation with length tag in GNU Radio

Felix, So I threw a couple of stream-to-tagged-stream blocks in that test flow graph to see if I could see what you see. And it does replicate the behavior you report though I see a time offset that seems to range from approx 24 to 29uS with no obvious linkage between that value and any

Re: [USRP-users] USRP B210

Making a hardware DDS to generate a chirp in the FPGA is easy, extremely so if you reuse the Ettus code that interfaces the B210 to AD3961 with correct timing. What is very hard in what you propose, is controlling the AD9361 from within the FPGA without an external host. There is a *lot* of

Re: [USRP-users] Assistance In Stopping Python Script After Removing Ethernet Connection

> On Apr 3, 2018, at 10:24 PM, Matheou, Konstantin J. (GRC-LCI0)[ZIN > TECHNOLOGIES INC] via USRP-users wrote: > > Thanks Marcus… > > Actually, this is what I am looking into currently. > > Unfortunately, I get the PID, but when I reconnect and go to terminal,

Re: [USRP-users] RFNoC On B210

There is no conceptual reason why you can’t build an RFNoC design on B210, it uses the same USRP3 base architecture and FPGA source files….*HOWEVER*…. B210 is implemented with a Spartan6 FPGA and all the implementation work for RFNoC is done using Xilinx’s Vivado design tools which support only

Re: [USRP-users] USRP 200 Square with Carrier Frequency Behaviour?

GB, What you are seeing I think is the Square wave generated in quadrature as a complex signal….imagine 2 square waves with pi/4 phase offset. Also I think you will find the square wave is [0,1] not [-1,1]. So when your modulated square waves are summed…you get what you see. Build it for your

Re: [USRP-users] Cordic Algorithm quadrant selection

In brief, (since the CORDIC algorithm is a simple and fun one to simulate standalone and look at the functions generated as analog waveforms) The zi input (fed from the DDC/DUC phase accumulator) represents an angle as a fraction of 2*Pi. The symmetry of the sin/cos functions is exploited so

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

> > 1) When each B210 syncs, the 1PPS pulse between each USRP would be aligned to > +-50 nsec. Since they're only separated by a few km, I suspect the alignment > might be better because of common errors (Ionosphere, orbits, clocks, etc) in > the GPS solution I think you will find that

Re: [USRP-users] Hello,

Brais, Sam sent you a little bit the wrong direction there, the B200mini has the PLL phase noise issue that precludes use in a MIMO system. The B210 can be fully time and frequency locked to an external 10MHz reference and PPS. What is slightly tricky about using multiple B210’s in a MIMO

Re: [USRP-users] Hello,

N310 has a different ADI radio chip and since I did not work on the design I don’t want to give you misleading advice on that one. N210 is different, as it uses the standard Ettus interchangeable daughter board standard. Some daughterboards have features to fully phase align synthesizers after

Re: [USRP-users] Questions regarding BasicTX Daughterboard

Hua, Yes to both questions. If you drive a constant DC amplitude into a USRP sink in GR then you can observe the frequency and phase of the FPGA “digital LO” on an oscilloscope easily. -ian > On Nov 16, 2018, at 9:40 PM, Huacheng Zeng via USRP-users > wrote: > > Dear All: > > I have some

Re: [USRP-users] X310 Dual 10 Gb/s Link Detection Issue

Dave, I might be miss-reading what you are telling me here but…..are you saying that an “HG” image brought up both ports over a 10G Twinax passive cable to the X710, but not the “XG” image? Is it possible either you or someone at Ettus has got HG and XG switched in the latest release? Can you

Re: [USRP-users] X310 Dual 10 Gb/s Link Detection Issue

Dave, I can’t speak to anything that might be happening because of recent code changes, but I would recommend you doing a quick switch of the cables/ports to see if the problem follows the cable/SFP/Port jut in case it’s a coincidence that you did the firmware update at that time. I’ve had

Re: [USRP-users] regrading GPIO header connector in USRP-B200 mini

Maitry, I think you have a fundamental misunderstanding here, and to be fair, it is largely because the term SDR is being used carelessly everywhere these days. The SDR is GNURadio, not the USRP. There is a limited amount of Hardware implemented DSP inside the USRP (B200mini) and analog RF

Re: [USRP-users] Unexpected spurious from N200

Correct, move the LO greater than 20MHz away from 0Hz to suppress the LO via the LPF on SBX/WBX. > On Jan 3, 2019, at 7:27 AM, Milos Milosavljevic > wrote: > > Thank you Ian. > > Apologies, we are using the SBX not WBX (that was a typo from my side). I > believe that SBX also has TX

Re: [USRP-users] Unexpected spurious from N200

Milos, Early AM for me….disregard what I just said…had a pre-coffee moment…LO not present in signal chain at that point…doh! > On Jan 3, 2019, at 7:27 AM, Milos Milosavljevic > wrote: > > Thank you Ian. > > Apologies, we are using the SBX not WBX (that was a typo from my side). I > believe

Re: [USRP-users] Unexpected spurious from N200

Milos, FWIW WBX includes TX baseband filters of 40MHz bandwidth. LO offsetting your LO spur’s into those should suppress this. -Ian > On Jan 3, 2019, at 3:48 AM, Milos Milosavljevic via USRP-users > wrote: > > Thank you Marcus. Much appreciated. > > I think I do understand why would I see

Re: [USRP-users] Standalone signal generator on B205mini

To activate TX streaming in the radio without modifying UHD you are going to have to supply some type of TX sample stream to the USRP. It can be at pretty much any rate and can be completely discarded after it’s depacketized and the corresponding ACK’s returned to the Host. The rate it’s sent

Re: [USRP-users] Standalone signal generator on B205mini

I can’t give you a specific solution Diego because there are a lot of things here that *could* be the issue. However in general my tips for hacking fast custom B2xx FPGA images are: 1) Do it in such a way that UHD can not tell you changed the FPGA. i.e All register transactions should work as

Re: [USRP-users] Hardware clocks, X310

Cherif, 1) Changing the radio clock frequency is not simple and would leave you an immense amount of knock on problems to address. 2) ADC and DAC are tightly coupled to the radio clk, they run on low jitter versions of the same clock. 3) Absolutely, and that is the beauty of streaming style

Re: [USRP-users] [Discuss-gnuradio] continous Tx voice transmission

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. > On Mar 6,

Re: [USRP-users] Phase after Freq Hopping

> On Mar 12, 2019, at 3:05 PM, Marcus D. Leech via USRP-users > 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

Re: [USRP-users] The problem with setting the frequency of USRP B 210.

Ivan, When the AD9361 is retuned, recalibration of various RF circuits may (need to) reoccur. The device driver looks how far you have retuned from a previous frequency, and if it exceeds a certain distance rerun’s this calibration, which takes time. Since Analog devices envisaged that this

Re: [USRP-users] [Discuss-gnuradio] continous Tx voice transmission

Brian, I think your idea does work. I think the tricky bit to doing this really well is having a control loop that reacts quickly enough that we don’t have to be stuck with a giant buffer that adds undesirable latency, but then conversely a control loop that adapts at a slow enough rate and

Re: [USRP-users] B210 bypass Tx FIR filter

Yeah, the driver tries to keep the DAC clock close to it’s max legal frequency with the highest possible interpolation ratio from master_clock_rate. That code doesn’t have any API access but I can show Sean how to hack it into UHD if necessary. > On Apr 10, 2019, at 10:57 PM, Julian Arnold via

Re: [USRP-users] Need a little help with running legacy prebuilt UHD versions

Joe, So I scratched my head about this a little late last night and looked back through the development repository for the N210 and as far as I can tell there was never customer facing FPGA code for a Rev2 N210. Chatting with Matt this morning he shared my feeling that a Rev2 wasn't sold to

Re: [USRP-users] what is the difference between UBX and UBX REVC

Did you look at the schematics? The change block indicates that they had to replace one (of the many…) parts that Avago has made end-of-life. So new LNA, upgraded T/R switch it seems. https://files.ettus.com/schematics/ubx/ubx_revC.pdf > On

Re: [USRP-users] get_time_now() blocking?

Fabian, It probably helps to try to understand the hardware a little, and then the way that timed commands operate will be a little bit more intuitive. Only certain parts of the actual USRP have access to accurate time (Those parts running on the so called “Radio clock” which is an integer

Re: [USRP-users] Time synchronization of multiple B210s not working with multiple channels

This is a particularly curious problem. The offset between B210’s of the “time after run” values after sample capture has completed is very hard to explain…certainly from a hardware only perspective. What are the absolute time values reported? Are they at least approximately 5-6 seconds as you

Re: [USRP-users] X310 broadcasting ICMP - information request

Old thread but for the sake of a knowledge archive: The ICMP IR traffic is the X310 Link state routing table updates…it’s unique to the X310, not present in the N210 And I also, only tonight, observed other X310 firmware driven network services running at ~3x the interval I expected Marcus…so

Re: [USRP-users] X310 broadcasting ICMP - information request

Marcus, I don’t think any action is required at present, it’s been working “fine" for many years. But as you say the firmware as written thinks things are working on a different timescale. Luckily their is nothing real time or timing critical in there -Ian > On Mar 24, 2020, at 6:56 AM, Marcus