[USRP-users] Re: N320 SFP MAC issue

3 10:30 AM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: N320 SFP MAC issue On 20/04/2023 10:17, Jim Palladino wrote: Hello, We have multiple N320's connected to a managed 100Gbps switch. Each switch port has a QSFP -- so 4 10Gbps connections per port. We're connecting and using

[USRP-users] N320 SFP MAC issue

Hello, We have multiple N320's connected to a managed 100Gbps switch. Each switch port has a QSFP -- so 4 10Gbps connections per port. We're connecting and using both 10Gbps SFP interfaces on each N320 radio to the switch. Basically, one 100Gbps port on the switch will handle 2 N320's via the Q

[USRP-users] Re: Did anyone else need to do this?

. I can post and issue on the gnuradio github page as well. Jim ________ From: Jim Palladino Sent: Friday, December 16, 2022 9:38 AM To: usrp-users@lists.ettus.com ; Mike Subject: [USRP-users] Re: Did anyone else need to do this? Hi Mike, Yes, I've run into that.

[USRP-users] Re: Did anyone else need to do this?

Hi Mike, Yes, I've run into that. I posted an issue last week here: https://github.com/EttusResearch/gr-ettus/issues/69 [https://opengraph.githubassets.com/5b58487cd101d233e77dea3debf24f97c1326803f405d696532fef76e41550f5/EttusResearch/gr-ettus/issues/69]

[USRP-users] Re: N320 LO stability problem

Sent: Wednesday, November 2, 2022 2:05 PM To: Jim Palladino ; Marcus D. Leech ; USRP-users@lists.ettus.com Subject: RE: [USRP-users] Re: N320 LO stability problem Jim, thanks for the feedback and I’m glad it helped. Spurious phase noise tends to impair performance for our projects as well, thou

[USRP-users] Re: N320 LO stability problem

o keep moving forward. Also, I did briefly update one of the N320s to UHD 4.3.0.0 and saw the exact same overall behavior. Thanks, Jim ________ From: Jim Palladino Sent: Wednesday, November 2, 2022 8:52 AM To: David Raeman ; Marcus D. Leech ; usrp-users@lists.ettus.com

[USRP-users] Re: N320 LO stability problem

id Raeman Sent: Wednesday, November 2, 2022 8:49 AM To: Jim Palladino ; Marcus D. Leech ; usrp-users@lists.ettus.com Subject: RE: [USRP-users] Re: N320 LO stability problem Hi Jim, I ran into what sounds like the same issue using N320s operating at nearly the same center frequency. I was ab

[USRP-users] Re: N320 LO stability problem

iment with other UHD versions today to see if that makes a difference. Thanks, Jim From: Marcus D. Leech Sent: Wednesday, November 2, 2022 8:31 AM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: N320 LO stability problem On 02/11/2022 08:11, Jim Pall

[USRP-users] N320 LO stability problem

Hello, We have about ten N320s and almost all are exhibiting issues regarding the LO stability. It appears the LO is not locking at certain frequencies, or if it does, it barely maintains lock. We can see this with either a gnuradio flowgraph consisting of nothing more than a usrp_sink and a co

[USRP-users] Re: N320 sample rate change locking-up

I spent a fair amount of time trying to debug this. I wrote a custom app using the RFNoC API and tried continuously changing the sample rate (while streaming). I mostly bounced back and forth between 100Msps and 200Msps, with a master clock of 200MHz. To do this, I would change the sample rate l

[USRP-users] Re: N320 TDC measurement errors

3:8] This just undoes the change made in the commit mentioned above and requires more time before the LMK04848 to declares lock. Maybe some value in between would be a better choice, but I'm leaving it this way for now. I haven't seen any TDC errors so far. Thanks, Jim

[USRP-users] Re: N320 TDC measurement errors

Just passing on that I updated an N320 to UHD 4.2.0.0 and ran into the TDC error pretty quickly. I now reverted that radio to 4.1.0.2 and have not seen that error "yet". Thanks, Jim ____ From: Jim Palladino Sent: Monday, May 9, 2022 1:08 PM To: Marcu

[USRP-users] Re: N320 TDC measurement errors

2 and keep an eye on its behavior. Thanks Jim From: Marcus D. Leech Sent: Monday, May 9, 2022 12:04 PM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: N320 TDC measurement errors On 2022-05-09 11:32, Jim Palladino wrote: Sorry to bring it up again, but th

[USRP-users] Re: N320 TDC measurement errors

r has any thoughts on why this might be happening or how to fix it, that would be greatly appreciated. Thanks, Jim From: Jim Palladino Sent: Monday, May 2, 2022 12:59 PM To: USRP-users@lists.ettus.com Subject: [USRP-users] N320 TDC measurement errors Hello,

[USRP-users] N320 TDC measurement errors

