[USRP-users] Fwd: Error on adding RFNoC BLOCK - FFT.

Hello Wade, I did not realise that I had removed usrp-users mail ID. Now I am able to add "FFT and Stream splitter" RFNoC core in the design making changes to the "x3xx_radio_base.yml" script. However, even now I am getting error *[WARNING] [0/Radio#0] Attempting to set tick rate to 0.

[USRP-users] Fwd: UHD 4.7 - Building X310_XG FPGA

Hi All, I have a clone of UHD 4.7 (Tags: v4.7.0.0) and am trying to build the default X310_XG FPGA to check if my setup is OK. I ran the following commands from /uhd/fpga/usrp3/top/x300 source ./setupenv.sh rfnoc_image_builder -y x310_XG_rfnoc_image_core.yml -t X310_XG After some time I get t

[USRP-users] Fwd: The firmware build is not compatible with the host code build

Those Rev numbers are hardware revs, but it may well also indicate that its on-board FPGA image is quite old--old enough that   modern image-loader tooling cannot cope, which is why a "hill-climbing" approach may be necessary. I'll note that Ubuntu packaged UHD 3.15 for 20.04 (Focal): https://

[USRP-users] Fwd: [CfP] Software-Defined Radio and Amateur Radio Devroom 2024

Dear USRP-users, many of us do interesting work, producing Free and Open Source solution to radio (and other!) problems. Should you happen to feel the need to talk about what you're doing in public: That can be helped! Please submit your talk (20–25 min) proposal for FOSDEM'24; see the full Cal

[USRP-users] Fwd: Re: E310 GnuRadio upgrade?

For the person asking about upgrading GNURadio on the E312. My outline from last year. Philip Forwarded Message Subject:[USRP-users] Re: E310 GnuRadio upgrade? Date: Fri, 4 Nov 2022 15:42:31 -0700 From: Rich Gopstein To: Philip Balister CC: Marcus D. Lee

[USRP-users] Fwd: Initializing block control DmaFIFO_0 module error

Hello, I am working with two X310 and TwinRx in both, Ubuntu 16.04 LTE and UHD 3.12. I am trying to execute any code and I get an error in the initialization of the cards in the DmaFIFO_0 module. This is my output from running the *uhd_usrp_probe* command for each individual card and for the set.

[USRP-users] Fwd: Adding a Window block to an RFNOC graph

Hello, I have a problem that when receiving samples from the USRP E310 board, after the FFT block at low gain, zero values are received. After that I log them and get infinity. I wanted to figure out what the problem is, but I have no idea, maybe the Window block will fix the situation. But when bu

[USRP-users] Fwd: Continuos time acquisition

-- Forwarded message - De: Anabel Almodovar Date: jue, 24 jun 2021 a las 12:49 Subject: Continuos time acquisition To: Ettus Research Support I am working with two X310 boards equipped with two TwinRx each. They are connected to a host via a dual 10GB Ethernet interface (MTU 900

Re: [USRP-users] Fwd: E310: Change MAC Address?

On 12/1/20 12:52 PM, Andrew Payne via USRP-users wrote: > That worked as planned, no more duplicate MAC addresses now. > > As you can see from the following 3 boot message blocks (1. before, 2. > after applying said env settings, 3. thereafter) it knew the environment > MAC didn't match the ROM MA

Re: [USRP-users] Fwd: E310: Change MAC Address?

That worked as planned, no more duplicate MAC addresses now. As you can see from the following 3 boot message blocks (1. before, 2. after applying said env settings, 3. thereafter) it knew the environment MAC didn't match the ROM MAC. But it's just a warning. Thanks! ---

Re: [USRP-users] Fwd: E310: Change MAC Address?

No worries! In lieu of an eeprom burning solution which is the right answer as Phillip stated, one can just provision it in the dtb pre-production (ur uboot enc method) for an interim fix (i would assume) before SD cards are passed around with some scripting. Of course testing required :). someo

Re: [USRP-users] Fwd: E310: Change MAC Address?

OK try this at the u-boot prompt: env default -a env save and then reset This should reset the u-boot env to the default values and I think this resets the ethaddr variable. Then you write it to the mmc (99% certain). On the next hard reset hopefully it reads the address from the eeprom. Phil

Re: [USRP-users] Fwd: E310: Change MAC Address?

I have a query In to Ettus engineering on this. I can’t find any documentation on changing the MAC. The u-boot environment thinks of the MAC address as precious and once it is set, it won’t let you change it or delete it. Presumably a fresh image from the download site has code that sets the

Re: [USRP-users] Fwd: E310: Change MAC Address?

Thanks Aneesh but the decompiled dts file has no mention of the exact MAC address for eth0, but just to read from the eeprom from what I can gather. Plus an md5sum of the dtb file on the sdimg from Ettus is the same checksum as an e310 that has booted. On Fri, Nov 27, 2020 at 1:40 PM Philip Balist

Re: [USRP-users] Fwd: E310: Change MAC Address?

On 11/27/20 1:34 PM, aneesh patel via USRP-users wrote: > Hi Andrew, > The MAC may be in the devicetree blobs in the boot area of the SD image. > You will need dtcedit to decompile, edit, and recompile as needed. I don't think so, since the first time the card boots it does read from the i2c eepro

Re: [USRP-users] Fwd: E310: Change MAC Address?

Correction as the last post was from memory/apologies. Package: device-tree-compiler executable: dtc Happy holidays.  Amp Sent from Yahoo Mail on Android On Fri, Nov 27, 2020 at 1:35 PM, aneesh patel via USRP-users wrote: ___ USRP-users mailing

Re: [USRP-users] Fwd: E310: Change MAC Address?

Hi Andrew, The MAC may be in the devicetree blobs in the boot area of the SD image. You will need dtcedit to decompile, edit, and recompile as needed. Amp Sent from Yahoo Mail on Android On Fri, Nov 27, 2020 at 1:23 PM, Andrew Payne via USRP-users wrote: __

Re: [USRP-users] Fwd: E310: Change MAC Address?

P.S.: To add, in each of my 8 e310s, the following command: cat /sys/class/net/eth0/address yields: 00:80:2f:19:4c:37 So I have that mac address in 8 SDRs on my LAN. And only one of them is true, the one from which I cloned the golden image via dd. But the following command: hexdump /sys/bus/

Re: [USRP-users] Fwd: E310: Change MAC Address?

Just an update on my findings with the MAC Address problem. It seems that on first boot, the mac address is set in stone in the u-boot environment variable ethaddr. It cannot be manually changed by me if I went into the u-boot configuration menu: https://www.denx.de/wiki/view/DULG/UBootEnvVariabl

Re: [USRP-users] Fwd: E310: Change MAC Address?

Of the 8 e310s that I have tested with the same image, only one of them has the actual MAC address of 00:80:2f:19:4c:37, which I was able to find out via: hexdump /sys/bus/nvmem/devices/0-00510/nvmem Weird. Glad I found the one device that had that MAC though. So that must have been patient 0. Th

Re: [USRP-users] Fwd: E310: Change MAC Address?

Near as I can tell the e310 gets its MAC from the motherboard i2c eeprom. Sent from my iPhone > On Nov 25, 2020, at 12:55 PM, Andrew Payne via USRP-users > wrote: > >  > So does the U-Boot environment determine the MAC address of eth0 prior to > booting the kernel? Or is it during the make

Re: [USRP-users] Fwd: E310: Change MAC Address?

So does the U-Boot environment determine the MAC address of eth0 prior to booting the kernel? Or is it during the make of the boot image? I just find it a stretch to believe that I am running an image on a number of SDRs, and they're all using the same MAC address, possibly from the e310 for whic

Re: [USRP-users] Fwd: FPGA RFNoC Radio block with only one channel

Hi Wide, You are right, for radio_1x64, the port is radio_iface. I have change it and now it works. Thanks for helping me. Kind Regards, Maria. El mié., 25 nov. 2020 17:06, Wade Fife escribió: > Hi Maria, > > I think you need to change the dstport on line 86 to from x300_radio to > radio_ifa

Re: [USRP-users] Fwd: FPGA RFNoC Radio block with only one channel

Hi Maria, I think you need to change the dstport on line 86 to from x300_radio to radio_iface. When there are unresolved connections, the tool outputs the list of connections available. The one you want is (('radio0', 'radio_iface', 'slave'),). You can also check the port name in the radio_1x64.ym

Re: [USRP-users] Fwd: E310: Change MAC Address?

Mine is different, but both seem to be from the National Instruments block (which is good): root@ni-e31x-30D280A:~# ifconfig eth0 Link encap:Ethernet HWaddr 00:80:2F:25:02:37 inet addr:192.168.11.152 Bcast:192.168.11.255 I see a warning early in boot about using a MAC address fro

[USRP-users] Fwd: E310: Change MAC Address?

-- Forwarded message - From: Andrew Payne Date: Wed, Nov 25, 2020 at 8:35 AM Subject: Re: [USRP-users] E310: Change MAC Address? To: Philip Balister It is: 00:80:2f:19:4c:37 When is that .patch file ran, is it during compilation of the BSP? When would I see that error message

Re: [USRP-users] Fwd: FPGA RFNoC Radio block with only one channel

Hi Wade, Thanks for the answer. I get an error if I run this command with the modifications made on the .yml file: ~/rfnoc/src/uhd/host/utils$ ./rfnoc_image_builder.py -y ../../fpga/usrp3/top/e320/e320_rfnoc_image_core.yml -d e320 -t E320_1G -g *[WAR] Module

Re: [USRP-users] Fwd: FPGA RFNoC Radio block with only one channel

Yes, that's correct. There's a radio_1x64.yml you can use to get a single channel radio. You might consider removing the FIFO if you don't need it. Wade On Tue, Nov 24, 2020 at 8:46 AM Maria Muñoz via USRP-users < usrp-users@lists.ettus.com> wrote: > > > -- Forwarded message - >

[USRP-users] Fwd: FPGA RFNoC Radio block with only one channel

-- Forwarded message - De: Maria Muñoz Date: lun, 23 nov 2020 a las 10:05 Subject: Re: [USRP-users] FPGA RFNoC Radio block with only one channel To: Wade Fife Hi Wade, Thanks for your answer that helps me a lot. I have migrated to UHD 4.0 as you suggested so just a few questio

[USRP-users] Fwd: Direction finding based on USRP E310 board

That is, in theory, I can simply start two streams from two channels and further process them using certain direction finding algorithms? ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus

Re: [USRP-users] Fwd: Benchmark_rate.py error

Thank you so much for your help. I was able to get it to work after so troubleshooting. Sincerely, Moges On Thu, Aug 20, 2020, 11:22 AM Marcus D. Leech wrote: > On 08/20/2020 06:57 AM, Ephraim Moges wrote: > > Good Morning, > > > > I am getting an error when follow the package manager route.

Re: [USRP-users] Fwd: Benchmark_rate.py error

On 08/20/2020 06:57 AM, Ephraim Moges wrote: Good Morning, I am getting an error when follow the package manager route. I think it is because their is currently no build that ettus was able to do on Ubuntu 20 and 18 according to ettus records. Please advise if I should revert back to ubuntu 1

Re: [USRP-users] Fwd: Benchmark_rate.py error

On 08/20/2020 06:57 AM, Ephraim Moges wrote: Good Morning, I am getting an error when follow the package manager route. I think it is because their is currently no build that ettus was able to do on Ubuntu 20 and 18 according to ettus records. Please advise if I should revert back to ubuntu 1

Re: [USRP-users] Fwd: Benchmark_rate.py error

Good Morning, I am getting an error when follow the package manager route. I think it is because their is currently no build that ettus was able to do on Ubuntu 20 and 18 according to ettus records. Please advise if I should revert back to ubuntu 16 or if this problem is unique to my computer. ht

Re: [USRP-users] Fwd: Benchmark_rate.py error

Please try the PPA route. Just spoke with Ettus R&D. Sent from my iPhone > On Aug 19, 2020, at 12:16 PM, Ephraim Moges wrote: > >  > Thank you I look forward to hearing from you. In the meantime I will > reinstall Ubuntu 20 and the essential libraries. > > >> On Wed, Aug 19, 2020, 12:13

Re: [USRP-users] Fwd: Benchmark_rate.py error

Thank you I look forward to hearing from you. In the meantime I will reinstall Ubuntu 20 and the essential libraries. On Wed, Aug 19, 2020, 12:13 PM Marcus D Leech wrote: > That’s a good question. I’m > Not sure if the packaging person for Ubuntu pays attention to this > list—they would be able

Re: [USRP-users] Fwd: Benchmark_rate.py error

That’s a good question. I’m Not sure if the packaging person for Ubuntu pays attention to this list—they would be able to definitively answer that. The Python API may be a separate package. I *think* the PPA provided by Ettus includes the Python API. Be careful about Mixing the official packag

Re: [USRP-users] Fwd: Benchmark_rate.py error

Will this also allow for me to call "import uhd" in my python scripts? On Wed, Aug 19, 2020, 11:47 AM Marcus D. Leech wrote: > On 08/19/2020 11:43 AM, Ephraim Moges wrote: > > I tried to install it on I ubuntu 20 or 18 but ran into many issues. I can > reinstall Ubuntu 20 but I'm not sure what s

Re: [USRP-users] Fwd: Benchmark_rate.py error

On 08/19/2020 11:43 AM, Ephraim Moges wrote: I tried to install it on I ubuntu 20 or 18 but ran into many issues. I can reinstall Ubuntu 20 but I'm not sure what steps you would recommend to follow to allow for an easy installation. https://files.ettus.com/manual/page_install.html#install_linux

Re: [USRP-users] Fwd: Benchmark_rate.py error

I tried to install it on I ubuntu 20 or 18 but ran into many issues. I can reinstall Ubuntu 20 but I'm not sure what steps you would recommend to follow to allow for an easy installation. On Wed, Aug 19, 2020, 11:41 AM Marcus D. Leech wrote: > On 08/19/2020 11:36 AM, Ephraim Moges wrote: > > Ubu

Re: [USRP-users] Fwd: Benchmark_rate.py error

On 08/19/2020 11:36 AM, Ephraim Moges wrote: Ubuntu 16 and I used cmake instructions https://files.ettus.com/manual/page_build_guide.html OK, so when CMake ran, did it say that it was turning off various features, due to missing dependencies. Also, Ubuntu 16 is insanely, outrageously, out-of-

Re: [USRP-users] Fwd: Benchmark_rate.py error

Ubuntu 16 and I used cmake instructions https://files.ettus.com/manual/page_build_guide.html On Wed, Aug 19, 2020, 11:35 AM Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 08/19/2020 11:27 AM, Ephraim Moges via USRP-users wrote: > > Good Morning, > > I am having a proble

Re: [USRP-users] Fwd: Benchmark_rate.py error

On 08/19/2020 11:27 AM, Ephraim Moges via USRP-users wrote: Good Morning, I am having a problem running the python benchmark_rate.py. The error message I am receiving is in the image attached "the module uhd has no attribute 'usrp'". My installation indicated everything was good when I ran a

[USRP-users] Fwd: Benchmark_rate.py error

Good Morning, I am having a problem running the python benchmark_rate.py. The error message I am receiving is in the image attached "the module uhd has no attribute 'usrp'". My installation indicated everything was good when I ran a make test, so I am not sure if I need to be in a specific folder

Re: [USRP-users] Fwd: Included headers in the installer:

On 06/24/2020 05:39 AM, Andreas Hagström via USRP-users wrote: -- Forwarded message - Från: *Andreas Hagström* > Date: ons 24 juni 2020 kl 09:36 Subject: Re: [USRP-users] Included headers in the installer: To: Marcus D Leech

[USRP-users] Fwd: Included headers in the installer:

-- Forwarded message - Från: Andreas Hagström Date: ons 24 juni 2020 kl 09:36 Subject: Re: [USRP-users] Included headers in the installer: To: Marcus D Leech Sorry, here is the complimentare information: Windows 64 bit version and built on vs2017. Den tis 23 juni 2020 kl 18:04

Re: [USRP-users] Fwd: dpdk-test does not work

Works beautifully. Thanks, Sam. Akın 9 Oca 2020 Per 21:54 tarihinde Sam Reiter şunu yazdı: > Akin, > > I'd recommend you check out our DPDK setup guide - hot off the presses: > > https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD > > Sam Reiter > Ettus Research > > > On Wed, Jan 8, 2020 at

Re: [USRP-users] Fwd: dpdk-test does not work

Akin, I'd recommend you check out our DPDK setup guide - hot off the presses: https://kb.ettus.com/Getting_Started_with_DPDK_and_UHD Sam Reiter Ettus Research On Wed, Jan 8, 2020 at 10:52 PM akin soysal via USRP-users < usrp-users@lists.ettus.com> wrote: > > > -- Forwarded message ---

[USRP-users] Fwd: dpdk-test does not work

-- Forwarded message - Gönderen: akin soysal Date: 8 Oca 2020 Çar 15:22 Subject: dpdk-test does not work To: USRP-users@lists.ettus.com Dear all, We have a USRP X310 setup and we are trying to make the UHD_3.15.0.0-0-g4e06022c driver work. I have added a file under /etc/uhd/uhd

[USRP-users] Fwd: [usrp-users] E320 Multi TX Stream Operation in GR 3.8 stops during configuration of the USRP sink

Hey, I managed to find a solution. So it really was a bug in GNU Radio 3.8. This issue proposes a workaround by clearing the stream channels variable in the uhd block (https://github.com/gnuradio/gnuradio/issues/2789). There is also an approved PR with a bugfix (https://github.com/gnuradio/gnuradi

Re: [USRP-users] Fwd: Failing to Instantiate Blocks ("No Binding Entity")

Hi, Did you include your generic_counter VHDL source file in Makefile.inc in the fpga-src directory? Jonathon On Mon, Oct 7, 2019 at 3:46 PM ishai alouche via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi everyone, > > In my architecture I instantiated an FM_block.vhd, and in the FM_bloc

Re: [USRP-users] Fwd: Error handling D when reading data USRP N 210

I read at 25 MHz with frequency tuning. And there can be a lot of these reorganizations. On another PC, I have an Ethernet controller network card: Intel Corporation 82571EB / 82571GB Gigabit Ethernet Controller D0 / D1 (copper applications) (rev 06) and similar errors occur. Unfortunately, I canno

Re: [USRP-users] Fwd: Error handling D when reading data USRP N 210

On 10/11/2019 04:28 PM, Sam Reiter via USRP-users wrote: Ivan, Thanks for sending that along. From a software perspective, what parameters do you input to your attached code to run it? I'm trying to understand the data rates you're trying to sustain over the NIC you have. I've been combing th

Re: [USRP-users] Fwd: Error handling D when reading data USRP N 210

Ivan, Thanks for sending that along. From a software perspective, what parameters do you input to your attached code to run it? I'm trying to understand the data rates you're trying to sustain over the NIC you have. I've been combing through this past USRP-users thread for some additional insight:

[USRP-users] Fwd: Error handling D when reading data USRP N 210

-- Forwarded message - От: Ivan Zahartchuk Date: ср, 9 окт. 2019 г. в 06:05 Subject: Re: [USRP-users] Error handling D when reading data USRP N 210 To: Sam Reiter CPU intel core i7 -3610QE 2.3 GGz RAM 16 Gb 2 NIC intel 82574L gigabit ethernet and intel 82574LM gigabit ethernet

[USRP-users] Fwd: Failing to Instantiate Blocks ("No Binding Entity")

Hi everyone, In my architecture I instantiated an FM_block.vhd, and in the FM_block I instantiated a generic_counter.vhd block. The problem: when I run the simulation I see that the FM_block is fine, but the generic_counter is unreferenced, and i get the following warning: *Starting static el

Re: [USRP-users] Fwd: Varying delay in signal reception

Let's take this discussion off list. If there's something useful to report back to the list we will. - MLD On Fri, Aug 9, 2019, at 3:41 AM, Sneha vasan wrote: > I want to know the time it takes to transmit and receive the signal,(which is > in the sense delay). I calculate this based on the time

Re: [USRP-users] Fwd: Varying delay in signal reception

I want to know the time it takes to transmit and receive the signal,(which is in the sense delay). I calculate this based on the time instant I receive the signal. Since I was receiving the signal at different time instants. And currently I am receiving the delay of 1.9e-4sec, 2.3e-4, 2.1e-4s...so

Re: [USRP-users] Fwd: Varying delay in signal reception

On 08/08/2019 01:32 PM, Michael Dickens via USRP-users wrote: Hi Sneha - Please "reply all" to keep the discussion on the USRP users email list. More eyes reading these means a greater chance that folks will jump in to help! The startup time for UHD / USRP / GR will be very similar between di

Re: [USRP-users] Fwd: Varying delay in signal reception

Hi Sneha - Please "reply all" to keep the discussion on the USRP users email list. More eyes reading these means a greater chance that folks will jump in to help! The startup time for UHD / USRP / GR will be very similar between different runs of the exact same flowgraph, but not exactly the sa

Re: [USRP-users] Fwd: Varying delay in signal reception

Hi Sneha - I take it by you forwarding your query without further comment that you didn't receive an answer to it? FYI It would be useful in the future to add such a comment, enquiring politely, before the forwarded part. So the big question here is how you are generating the signal. You say "M

[USRP-users] Fwd: Varying delay in signal reception

-- Forwarded message - From: Sneha vasan Date: Thu, Aug 8, 2019 at 2:31 PM Subject: Varying delay in signal reception To: Hi everyone, I am transmitting a OFDM modulated random signal padded with zeros which is generated from the Matlab. I am transmitting this signal using USR

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

Dear Edwin, this usually fails because the USRPs reply with a "where are USRPs broadcast" from uhd_find_devices with a "here I am broadcast", and often, these get caught in the firewall or don't get routed through e.g. NAT. Since you're using a VM: the X300 can push through a WHOLE lot of data pe

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

-- Forwarded message - De: Edwin Mauricio Barbosa Salinas Date: mar., 6 ago. 2019 a las 17:37 Subject: Configurating X300 "uhd_find_devices" No uhd devices found To: regards, I am currently working with a USRP X300, following its UHD and GNURADIO installation guides, I am making

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

On 07/30/2019 12:43 PM, Sammy Welschen via USRP-users wrote: Sorry for not specifying, but I was talking about two N310 or N320 devices. Do you know how it is in that case? With the N320, with the sample-clocks in-phase when using an external reference, I *THINK* you should see very little phase

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

Sorry for not specifying, but I was talking about two N310 or N320 devices. Do you know how it is in that case? Am Fr., 19. Juli 2019 um 16:58 Uhr schrieb Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com>: > On 07/19/2019 05:24 AM, Sammy Welschen via USRP-users wrote: > > Thanks for yo

Re: [USRP-users] Fwd: Re: Digital TV Clock recovery using N310 and GNUradio

Sounds good. I'll allow others to comment on the GNURadio side of things. Let me know if you have any specific HW concerns and I can chime in. -Daniel On Mon, Jul 22, 2019 at 5:17 PM m2wagner via USRP-users < usrp-users@lists.ettus.com> wrote: > > > Hey Daniel, > > Right now I'm setting an exter

[USRP-users] Fwd: Re: Digital TV Clock recovery using N310 and GNUradio

Hey Daniel,Right now I'm setting an externally generated clock to a nearby frequency and recording the data to file for later processing. I'd like the LOs to be disciplined to the recovered clock (I have a clock splitter already). I suppose I'm most curious to see what GNUradio blocks people hav

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

On 07/19/2019 05:24 AM, Sammy Welschen via USRP-users wrote: Thanks for your reply. I am a bit confused now. Since the LO for this stage is derived from the sample clock, wouldn't I be in the same situation as if I only shared 10 MHz reference and PPS signals? Quote from https://files.ettus.c

Re: [USRP-users] Fwd: Phase coherency for low RX frequencies

Thanks for your reply. I am a bit confused now. Since the LO for this stage is derived from the sample clock, wouldn't I be in the same situation as if I only shared 10 MHz reference and PPS signals? Quote from https://files.ettus.com/manual/page_usrp_n3xx.html: -- Reasons to

Re: [USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

It wouldn’t and it doesn’t. Those are just the defaults brought up in the source and sink blocks because many of the cards have those for standard antenna names. Sent from my iPhone > On Jul 18, 2019, at 8:17 PM, Taylor Eisman via USRP-users > wrote: > > I don’t want to make this about gnur

Re: [USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

Hi Taylor, The behavior of UHD selecting the antenna port for the LF/Basic boards changed a few releases ago on the X3xx. Instead of setting a subdev spec, you use the antenna port with the name. https://files.ettus.com/manual/page_dboards.html#dboards_basicrx Within the UHD Source/Sink blocks y

Re: [USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

I don’t want to make this about gnuradio, because this isn’t the place. However, why would gnuradio know to link the ab,a,b,ba antennas to tx/rx and rx2? On Thu, Jul 18, 2019 at 7:14 PM Marcus D Leech wrote: > There IS no RX2 or TX/RX antenna names on Basic_rx or Basic_tx boards. > > You can see

Re: [USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

There IS no RX2 or TX/RX antenna names on Basic_rx or Basic_tx boards. You can see In the probe output what the legit antenna names are for the boards you have installed. Sent from my iPhone > On Jul 18, 2019, at 6:33 PM, Robin Coxe via USRP-users > wrote: > > Sorry, I misunderstood your q

Re: [USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

Sorry, I misunderstood your question-- did you set up the mode in UHD correctly? http://files.ettus.com/manual/page_dboards.html Also, you might want to double-check the SMA connections just in case. Not sure if the subdev spec has changed in the last year. Someone who knows the UHD codebase bett

Re: [USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

Robin, We've set it up so that the RX Daughterboard connects to RX2 and the TX Daughterboard connects to TX/RX. Previously, we've been able to use these ports, but now it no longer identifies that we even have these ports. I don't think the issue is the Daughterboard as this worked less than a yea

[USRP-users] Fwd: Ettus X300 -- NO TX/RX, RX2 Avaliability

The RF capabilities of USRPs are determined by the daughterboards that are installed in the X300. From your uhd_usrp_probe output, you have a BasicTX and BasicRX installed in your device, which only support 1 bare bones transmit channel and one receive channel. Check out the daughtercard section

[USRP-users] Fwd: Phase coherency for low RX frequencies

>> >> I have just been corrected by one of my colleagues at Ettus. >> >> While there is an up conversion stage for frequencies below 450Mhz, the LO >> for that stage is fixed frequency, and derived from the sample clock and >> coherent across channels. >> >> So there should be no random ph

Re: [USRP-users] Fwd: How to escape from overflow error?

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

Re: [USRP-users] Fwd: How to escape from overflow error?

Unfortunately, Python is the only programming language I know. And I somehow difficult to imagine how without delay delays frequency tuning and continuous reading. I think that the NUM_AND_DONE mode will help me, but I do not know how to insist on it correctly and whether my reasoning on this is co

Re: [USRP-users] Fwd: How to escape from overflow error?

On 05/29/2019 03:29 AM, Ivan Zahartchuk via USRP-users wrote: Yes, I expanded the buffer as suggested in the driver. I made a test file for working with the board, here is its code. importuhd importnumpyasnp fromuhdimportlibpyuhdaslib importtime importscipy.signalassignal importpyqtgraphaspg

[USRP-users] Fwd: How to periodically write files using USRP and GNUradio

Hi Mark, If you look at gr-filerepeater (https://github.com/ghostop14/gr-filerepeater or from pybombs), I just recently added an advanced file sink to the module. One thing it has is a message port that you can pass a state key in the metadata to (1 to record, 0 to stop).The block will also a

[USRP-users] Fwd: Please add me to the mail list

Hallo Diogo, I had the same Problem. You get no sending-confirmation from the mailing-list and you don't get your own message from the mailing list. Unfortunately even the support of Ettus didn't know that an couldn't helped me. I've had to use a second Mail, to find this out :/ @Ettus: would be g

[USRP-users] Fwd: [Discuss-gnuradio] European GNU Radio Days contribution deadline (March 21st)

Forwarded Message Subject: [Discuss-gnuradio] European GNU Radio Days contribution deadline (March 21st) Date: Mon, 18 Mar 2019 10:50:51 + From: jean-michel.fri...@femto-st.fr To: discuss-gnura...@gnu.org The European GNU Radio Days contribution deadline is getting close

Re: [USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

Oh, OK. So I think this test passes, the output is below. I also double checked that I could set the 184.32e6 frequency when I am trying to run the actual code. But still I have timing related problems. So how can I further debug my timing problems? sudo ./tx_samples_from_file --rate 61.44e6 --arg

Re: [USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

On 02/08/2019 01:31 PM, akin soysal wrote: I tried setting it with the following command: uhd_usrp_probe --args="master_clock_rate=184.32e6" [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.HEAD-0-gbbce3e45 [INFO] [X300] X300 initialization sequence... [INFO] [X300]

Re: [USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

I tried setting it with the following command: uhd_usrp_probe --args="master_clock_rate=184.32e6" [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.13.1.HEAD-0-gbbce3e45 [INFO] [X300] X300 initialization sequence... [INFO] [X300] Maximum frame size: 8000 bytes. [INFO] [X300]

Re: [USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

On 02/08/2019 04:37 AM, akin soysal via USRP-users wrote: I am resending the mail to the forum so that everybody benefits. -- Forwarded message - From: *akin soysal* mailto:akinsoy...@gmail.com>> Date: Fri, Feb 8, 2019 at 10:29 AM Subject: Re: [USRP-users] USRP X310 Ubuntu 16.04

[USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

I am resending the mail to the forum so that everybody benefits. -- Forwarded message - From: akin soysal Date: Fri, Feb 8, 2019 at 10:29 AM Subject: Re: [USRP-users] USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers To: Marcus D. Leech Hello Mar

Re: [USRP-users] Fwd:

On 10/11/2018 01:03 PM, Mercado, Alejandra via USRP-users wrote: Dear USRP and GnuRadio folks, I'm not sure whom to whom I should address this question, since I don't know if the problem arises in the GnuRadio code, the drivers, or the actual physical USRP. I was attempting to run an extrem

[USRP-users] Fwd:

Dear USRP and GnuRadio folks, I'm not sure whom to whom I should address this question, since I don't know if the problem arises in the GnuRadio code, the drivers, or the actual physical USRP. I was attempting to run an extremely simple GRC graph (attached to this email) where the input antenna o

Re: [USRP-users] Fwd: USRP No antenna port listed

On 05/02/2018 03:58 PM, Daniel Guarecuco wrote: Hi Marcus, I don´t really understand what you mean when you say that I need to apply a tight filtering, I am very new to USRPs. Why would it work on USRP-2920 but it won't on USRP1? I am using a regular USB2 port with erllc_uhd_winusb driver down

Re: [USRP-users] Fwd: USRP No antenna port listed

On 04/30/2018 02:54 PM, Daniel Guarecuco via USRP-users wrote: Hi, I have an USRP1 with a BasicTX and a BasicRX. I have been trying to receive data with no luck, it seems there is a problem with the antenna port. I run uhd_usrp_probe.exe and this is what I get: C:\Program Files\UHD\bin>uhd_us

[USRP-users] Fwd: USRP No antenna port listed

Hi, I have an USRP1 with a BasicTX and a BasicRX. I have been trying to receive data with no luck, it seems there is a problem with the antenna port. I run uhd_usrp_probe.exe and this is what I get: C:\Program Files\UHD\bin>uhd_usrp_probe [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boo

[USRP-users] Fwd: Spectrum Scanning Problems USRP B200

​Hello. I use B200 to scan the spectrum in a certain band. I have two problems. 1) the last part of the collection of the spectrum becomes the beginning. Fig. 1 2) the switching time from frequency to frequency is alternated 0.00305509567261 0.0539989471436 0.00493001937866 0.054967880249 0.0047459

[USRP-users] FWD: set_rx_lo_source repeat

I think that the results with clock() are correct.The main issue is that the time at which data from all frequencies is present is meaningably greater than 5 msюIf I set the time to 5 ms as in the original example, the receiver will not be able to rebuild and the time measurement shows that it n

[USRP-users] Fwd: i want to ask something

Hello Kim: Since you mention a MIMO cable, I assume that you are using USRP 2 / N200 / N210. Do the following: 1. Assign unique IP addresses to one of the USRPs (if you haven't yet). See: https://files.ettus.com/manual/page_usrp2.html#usrp2_network_changeip 2. Set "Device Address" or "Device Arg

Re: [USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission

W dniu 13.11.2017 o 11:36, Piotr Krysik via USRP-users pisze: > Dear list, > > Little update on transmitting bursts and simultaneous receiving with > USRP B210. When I connect anything that has some path between TX/RX SMA > port's body and inner female sleeve contact (like 3dB attenuator or even >

Re: [USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission

Dear list, Little update on transmitting bursts and simultaneous receiving with USRP B210. When I connect anything that has some path between TX/RX SMA port's body and inner female sleeve contact (like 3dB attenuator or even my finger) the output signal starts to look ok. I don't know what is caus

[USRP-users] Fwd: Compiling UHD Host Library: Problem Enabling ARM Neon Support

Gwen, Wow, it was only 15 days ago too. The coincidence! Yes, that is the exact problem. Thank you! I have got mine compiled and I can see that it did build the converter for the neon. Kevin On Fri, Nov 10, 2017 at 2:07 AM, Gwenhael Goavec-Merou via USRP-users < usrp-users@lists.ettus.com> wrot

  1   2   >