[USRP-users] [RFNoC] Listen Before Talking (LBT)

Dear All, I'm thinking of implementing LBT with RFNoC, however, after an initial study of the RFNoC framework I realized it would be hard to implement what I had in mind: Initially, I would start with a very basic approach: 1) Calculate the power received just after the DDC for every received pac

Re: [USRP-users] Advise on how to modifying HDL design E310 to add custom blocks

Hello Brais, The HDL design does have a top block and is composed of usefully divided sub blocks. It is not however designed using the graphical Vivado workflow, but a source based one. Here is the top block: https://github.com/EttusResearch/fpga/blob/maint/usrp3/top/e300/e310.v Your application

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

Hi, I am trying to run an example from GNU Radio - examples/digital/packet/uhd_packet_rx and uhd_packet_tx with real USPR radios connected via an attenuator and a coax cable. When I enable receiver by clicking on 'On' check box - the whole RX flow graph freezes. I think I manually adjusted transm

Re: [USRP-users] uhd_usrp message return and Comms issues

Hello Mark, It has been some time since I have looked at the probe routine in the 3.8 version of UHD, but it sounds like the discovery packets are having routing problems. Do you have an N210, N200, or USRP2 anywhere on the network? We can probably give some assistance to discovering the root cau

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

Hello, The requested sizes do change a little during the initialization. Also the settings are not persistent across reboots of your host computer so need to be re-appled each time you restart or changes made to other configuration files to make them persistent. Can you confirm which sizes you ar

Re: [USRP-users] uhd_usrp message return and Comms issues

Hi Derek, I have recently upgraded to UHD rev 003.009.000 and have everything up and running on Centos 6.5. I am currently working on migrating to Centos 7.2 and hope to be there in the next couple of days. I am still seeing the retuning issues with the x310, unlike with the N210. What would

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, bu

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 US

Re: [USRP-users] uhd_usrp message return and Comms issues

Hi Mark, I'm glad to hear you were able to update to 3.9. Retuning the UBX takes approximately 500 usec. This varies based on how far the internal VCO needs to tune and if there is a band crossing. A dwell time of 5 seconds (5,000 msec) should be four orders of magnitude more than is needed to ge

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

Marcus, cpu: Intel Core i7-7820HQ (Quad Core 2.90GHz, 3.90GHz Turbo, 8MB) chipset: Intel Mobile CM238 RAM: 32GB (2x16GB) 2400MHz DDR4 OS: ubuntu 16.04 TLS almost no other software running - only GNU Radio. htop shows digital/packet/uhd_packet_rx.py takes ~192 % CPU. header_payload2 - ~100% pfb_cl

Re: [USRP-users] cannot ping

Seah, are you saying that you're trying to get a wireless link working between both USRP devices? If that is the case, and you are not implementing a full protocol and handshaking between them in the RF domain, they will not behave as intended (i.e., as a pair of wireless CPEs, such as Ubiquiti Nan

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

That's very interesting, indeed! If I had to infer (sorry, not right now on a computer where I can test) from the thread name "header_payload2", I'd say that for some reason that I don't know, the header/payload demuxer in packet_rx "spins" on something. If you want to, throw some more runtime ana

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

Will try it. Thank you! O From: Derek Kozel [mailto:derek.ko...@ettus.com] Sent: Tuesday, October 03, 2017 4:48 AM To: Osvaldo Alcala (Ozzie) Cc: Andrej Rode ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] warning on UDP buffer size when using Python API Hello, The requested sizes do cha

[USRP-users] 10 MHz reference signal on B210

I'm testing the behavior of B210-based systems, comparing the performance with "internal" and "external" (10 MHz) clock source. Expect for the following "is the 10 MHz input actually present" check running when the app starts, the two branches share the same code. rfBoardPtr->set_clock_source( "ex

Re: [USRP-users] 10 MHz reference signal on B210

You'd have to look at the detailed specs of the ADF4001 PLL chip that is used to steer the VCTCXO. That chip doesn't, as far as I know, have a "reference quality metric" output, and if it does, UHD doesn't expose it. On 2017-10-03 11:44, Dario Fertonani via USRP-users wrote: > I'm testing the

Re: [USRP-users] Advise on how to modifying HDL design E310 to add custom blocks

Thank you Derek, I was playing around with E300 design, but we actually need to use B2X0 devices, apparently not supported by RFNoC. Also we need to implement some complex decimation and filtering so that FIR block will not be enough. I guess, if I'm not mistaken, our only choice is to use Xilinx

Re: [USRP-users] 10 MHz reference signal on B210

Dario, 10 MHz signal input is meat to be freq reference. If a radio could tell that 10 MHz is not 10 MHz - there was no need to feed it externally. USRP boards seem have +/1ppm freq stability. 1ppm means when you tell radio to tune to 100 MHz - it might end up giving you 100 MHz + 100 Hz or might

Re: [USRP-users] 10 MHz reference signal on B210

I'd like to assume that *OctoClock-G*'s 10 MHz output is good to use as 10 MHz input on B210 (and other) USRP boards, given who the vendor of OctoClock-G is. If this is a bad assumption, please correct me. if this is a good assumption, then I'll use the OctoClock-G specs

[USRP-users] Error creating RFNoC FPGA image with OOT module

We are currently getting an error attempting to build a fpga image when running the following which points to the OOT module using the -I option ./uhd_image_builder.py twochannelsiggen duc fft -I /home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/rfnoc/fpga-src/ -d x310 -t X310_RFNOC_H

Re: [USRP-users] Error creating RFNoC FPGA image with OOT module

Hello Jose, please try running the following: $ ./uhd_image_builder.py twochannelsiggen duc fft *-I /home/joseavila/Documents/gnuradio_source/rfnoc-siggen2ch/* -d x310 -t X310_RFNOC_HG -m 6 --fill-with-fifos which means pointing to the top OOT directory instead to directly the fpga-srcs dire