Hello, Ever since updating to UHD 4.1.0.5 (including updating the filesystem and FPGA image on our six N320 USRPs), we occasionally get TDC measurement errors when trying to interact with the radio via UHD. It isn't easily reproducible, but it does happen on different radios maybe once a day or

[USRP-users] Re: rfnoc vs mult_usrp API question(s)

x27;t cause confusion. Thanks, Jim ________ From: Jim Palladino Sent: Thursday, March 24, 2022 10:40 AM To: USRP-users@lists.ettus.com Subject: rfnoc vs mult_usrp API question(s) Hello, I just want to make sure I understand the different API's and when to use them. I&#

[USRP-users] rfnoc vs mult_usrp API question(s)

Hello, I just want to make sure I understand the different API's and when to use them. I've been using the multi_usrp API for most development using the standard FPGA load on an N320. I recently added in an FFT RFNoC block into the FPGA load, and will soon add 1 or more custom RFNoC blocks. I

[USRP-users] Re: Problem using IQ calibration coefficients with Rhodium DB

Hi Marcus, One of my coworkers created an "Issue" in the UHD github repo. If there is a different place to post a bug, please let me know. Thanks, Jim From: Marcus D Leech Sent: Monday, March 14, 2022 12:45 PM To: Jim Palladino Cc: USRP-users@lists

[USRP-users] Problem using IQ calibration coefficients with Rhodium DB

Hello, I've found an issue with the Rhodium block controller code (rhodium_radio_control.cpp) where the daughterboard serial number is not handled correctly. If you look at line 452 here: https://github.com/EttusResearch/uhd/blob/master/host/lib/usrp/dboard/rhodium/rhodium_radio_control.cpp It

[USRP-users] Re: Timed Commands Not Working

function like set_rx_freq(), it really sends a series of commands that might vary depending on the frequency I'm tuning from/to. So, what I'm wondering is: how I can tell how much room remains in the command FIFO -- or some way to know how many future timed commands I can issue. Thanks, Jim

[USRP-users] Re: Timed Commands Not Working

e_command(). Thanks, Jim From: Dustin Widmann Sent: Friday, February 4, 2022 1:23 PM To: Jim Palladino; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Timed Commands Not Working For reference, I've done it over again with the latest commits from

[USRP-users] Re: RX Frequency Tuning Questions

e thing -- although Marcus L. mentioned that "test_timed_commands" does work with an N310 in UHD 3.15. If you could help clarify any of this, it would be appreciated. Thanks, Jim From: Martin Braun Sent: Monday, February 7, 2022 6:01 AM To: Jim Pall

[USRP-users] Re: Timed Commands Not Working

-Dustin On 2/3/22 08:02, Jim Palladino wrote: Thanks, Rob. I always appreciate when you "chime in". Hopefully, someone can try the uhd "test_timed_commands" example in 4.1 to help confirm whether or not it's a problem with something on my end or with UHD. Marcus already c

[USRP-users] Re: Timed Commands Not Working

nd UHD 3.15. Thanks, Jim From: Rob Kossler Sent: Wednesday, February 2, 2022 3:26 PM To: Jim Palladino Cc: Marcus D. Leech ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Timed Commands Not Working Hi Jim, This sounds like a pretty big issue. I ha

[USRP-users] Re: Timed Commands Not Working

Just to add one more data point, I just ran test_timed_commands on a different computer connected to an X310 -- still UHD 4.1. I have the same problem with that device where it looks like timed commands are not working right. Thanks, Jim From: Jim Palladino

[USRP-users] Re: RX Frequency Tuning Questions

9361-based. Thanks, Jim From: Marcus D. Leech Sent: Wednesday, February 2, 2022 11:41 AM To: usrp-users@lists.ettus.com Subject: [USRP-users] Re: RX Frequency Tuning Questions On 2022-02-02 10:43, Jim Palladino wrote: Hello, I'm working on a frequency scann

[USRP-users] Re: Timed Commands Not Working

Correct -- I am using the stock FPGA image for the E320 and the N320. Thanks, Jim From: Marcus D. Leech Sent: Wednesday, February 2, 2022 10:39 AM To: Jim Palladino ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: Timed Commands Not Working On 2022

[USRP-users] RX Frequency Tuning Questions

Hello, I'm working on a frequency scanning app where I need to maximize the tuning speed. I've been playing with timed commands -- I'm having issues with that and have posted about that separately. But I have some questions regarding RX tuning. I'm currently using an E320 and UHD 4.1 and devel

[USRP-users] Re: Timed Commands Not Working

Thanks Marcus. Please let me know if R&D comes back with anything. I'm at a bit of a loss . . . Thanks, Jim From: Marcus D. Leech Sent: Wednesday, February 2, 2022 9:56 AM To: Jim Palladino ; USRP-users@lists.ettus.com Subject: Re: [USRP-users]

