[USRP-users] Re: RFNoC Replay module (DRAM to PC)
Hi all, I’m working on a multi-channel, phase-coherent transceiver platform using the N310 and RFNoC Replay block (UHD4.6). It has been tested successfully for 4TX and 4RX individually. However, I’m facing challenges getting 4TX and 4RX to work simultaneously. Attempts to configure: 1. *1 Replay block with 8 I/O ports:* - Result: Bitstream generated successfully, and Replay block connects with other blocks. However, data read/write fails on ports 4–7. - Inference: [1][2] suggest the N310 Replay block only supports 4 channels, which might explain the issue. 2. * 2 Replay blocks, each with 4 I/O ports:* - Result: Bitstream compilation fails (YAML and logs attached). - Inference: Could the issue be related to connecting both Replay blocks to the same DRAM? If so, is it possible to partition the DRAM for use by both blocks? Reference [2] mentions that DRAM access can be controlled by adjusting axi_intercon_2x64_128_bd to restrict memory availability. Could this be a solution to allow DRAM access for both Replay blocks? Any guidance on configuring the Replay block for simultaneous 4TX/4RX would be greatly appreciated. References: [1] https://kb.ettus.com/Using_the_RFNoC_Replay_Block_in_UHD_4#Building_Custom_FPGA_Images_with_a_Replay_Block [2] https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#How_do_I_add_the_Replay.2FDMA_FIFO_block_to_my_FPGA_image.3F Thanks, Jorge Martin Braun 於 2024年10月4日 週五 下午11:41寫道： > Mark the last connection as a back-edge ( > https://uhd.readthedocs.io/en/latest/classuhd_1_1rfnoc_1_1rfnoc__graph.html#ab4cca8d99af451a9b9c5757af2b66ffa, > see also > https://uhd.readthedocs.io/en/latest/page_properties.html#props_graph_resolution_back_edges > ). > > --M > > On Fri, Oct 4, 2024 at 4:39 PM hui cj wrote: > >> Sorry to bother everyone again, >> >>- 0/Replay#0:0 --> 0/DUC#0:0 >>- 0/DUC#0:0 ==> 0/Radio#0:0 >>- 0/Radio#0:0 ==> 0/DDC#0:0 >>- 0/DDC#0:0 --> 0/Replay#0:0 >> >> I wonder to realize the graph that work for playing from DRAM and >> recording to DRAM simultaneously, >> >> graph->connect(tx_replay_ctrl->get_block_id(), tx_replay_chan, >> duc_ctrl->get_block_id(), duc_chan); >> >> graph->connect(duc_ctrl->get_block_id(), duc_chan, >> tx_radio_ctrl->get_block_id(), tx_chan); >> >> >> graph->connect(rx_radio_ctrl->get_block_id(), rx_chan, >> ddc_ctrl->get_block_id(), ddc_chan); >> >> graph->connect(ddc_ctrl->get_block_id(), ddc_chan, >> rx_replay_ctrl->get_block_id(), rx_replay_chan); >> >> >> Then the following error ran out. >> >> [ERROR] [RFNOC::GRAPH::DETAIL] Adding edge 0/DDC#0:0 -> 0/Replay#0:0 without >> disabling is_forward_edge will lead to unresolvable graph! >> >> Can someone help me? Thanks! >> >> ___ >> USRP-users mailing list -- usrp-users@lists.ettus.com >> To unsubscribe send an email to usrp-users-le...@lists.ettus.com >> > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > [00:13:54] Starting DRC Command [00:15:13] Current task: DRC +++ Current Phase: Starting [00:15:13] Current task: DRC +++ Current Phase: Finished [00:15:13] Executing Tcl: opt_design -directive NoBramPowerOpt [00:15:13] Starting Logic Optimization Command [00:15:13] Current task: Logic Optimization +++ Current Phase: Starting [00:15:13] Current task: Logic Optimization +++ Current Phase: Finished [00:15:13] Starting DRC Task ERROR: [DRC MDRV-1] Multiple Driver Nets: Net n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/B25[0] has multiple drivers: n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[0]/Q, and n3xx_core/rfnoc_sandbox_i/b_replay0_6/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[0]/Q. ERROR: [DRC MDRV-1] Multiple Driver Nets: Net n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/B25[1] has multiple drivers: n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[1]/Q, and n3xx_core/rfnoc_sandbox_i/b_replay0_6/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[1]/Q. ERROR: [DRC MDRV-1] Multiple Driver Nets: Net n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/B25[2] has multiple drivers: n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[2]/Q, and n3xx_core/rfnoc_sandbox_i/b_replay0_6/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[2]/Q. ERROR: [DRC MDRV-1] Multiple Driver Nets: Net n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/B25[3] has multiple drivers: n3xx_core/rfnoc_sandbox_i/b_replay1_7/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[3]/Q, and n3xx_core/rfnoc_sandbox_i/b_replay0_6/gen_replay_blocks[0].axi_dma_master_i/m_axi_awlen_reg[3]/Q. ERROR: [DRC MDR
[USRP-users] Re: RFNoC Replay module (DRAM to PC)
Hi Martin Thank you for your reply. I understand the N310’s default Replay block has 4 input and 4 output ports. In my setup, I connect the tx_streamers to the Replay block’s input ports and route the output ports to the DUC blocks on the TX side. On the RX side, I connect the DDC blocks to the Replay block’s input ports, with the output ports connected to the rx_streamers. This is why I believe I may need additional ports for simultaneous TX-RX, and I’m exploring possible solutions. I plan to use a 100MHz bandwidth with a sample rate of 122.88MSps per channel. I’ve noticed that channel time offsets occur when overflows or underflows happen in the real-time streaming architecture based on the multi-usrp object. Since stability is crucial, especially it takes time to collect data. And the experiment will be conducted outdoors, I aim to keep the system as compact as possible, using just one USRP N310 and a notebook (there will be a target in the air for transmitting samples to and receiving samples from). This is why I’m considering using the Replay block to off load the massive data transmission between NB and USRP N310. Thanks again for mentioning the TX/RX cross talk issue. I plan to try separating the frequencies for the external TX/RX LOs to reduce the problem. Do you think this approach might help? Any further suggestions would be greatly appreciated! Thanks! Jorge On Wed, Oct 9, 2024 at 3:53 PM Martin Braun wrote: > Jorge, > > for 4x4 mode, you need 4 ports, not 8. If you configure the replay block > with 4 channels, it will create both 4 input and output ports, > respectively. What bandwidth are you trying to capture? > > Also remember that if you TX and RX simultaneously, you will get crosstalk. > > --M > > On Tue, Oct 8, 2024 at 10:06 AM Jorge Chen wrote: > >> Hi all, >> >> I’m working on a multi-channel, phase-coherent transceiver platform using >> the N310 and RFNoC Replay block (UHD4.6). It has been tested successfully >> for 4TX and 4RX individually. >> >> However, I’m facing challenges getting 4TX and 4RX to work simultaneously. >> >> Attempts to configure: >> >>1. *1 Replay block with 8 I/O ports:* >> - Result: Bitstream generated successfully, and Replay block >> connects with other blocks. However, data read/write fails on ports >> 4–7. >> - Inference: [1][2] suggest the N310 Replay block only supports 4 >> channels, which might explain the issue. >>2. * 2 Replay blocks, each with 4 I/O ports:* >> - Result: Bitstream compilation fails (YAML and logs attached). >> - Inference: Could the issue be related to connecting both Replay >> blocks to the same DRAM? If so, is it possible to partition the DRAM >> for >> use by both blocks? >> >> Reference [2] mentions that DRAM access can be controlled by adjusting >> axi_intercon_2x64_128_bd to restrict memory availability. >> Could this be a solution to allow DRAM access for both Replay blocks? >> >> Any guidance on configuring the Replay block for simultaneous 4TX/4RX >> would be greatly appreciated. >> >> >> References: >> [1] >> https://kb.ettus.com/Using_the_RFNoC_Replay_Block_in_UHD_4#Building_Custom_FPGA_Images_with_a_Replay_Block >> [2] >> https://kb.ettus.com/RFNoC_Frequently_Asked_Questions#How_do_I_add_the_Replay.2FDMA_FIFO_block_to_my_FPGA_image.3F >> >> >> Thanks, >> Jorge >> >> >> Martin Braun 於 2024年10月4日 週五 下午11:41寫道： >> >>> Mark the last connection as a back-edge ( >>> https://uhd.readthedocs.io/en/latest/classuhd_1_1rfnoc_1_1rfnoc__graph.html#ab4cca8d99af451a9b9c5757af2b66ffa, >>> see also >>> https://uhd.readthedocs.io/en/latest/page_properties.html#props_graph_resolution_back_edges >>> ). >>> >>> --M >>> >>> On Fri, Oct 4, 2024 at 4:39 PM hui cj wrote: >>> >>>> Sorry to bother everyone again, >>>> >>>>- 0/Replay#0:0 --> 0/DUC#0:0 >>>>- 0/DUC#0:0 ==> 0/Radio#0:0 >>>>- 0/Radio#0:0 ==> 0/DDC#0:0 >>>>- 0/DDC#0:0 --> 0/Replay#0:0 >>>> >>>> I wonder to realize the graph that work for playing from DRAM and >>>> recording to DRAM simultaneously, >>>> >>>> graph->connect(tx_replay_ctrl->get_block_id(), tx_replay_chan, >>>> duc_ctrl->get_block_id(), duc_chan); >>>> >>>> graph->connect(duc_ctrl->get_block_id(), duc_chan, >>>> tx_radio_ctrl->get_block_id(), tx_chan); >>>> >>>> >>>> graph-&g
[USRP-users] Re: For building Verilog code for FPGA x300 series which license Vivado should I necessary?
Hi, By the way, there's a note in AN-823 indicating the required Vivado edition for the USRP device. https://kb.ettus.com/Getting_Started_with_RFNoC_Development#Prerequisites *NOTE:* - The edition of Xilinx Vivado that is required will depend on which USRP device is being used. - X3xx series devices: Design Edition or System Edition. - E3xx series devices: Design Edition, System Edition, or the free WebPack Edition. 於 2022年1月17日 週一 下午8:49寫道： > K7-325T requires a full license. > > > https://support.xilinx.com/s/question/0D52E6hpNqF/ettus-usrp-x300-vivado-license?language=en_US > ___ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-le...@lists.ettus.com > ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] PPS and REF out form a X310 and leakage problem
Hi all
I’d like to build up 8X8 MIMO system using 4 USRP X310.
To synchronize time&freq. between all of them, I used to use a function
generator to feed both 1 PPS and 10 MHz reference clock to them.
Today, I got an Octoclock which I thought it is able to provide both
synchronization signal, but it is said that “For the OctoClock, there is no
internal timing or clocking source, so the OctoClock will always use
external 10 MHz and 1 PPS sources, regardless of the position of the switch.”
in the UHD manual.
So, I plan to use one of the X310 to feed the synchronization signal to the
Octoclock REF&PPS input and connect other X310s to the REF&PPS output, like
the block diagram below.
[image: 內置圖片 1]
1.
I use the LTS version of UHD (3.9.6).
And I use the commands like:
//Lock mboard clocks
tx_usrp->set_clock_source("internal",0);
tx_usrp->set_clock_source("external",1);
But it always show the error message:
Error: RuntimeError: Reference Clock PLL failed to lock to external source.
I wonder if the commands or my thought were wrong or this function is not
supported?Because I found some discussions (March, 2017) in the mailing
list talked about the X310 is not supported for daisy-chaining. By the way,
is X300 not supported neither?
2.
The other problem is that when I use a terminator to terminate the TX/RX
port, I can still discover the signal through the spectrum analyzer by
connecting an antenna. Is the signal leaked from somewhere? And how to
prevent it?
Thanks in advance!
Jorge
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] PPS and REF out form a X310 and leakage problem
Dear Derek
First of all, I feel sorry that I write you back so late, cuz I went to a
conference these days and was not able to do the experiments.
1. The Octoclock I have is the one needs external source.
2. Just to clarify, "The X310 will always output it's signals so can still
be used as the source but by using the external reference on all USRPs the
1PPS signals will be aligned at all units rather than having the master be
earlier than the others due to propagation delays."
2.1 No matter I set set_clock_source("external") or
set_clock_source("internal"),
the REF OUT/PPS TRIG OUT will always output reference/PPS sources?
2.2 If yes, does that mean I just need to use one of the X310 to provide
reference/PPS sources to the Octoclock, then the Octoclock will
provide the reference/PPS
to all of the X310? And thus the PPS will arrive to all X310 simultaneously?
Win32; Microsoft Visual C++ version 12.0; Boost_105600;
UHD_003.009.006-release
Creating the transmit usrp device with:
addr0=192.168.10.4,addr1=192.168.10.5...
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio0 control...
-- Creating WSA UDP transport for 192.168.10.4:49153
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Creating WSA UDP transport for 192.168.10.4:49153
-- Performing register loopback test... pass
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
Rev 0.929a
-- Initialize Radio0 control...
-- Creating WSA UDP transport for 192.168.10.5:49153
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Creating WSA UDP transport for 192.168.10.5:49153
-- Performing register loopback test... pass
Creating the receive usrp device with:
addr0=192.168.10.4,addr1=192.168.10.5...
Error: RuntimeError: Reference Clock PLL failed to lock to external source.
2017-08-08 0:22 GMT+08:00 Derek Kozel :
> Hello Jorge,
>
> The Octoclock is sold in two versions, one with an internal GPSDO and one
> that requires an external source.
>
> The X310 and X300 both do not support daisy chaining. There are a few
> issues with it, one of the key ones being propagation delay. If the 1PPS
> signal was passed from one unit to the next again and again it would arrive
> at the different USRPs at different times, ruining synchronization.
>
> The configuration should work with one of the X310s supplying the 10 MHz
> and 1 PPS. However it would be better to have the Octoclock's 10 MHz and
> 1PPS outputs connected to all four of the X310s. The X310 will always
> output it's signals so can still be used as the source but by using the
> external reference on all USRPs the 1PPS signals will be aligned at all
> units rather than having the master be earlier than the others due to
> propagation delays.
>
> Do you see the PPS light flashing on the Octoclock? What do the other
> lights show?
>
> Which USRP is failing to synchronize? If you only try to synchronize the
> slave USRPs does that work?
>
> Regards,
> Derek
>
> On Mon, Aug 7, 2017 at 3:28 PM, Jorge Chen via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi all
>>
>>
>>
>> I’d like to build up 8X8 MIMO system using 4 USRP X310.
>>
>> To synchronize time&freq. between all of them, I used to use a function
>> generator to feed both 1 PPS and 10 MHz reference clock to them.
>>
>> Today, I got an Octoclock which I thought it is able to provide both
>> synchronization signal, but it is said that “For the OctoClock, there is
>> no internal timing or clocking source, so the OctoClock will always use
>> external 10 MHz and 1 PPS sources, regardless of the position of the switch.”
>> in the UHD manual.
>>
>>
>>
>> So, I plan to use one of the X310 to feed the synchronization signal to
>> the Octoclock REF&PPS input and connect other X310s to the REF&PPS output,
>> like the block diagram below.
>>
>>
>>
>> [image: 內置圖片 1]
>>
>> 1.
>>
>> I use the LTS version of UHD (3.9.6).
>>
>> And I use the commands like:
>>
>> //Lock mboard clocks
>>
>> tx_usrp->set_clock_source("internal",0);
>>
>> tx_usrp->set_clock_source("external",1);
>>
>> But it always show the error message:
>>
>> Error: RuntimeError: Reference Clock PLL failed to lock to external
>> source.
>>
&
Re: [USRP-users] PPS and REF out form a X310 and leakage problem
Dear Derek
First of all, I feel sorry that I write you back so late, cuz I went to a
conference these days and was not able to do the experiments.
1. The Octoclock I have is the one needs external source.
2. Just to clarify, "The X310 will always output it's signals so can still
be used as the source but by using the external reference on all USRPs the
1PPS signals will be aligned at all units rather than having the master be
earlier than the others due to propagation delays."
2.1 No matter I set set_clock_source("external")
or set_clock_source("internal"), the REF OUT/PPS TRIG OUT will always
output reference/PPS sources?
2.2 If yes, does that mean I just need to use one of the X310 to
provide reference/PPS sources to the Octoclock, then the Octoclock will
provide the reference/PPS to all of the X310? And thus the PPS will arrive
to all X310 simultaneously?
3. However, when I use the configuration mentioned above, the program
failed in the beginning (Creating the receive usrp device).
Win32; Microsoft Visual C++ version 12.0; Boost_105600;
UHD_003.009.006-release
Creating the transmit usrp device with:
addr0=192.168.10.4,addr1=192.168.10.5...
-- X300 initialization sequence...
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Initialize Radio0 control...
-- Creating WSA UDP transport for 192.168.10.4:49153
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Creating WSA UDP transport for 192.168.10.4:49153
-- Performing register loopback test... pass
-- Determining maximum frame size... 1472 bytes.
-- Setup basic communication...
-- Loading values from EEPROM...
-- Setup RF frontend clocking...
-- Radio 1x clock:200
-- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
Rev 0.929a
-- Initialize Radio0 control...
-- Creating WSA UDP transport for 192.168.10.5:49153
-- Performing register loopback test... pass
-- Initialize Radio1 control...
-- Creating WSA UDP transport for 192.168.10.5:49153
-- Performing register loopback test... pass
Creating the receive usrp device with:
addr0=192.168.10.4,addr1=192.168.10.5...
Error: RuntimeError: Reference Clock PLL failed to lock to external source.
Thanks, and please ignore the previous not-finished-mail.
All the best!
Jorge
2017-08-18 20:15 GMT+08:00 Jorge Chen :
> Dear Derek
>
> First of all, I feel sorry that I write you back so late, cuz I went to a
> conference these days and was not able to do the experiments.
>
> 1. The Octoclock I have is the one needs external source.
> 2. Just to clarify, "The X310 will always output it's signals so can
> still be used as the source but by using the external reference on all
> USRPs the 1PPS signals will be aligned at all units rather than having the
> master be earlier than the others due to propagation delays."
>
> 2.1 No matter I set set_clock_source("external") or
> set_clock_source("internal"), the REF OUT/PPS TRIG OUT will always output
> reference/PPS sources?
> 2.2 If yes, does that mean I just need to use one of the X310 to provide
> reference/PPS sources to the Octoclock, then the Octoclock will provide
> the reference/PPS to all of the X310? And thus the PPS will arrive to all
> X310 simultaneously?
>
>
>
> Win32; Microsoft Visual C++ version 12.0; Boost_105600;
> UHD_003.009.006-release
>
>
> Creating the transmit usrp device with: addr0=192.168.10.4,addr1=192.
> 168.10.5...
> -- X300 initialization sequence...
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Initialize Radio0 control...
> -- Creating WSA UDP transport for 192.168.10.4:49153
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Creating WSA UDP transport for 192.168.10.4:49153
> -- Performing register loopback test... pass
> -- Determining maximum frame size... 1472 bytes.
> -- Setup basic communication...
> -- Loading values from EEPROM...
> -- Setup RF frontend clocking...
> -- Radio 1x clock:200
> -- Detecting internal GPSDO Found an internal GPSDO: LC_XO, Firmware
> Rev 0.929a
> -- Initialize Radio0 control...
> -- Creating WSA UDP transport for 192.168.10.5:49153
> -- Performing register loopback test... pass
> -- Initialize Radio1 control...
> -- Creating WSA UDP transport for 192.168.10.5:49153
> -- Performing register loopback test... pass
>
> Creating the receive usrp device with: addr0=192.168.10.4,addr1=192.
> 168.10.5...
> Error: RuntimeError: Reference Clock PLL failed to lock to external
> source.
>
>
>
> 2017-08-08 0:22 GMT+
[USRP-users] X310 REF LED is blinking
Dear all The LED of REF on the front panel of one of my X310 is blinking instead of constantly lighting up while working, that is, the reference clock is not able to be locked with other x310s (4x4 MIMO system). I've checked the reference clock source is constantly output, and other X310s works fine. I also tried to re-load the image, but it didn't work. Does anyone meet this situation before? How can I solve/fix this? Thanks! Jorge ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Is it able to use RFNoC Replay Block on the receiver chain?
Hi USRP users, In the example "rfnoc_replay_samples_from_file.cpp", we connect SEP and NoC blocks as follows: (Tx_streamer)=>[Replay#0:0]=>[DUC#0:0]=>[Radio#0:0]. It first sends samples from host and records them to the on board memory, then replays them from the on board memory continuously. We'd also like to offload the traffic and avoid overflow while receiving.Something like saving the samples outputs from DDC to the on board memory first,and then receive them from the on board memory to host. I'm wondering if I can use the same concept on the receiver chain by the replay block?If so, how to do that? Thanks and regards! Jorge ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] Probe N310 on Windows OS
Hi USRP Users I got the new N310, and followed the online Getting Started Guides step by step, and I'm able to run the rx_ascii_art_dft and some example programs on Ubuntu. However, while I tried it on Windows OS, I can ping the address (192.168.10.2) and find it using uhd_find_devices.exe, but cannot probe it. C:\Program Files\UHD\bin>uhd_find_devices.exe [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900; UHD_3.12.0.0-release -- -- UHD Device 0 -- Device Address: serial: 315A370 claimed: False mgmt_addr: 192.168.10.2 product: n310 reachable: No type: n3xx C:\Program Files\UHD\bin>uhd_usrp_probe.exe [INFO] [UHD] Win32; Microsoft Visual C++ version 14.0; Boost_105900; UHD_3.12.0.0-release [INFO] [MPMD FIND] Found MPM devices, but none are reachable for a UHD session. Specify find_all to find all devices. Error: LookupError: KeyError: No devices found for -> Empty Device Address I noticed that there's a reachable status while executing uhd_find_devices on Windows, I wonder if it corresponded to the message Found MPM devices, but none are reachable for a UHD session. in the uhd_usrp_probe log. Are there some other settings I should take care about? or the environment settings? Any suggestion would be appreciated. Thanks! Jorge ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] synchronizing multiple USRP N310
Hi USRP Users
I tried to synchronize 2 N310s throught the external PPS and reference
clock, and tested by the application below.
*tx_waveforms.exe --args
"addr0=192.168.30.3,addr1=192.168.40.3,clock_source=external,time_source=external,master_clock_rate=122.88e6"
--rate 30.72e6 --freq 3.5e9 --wave-type SINE --wave-freq 10e6 --gain 20
--channels "0,4"--ref "external" --pps "external"*
The program runs without errors, but no signal outputs from the
corresponding channels. ( No sine waveform on the scope, and the LED light
are dark.)
I've checked if the external PPS is available by the application
"test_pps_input.exe".
And if I only use 1 N310, it works normally.
But failed in the 2 N310s synchronized case.
The OS is Win10, and I use the UHD 3.13.1.
My questions are:
1. Is the commands or the hardware/environment setting causing the failure
on synchronizing the 2 N310s?
2. I found the eeprom_version and the rev information are different, does
this difference affect?
And two further questions:
3. When does the N310 re-initialize the daughter board? In the log (please
see the attached file), it executes re-initializing routine 3 times.
4. What's the difference between specifying "clock_source=external,
time_source=external" in the device argument and use the UHD API
set_time_source("external"),and set_clock_source("external") if I'd like to
synchronize multiple N310s.
Are they both necessary?
|/
| | Mboard: ni-n3xx-3151CB0
| | eeprom_version: 1
| | mpm_version: 3.13.1.0-gbbce3e45
| | pid: 16962
| | product: n310
| | rev: 5
| | rpc_connection: remote
| | serial: 3151CB0
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.2
| | FPGA git hash: d0360f7.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: temp, gps_locked, gps_time, gps_sky, gps_tpv, ref_locked,
fan
| _
|/
| | Mboard: ni-n3xx-3175D90
| | eeprom_version: 2
| | mpm_version: 3.13.1.0-gbbce3e45
| | pid: 16962
| | product: n310
| | rev: 6
| | rpc_connection: remote
| | serial: 3175D90
| | type: n3xx
| | MPM Version: 1.2
| | FPGA Version: 5.2
| | FPGA git hash: d0360f7.clean
| | RFNoC capable: Yes
| |
| | Time sources: internal, external, gpsdo, sfp0
| | Clock sources: external, internal, gpsdo
| | Sensors: gps_locked, fan, ref_locked, gps_tpv, gps_sky, gps_time,
temp
Any feedback or help are appreciated!
All the best!
Jorge
Florian Kaltenberger via USRP-users 於
2018年12月20日 週四 下午4:48寫道：
> Hi Michael,
>
> halleluja! that was it! Thanks for spotting this.
>
> Florian.
> On 20/12/2018 02:34, Michael West wrote:
>
> Hi Florian,
>
> The device arguments are "clock_source" and "time_source". I noticed in
> your command you had them as "clock_src" and "time_src". That may be the
> source of the problem.
>
> Regards,
> Michael
>
> On Mon, Dec 10, 2018 at 11:33 AM Florian Kaltenberger via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Dear Nate,
>>
>> no it says something like this is not supported with the N310 and I
>> should pass it using the args options. Sorry, I don't have access to the
>> N310 right now, so I can't give you the exact message, but I have tried
>> that.
>>
>> Florian.
>> On 10/12/2018 19:00, Nate Temple wrote:
>>
>> Hi Florian,
>>
>> If you pass the arg "--ref external" to tx_waveforms, does it resolve
>> this frequency offset?
>>
>>
>> https://github.com/EttusResearch/uhd/blob/master/host/examples/tx_waveforms.cpp#L62
>>
>> Regards,
>> Nate Temple
>>
>> On Thu, Dec 6, 2018 at 12:22 AM Florian Kaltenberger via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Marcus,
>>>
>>> I have measured this with a spectrum analyzer simply by setting markers
>>> to the peak of the sinusoid (one marker per measured USRP) and then taking
>>> the delta.
>>>
>>> Could it be that the USRP is ignoring the external reference when used
>>> alone? Remember, I am doing the test with one USRP at a time, as the test
>>> using multiple USRP simultaneously does not work.
>>>
>>> Florian.
>>> On 06/12/2018 00:29, Marcus Müller wrote:
>>>
>>> oh! That means 341 ppb frequency error, which *really* shouldn't be
>>> happening.
>>>
>>> I'd like to get some statistics of that error, how are you measuring
>>> it?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Wed, 2018-12-05 at 12:55 +0100, Florian Kaltenberger wrote:
>>>
>>> Sorry typo. I did use a frequency of 3.51GHz.
>>>
>>>
>>> On 5 Dec 2018, at 12:54, Marcus Müller
>>>
>>> wrote:
>>>
>>> Hi Florian,
>>>
>>> trying to get my head to understand the order of problems here:
>>> Could you try to use a higher frequency (say, --freq 2e9 instead of
>>> 3.5e6)?
>>> I'd thing 3.51 MHz is out of range for the N310, anyway?
>>>
>>> Best regards,
>>> Marcus
>>>
>>> On Wed, 2018-12-05 at 11:49 +0100, Flori
Re: [USRP-users] synchronizing multiple USRP N310
Hi Marcus
Thanks for your reply.
Since I thought it works in the case using channel 0,4 with default subdev
spec setup(“A:0 A:1 B:0 B:1”), so I ignore setting the subdev spec.
However, I add the subdev spec setting and test again, but still failed to
transmit synchronized signal from 2 N310s.
Any other advices?
To take a note, Q3 yesterday,3. When does the N310 re-initialize the
daughter board?
-> I found that the time is after set_clock_source(ref) and
set_time_source(pps) commands.
All the best!
Jorge
Marcus D. Leech via USRP-users 於 2019年2月22日
週五，上午3:27寫道：
> On 02/21/2019 10:18 AM, Jorge Chen via USRP-users wrote:
>
> Hi USRP Users
>
> I tried to synchronize 2 N310s throught the external PPS and reference
> clock, and tested by the application below.
> *tx_waveforms.exe --args
> "addr0=192.168.30.3,addr1=192.168.40.3,clock_source=external,time_source=external,master_clock_rate=122.88e6"
> --rate 30.72e6 --freq 3.5e9 --wave-type SINE --wave-freq 10e6 --gain 20
> --channels "0,4"--ref "external" --pps "external"*
> The program runs without errors, but no signal outputs from the
> corresponding channels. ( No sine waveform on the scope, and the LED light
> are dark.)
>
> You have not included a subdev specification, so it's not going to be able
> to intuit what you mean.
>
>
> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Subdevice_Specification_Mapping
>
>
>
>
> I've checked if the external PPS is available by the application
> "test_pps_input.exe".
> And if I only use 1 N310, it works normally.
> But failed in the 2 N310s synchronized case.
>
> The OS is Win10, and I use the UHD 3.13.1.
>
> My questions are:
> 1. Is the commands or the hardware/environment setting causing the failure
> on synchronizing the 2 N310s?
> 2. I found the eeprom_version and the rev information are different, does
> this difference affect?
> And two further questions:
> 3. When does the N310 re-initialize the daughter board? In the log (please
> see the attached file), it executes re-initializing routine 3 times.
> 4. What's the difference between specifying "clock_source=external,
> time_source=external" in the device argument and use the UHD API
> set_time_source("external"),and set_clock_source("external") if I'd like to
> synchronize multiple N310s.
> Are they both necessary?
>
>
> |/
> | | Mboard: ni-n3xx-3151CB0
> | | eeprom_version: 1
> | | mpm_version: 3.13.1.0-gbbce3e45
> | | pid: 16962
> | | product: n310
> | | rev: 5
> | | rpc_connection: remote
> | | serial: 3151CB0
> | | type: n3xx
> | | MPM Version: 1.2
> | | FPGA Version: 5.2
> | | FPGA git hash: d0360f7.clean
> | | RFNoC capable: Yes
> | |
> | | Time sources: internal, external, gpsdo, sfp0
> | | Clock sources: external, internal, gpsdo
> | | Sensors: temp, gps_locked, gps_time, gps_sky, gps_tpv, ref_locked,
> fan
> | _
> |/
> | | Mboard: ni-n3xx-3175D90
> | | eeprom_version: 2
> | | mpm_version: 3.13.1.0-gbbce3e45
> | | pid: 16962
> | | product: n310
> | | rev: 6
> | | rpc_connection: remote
> | | serial: 3175D90
> | | type: n3xx
> | | MPM Version: 1.2
> | | FPGA Version: 5.2
> | | FPGA git hash: d0360f7.clean
> | | RFNoC capable: Yes
> | |
> | | Time sources: internal, external, gpsdo, sfp0
> | | Clock sources: external, internal, gpsdo
> | | Sensors: gps_locked, fan, ref_locked, gps_tpv, gps_sky, gps_time,
> temp
>
>
>
> Any feedback or help are appreciated!
>
> All the best!
> Jorge
>
>
> Florian Kaltenberger via USRP-users 於
> 2018年12月20日 週四 下午4:48寫道：
>
>> Hi Michael,
>>
>> halleluja! that was it! Thanks for spotting this.
>>
>> Florian.
>> On 20/12/2018 02:34, Michael West wrote:
>>
>> Hi Florian,
>>
>> The device arguments are "clock_source" and "time_source". I noticed in
>> your command you had them as "clock_src" and "time_src". That may be the
>> source of the problem.
>>
>> Regards,
>> Michael
>>
>> On Mon, Dec 10, 2018 at 11:33 AM Florian Kaltenberger via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Dear Nate,
>>>
>>> no it says something like this is not supported with the N310 and I
>>> should pass it using the args options. Sorry, I don't have access to the
>>> N310 right now, so I can't give you the exact message,
Re: [USRP-users] synchronizing multiple USRP N310
Hi Marcus
Sorry for the confusion, the problem is no signal at all, and the
application just hang without any message.
Thanks
Jorge
Marcus D. Leech 於 2019年2月22日 週五，下午10:09寫道：
> On 02/22/2019 08:15 AM, Jorge Chen wrote:
>
> Hi Marcus
>
> Thanks for your reply.
>
> Since I thought it works in the case using channel 0,4 with default subdev
> spec setup(“A:0 A:1 B:0 B:1”), so I ignore setting the subdev spec.
> However, I add the subdev spec setting and test again, but still failed to
> transmit synchronized signal from 2 N310s.
> Any other advices?
>
> Yesterday, you said you failed to transmit *ANY* signal. Please clarify
> as to whether you mean you're transmitting, but the result is
> unsynchronized, or whether there's no signal at all.
>
>
>
>
>
>
> To take a note, Q3 yesterday,3. When does the N310 re-initialize the
> daughter board?
> -> I found that the time is after set_clock_source(ref) and
> set_time_source(pps) commands.
>
> All the best!
> Jorge
>
>
> Marcus D. Leech via USRP-users 於 2019年2月22日
> 週五，上午3:27寫道：
>
>> On 02/21/2019 10:18 AM, Jorge Chen via USRP-users wrote:
>>
>> Hi USRP Users
>>
>> I tried to synchronize 2 N310s throught the external PPS and reference
>> clock, and tested by the application below.
>> *tx_waveforms.exe --args
>> "addr0=192.168.30.3,addr1=192.168.40.3,clock_source=external,time_source=external,master_clock_rate=122.88e6"
>> --rate 30.72e6 --freq 3.5e9 --wave-type SINE --wave-freq 10e6 --gain 20
>> --channels "0,4"--ref "external" --pps "external"*
>> The program runs without errors, but no signal outputs from the
>> corresponding channels. ( No sine waveform on the scope, and the LED light
>> are dark.)
>>
>> You have not included a subdev specification, so it's not going to be
>> able to intuit what you mean.
>>
>>
>> https://kb.ettus.com/N300/N310_Getting_Started_Guides#Subdevice_Specification_Mapping
>>
>>
>>
>>
>> I've checked if the external PPS is available by the application
>> "test_pps_input.exe".
>> And if I only use 1 N310, it works normally.
>> But failed in the 2 N310s synchronized case.
>>
>> The OS is Win10, and I use the UHD 3.13.1.
>>
>> My questions are:
>> 1. Is the commands or the hardware/environment setting causing the
>> failure on synchronizing the 2 N310s?
>> 2. I found the eeprom_version and the rev information are different, does
>> this difference affect?
>> And two further questions:
>> 3. When does the N310 re-initialize the daughter board? In the log
>> (please see the attached file), it executes re-initializing routine 3 times.
>> 4. What's the difference between specifying "clock_source=external,
>> time_source=external" in the device argument and use the UHD API
>> set_time_source("external"),and set_clock_source("external") if I'd like to
>> synchronize multiple N310s.
>> Are they both necessary?
>>
>>
>> |/
>> | | Mboard: ni-n3xx-3151CB0
>> | | eeprom_version: 1
>> | | mpm_version: 3.13.1.0-gbbce3e45
>> | | pid: 16962
>> | | product: n310
>> | | rev: 5
>> | | rpc_connection: remote
>> | | serial: 3151CB0
>> | | type: n3xx
>> | | MPM Version: 1.2
>> | | FPGA Version: 5.2
>> | | FPGA git hash: d0360f7.clean
>> | | RFNoC capable: Yes
>> | |
>> | | Time sources: internal, external, gpsdo, sfp0
>> | | Clock sources: external, internal, gpsdo
>> | | Sensors: temp, gps_locked, gps_time, gps_sky, gps_tpv,
>> ref_locked, fan
>> | _
>> |/
>> | | Mboard: ni-n3xx-3175D90
>> | | eeprom_version: 2
>> | | mpm_version: 3.13.1.0-gbbce3e45
>> | | pid: 16962
>> | | product: n310
>> | | rev: 6
>> | | rpc_connection: remote
>> | | serial: 3175D90
>> | | type: n3xx
>> | | MPM Version: 1.2
>> | | FPGA Version: 5.2
>> | | FPGA git hash: d0360f7.clean
>> | | RFNoC capable: Yes
>> | |
>> | | Time sources: internal, external, gpsdo, sfp0
>> | | Clock sources: external, internal, gpsdo
>> | | Sensors: gps_locked, fan, ref_locked, gps_tpv, gps_sky, gps_time,
>> temp
>>
>>
>>
>> Any feedback or help are appreciated!
>>
>> All the best!
>> Jorge
>>
>>
>> Florian Kaltenberger via USRP-users
Re: [USRP-users] N310 Multi Device Configuration
Hi, Neharika and All,
I met some problems on controlling 2 N310s too.
But first of all, the argument "second_addr" indicates the IP addr. of
the second
SFP+ port on that device, and is set in the case of dual 10G streaming.
I think the first way you wrote is the right way to access the 2 N310s,
even though it is not listed in the Multiple USRP Configuration page.
(https://files.ettus.com/manual/page_multiple.html)
With that, I can control them (set rf parameters and receive signal on all
8 channels) without the error message you mentioned, what version of the
UHD you're using? (UHD 3.13.1, 3.14 worked for me)
My only problem is that they stop working (hang) at transmitting.
An alternative way is that I create 2 usrp objects to control them as the
commands below.
*uhd::usrp::multi_usrp::sptr tx_usrp_1
=
uhd::usrp::multi_usrp::make("addr=192.168.30.3,master_clock_rate=122.88e6,clock_source=external,time_source=external")
uhd::usrp::multi_usrp::sptr
tx_usrp_2
=
uhd::usrp::multi_usrp::make("addr=192.168.40.3,master_clock_rate=122.88e6,clock_source=external,time_source=external")*
Even though it works ( transmit signal simultaneously on all channels ), I
don't think it's the best way (or right way) to use multiple USRPs.
Has anyone done this before? or any suggestion?
Thanks
Jorge
Neharika Valecha via USRP-users 於 2019年5月2日 週四
下午9:20寫道：
> Hello,
>
> I am using two N310 USRP's to create an 8x8 MIMO setup. But, I am unable
> to make both of them work together. I am using an example program from
> the UHD driver - txrx_loopback_to_file.
>
> I give the following command:
>
> ./txrx_loopback_to_file --tx-rate 7.68e6 --rx-rate 7.68e6 --tx-freq 2.60e9
> --rx-freq 2.60e9 --tx-gain 70 --rx-gain 60 --tx-channels "0,1,2,3"
> --rx-channels "0,1,2,3" --tx-args
> "addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
> --rx-args
> "addr=192.168.10.2,second_addr=192.168.20.2,time_source=external,clock_source=external,master_clock_rate=122.88e6"
> --settling 1
>
> and only one USRP turns on.
> In USRP X300 there were two ways to use multiple USRP's,
> 1. Use --tx-args and --rx-args to specify "addr0,addr1" to access two
> different USRP's with --tx-channels and --rx-channels as "0,1". I tried
> that here but it gives an error, "Error message: Someone tried to claim
> this device again".
>
> 2. To define just one "addr" in --tx-args and --rx-args but have
> --tx-channels and --rx-channels as "0,1,2,3" (as X300 is 2x2). When tried
> with N310 with channel values "0,1,2,3,4,5,6,7" it gives an error that Tx
> channels invalid.
>
> So, could you tell me what is the correct syntax to access two USRP's?
>
> Thank you
> Neharika
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