[USRP-users] Re: Timed Commands Not Working

___ From: Marcus D. Leech Sent: Tuesday, February 1, 2022 2:13 PM To: Jim Palladino ; USRP-users@lists.ettus.com Subject: Re: [USRP-users] Re: Timed Commands Not Working On 2022-02-01 14:10, Jim Palladino wrote: Hi Marcus, In the app I'm writing, for now I'm just setting t

[USRP-users] Re: Timed Commands Not Working

.ettus.com Subject: [USRP-users] Re: Timed Commands Not Working On 2022-02-01 13:55, Jim Palladino wrote: Hello, I've been trying to get an app working with timed commands for an E320 or N320 using UHD 4.1. It seems that all commands are processed immediately, not at the time I tell them to. Set

[USRP-users] Timed Commands Not Working

Hello, I've been trying to get an app working with timed commands for an E320 or N320 using UHD 4.1. It seems that all commands are processed immediately, not at the time I tell them to. Setting the time to start RX streaming does seem to work fine, but that is a time_spec passed to the streami

[USRP-users] Re: Time different between X310 and N310 USRPs using UHD4.1.0

From: zhou Sent: Monday, December 20, 2021 10:38 AM To: usrp-users@lists.ettus.com ; Marcus Müller ; Jim Palladino Subject: Re: [USRP-users] Re: Time different between X310 and N310 USRPs using UHD4.1.0 Hi Jim, Thanks for your explanation. I got it. Inverter may be a quick solution; just

[USRP-users] Re: Time different between X310 and N310 USRPs using UHD4.1.0

ber 20, 2021 7:50 AM To: usrp-users@lists.ettus.com ; Marcus Müller ; Jim Palladino Subject: Re: [USRP-users] Time different between X310 and N310 USRPs using UHD4.1.0 Hi Jim, Thank you so much for your quick reply. Your finding is very interesting and I believe it is very related to my probl

[USRP-users] Re: Time different between X310 and N310 USRPs using UHD4.1.0

Hi, We had the exact same issue a couple months ago between an N320 and an X310. The issue is that the N320 (and I'm guessing the N310) detects the 1PPS pulse on the rising edge, as expected. The X310 detects the 1PPS edge on the falling edge. Note that the 1PPS pulse from the Octoclock stays h

[USRP-users] Re: Timing discrepencies with X310 vs N320

Hi Rob/all, You are on the same page as us (I work with Robert) regarding your rising/falling edge comments. This morning, I was looking at the schematics and FPGA code. Unless I missed something somewhere, it looks like the N320 detects the rising edge of the pulse. If I'm looking at the corre

[USRP-users] Re: N320 1PPS input voltage

e. The only thing we see there is: | | rev: 10 Thanks, Jim From: Marcus Müller Sent: Friday, June 11, 2021 3:07 PM To: Marcus D. Leech ; Jim Palladino ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: N320 1PPS input voltage Hi Jim, The cong

[USRP-users] Re: N320 1PPS input voltage

Ok, thanks for the info. I appreciate you guys running this down. Jim From: Marcus Müller Sent: Friday, June 11, 2021 3:07 PM To: Marcus D. Leech ; Jim Palladino ; usrp-users@lists.ettus.com Subject: Re: [USRP-users] Re: N320 1PPS input voltage Hi Jim, The

[USRP-users] Re: N320 1PPS input voltage

knowledge base article must be wrong: The octoclock internally only > has a 3.3V > supply. But before I say something wrong here, let me check back. > > > Best regards, > > Marcus The 1PPS outputs on the Octoclock are bufered by 7404 inverters, which appear to have a 5V Vc

[USRP-users] N320 1PPS input voltage

Hello, We are planning on using an octoclock with several devices, including an N320. The octoclock outputs a 5V 1pps signal, but I'm confused about the N320 1pps input. According to (https://kb.ettus.com/N320/N321): "PPS - Pulse Per Second Using a PPS signal for timestamp synchronization requ

Re: [USRP-users] OTT Gain Block stopping samples flowing from RFNoC Digital Down Converter

ebruary 17, 2021 11:43 AM To: Jim Palladino Cc: 'usrp-users@lists.ettus.com' Subject: RE: OTT Gain Block stopping samples flowing from RFNoC Digital Down Converter Thanks Jim, I’m using eth0 on the E320 which is set with an MTU of 1500 and this seems to be the maximum. If I try

Re: [USRP-users] OTT Gain Block stopping samples flowing from RFNoC Digital Down Converter

Hi Mark, I'm not sure if this is your problem, but I had a similar issue. After some debugging, I found that for some reason, with the OOT RFNoC Block inserted, the total size of the CHDR packet plus the Ethernet header that gets added on in the FPGA would slightly exceed the MTU size (mine was

Re: [USRP-users] Opening Vivado GUI during FPGA image build

It's been a while since I did this, but I had issues bringing up the gui as well. Here is a copy/paste of some notes I wrote for myself: * Edit the file "$PREFIX/bin/rfnoc_image_builder". * Find the line "gui=args.GUI" and change it to "GUI=args.GUI" and save it. * Next, edit "$PREFI

Re: [USRP-users] E320 SFP speed/duplex question

From: USRP-users on behalf of Jim Palladino via USRP-users Sent: Wednesday, December 9, 2020 2:03 PM To: Michael Dickens Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] E320 SFP speed/duplex question Thanks again for the response and information. I'm s

Re: [USRP-users] E320 SFP speed/duplex question

ssue could be, I would greatly appreciate it. We really need to run at higher sample rates than I'm currently able to do. Thanks, Jim From: Michael Dickens Sent: Wednesday, December 9, 2020 1:15 PM To: Jim Palladino Cc: usrp-users@lists.ettus.com Subject: Re:

Re: [USRP-users] E320 SFP speed/duplex question

o maybe things are working fine. Thanks, Jim From: Michael Dickens Sent: Wednesday, December 9, 2020 11:07 AM To: Jim Palladino Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] E320 SFP speed/duplex question Hi Jim - Just for completion: Try loading the &

[USRP-users] E320 SFP speed/duplex question

Hello, I just setup an E320 with a 1Gbps SFP. I've updated the filesystem, FPGA load (with the "1G" build"), etc and am using UHD 4.0. uhd_usrp_probe seems happy, and I created a gnuradio flowgraph and streamed samples ok. I did not test throughput, though. What concerns me is that when I conne

[USRP-users] E320 Autoboot

Hello, I have an E320 that I'm trying to get to auto-boot when power is applied (so the button doesn't need pushed). I followed instructions here (https://kb.ettus.com/E320_Getting_Started_Guide#Enable_Auto_Booting) to set the autoboot flag, but it isn't working (not automatically booting when

Re: [USRP-users] Adding Xilinx IP to custom RFNoC block

v:14] ERROR: [Common 17-69] Command failed: Synthesis failed - please see the console or run log file for details [00:04:25] Current task: Synthesis +++ Current Phase: Starting [00:04:26] Current task: Synthesis +++ Current Phase: Finished [00:04:26] Process terminated. Status: Failure Thanks, Jim

[USRP-users] Adding Xilinx IP to custom RFNoC block

Hello, I'm trying to add a Xilinx DDS to a custom RFNoC block (using UHD 4.0 and associated gr-ettus repo). To do this, I started building the FPGA image using the GUI option, stopped the build shortly after Vivado opened, and saved a Vivado Project. Then, in Vivado I configured/added a Xilinx

Re: [USRP-users] New mender instructions?

Hi Rob, Per (https://files.ettus.com/manual/page_usrp_e3xx.html#e3xx_rasm_mender) I used the following on an E320: mender install /home/root/usrp_e320_fs.mender I'm pretty sure I needed to add a force flag to it as well. Jim From: USRP-users on behalf of Rob

Re: [USRP-users] Trouble getting custom RFNoC block to work with gnuradio 3.8 / uhd 4.0

_ From: Rob Kossler Sent: Thursday, October 1, 2020 11:19 AM To: Jim Palladino Cc: usrp-users@lists.ettus.com Subject: Re: [USRP-users] Trouble getting custom RFNoC block to work with gnuradio 3.8 / uhd 4.0 So, the only other thing I can think of for now relates to issues that I have

Re: [USRP-users] Trouble getting custom RFNoC block to work with gnuradio 3.8 / uhd 4.0

dstport: ce } - { srcblk: _device_, srcport: dram, dstblk: fifo0, dstport: mem } - { srcblk: _device_, srcport: rfnoc_chdr,dstblk: Block0, dstport: ce } ### End of Block_x310_rfnoc_image_core.yml Thanks again for any help. Jim From: Rob Kossler Se

[USRP-users] Trouble getting custom RFNoC block to work with gnuradio 3.8 / uhd 4.0

Hello, Several weeks ago I went through the tutorial for producing the example "gain" block using rfnoc 3.8 and uhd 3.15. There were some bumps, but I did get that working fine. For the past couple weeks, I've been working with UHD 4.0 and the latest gr-ettus repo. I posted a question a week o

[USRP-users] RFNoC block not fully recognized by UHD 4.0

Hello, I just updated my rfnoc workflow to UHD 4.0 this week. I've gone through the process of creating an RFNoC block, building the corresponding FPGA image, putting it on an E320 (had to upgrade MPM), and seeing the block is present when executing uhd_usrp_probe. The problem is that the block