Re: [USRP-users] Lookup error: Path not found in tree

[Marcus D. Leech via USRP-users]

On 08/03/2018 05:17 PM, Pratik Chatterjee via USRP-users wrote:
I am building a repeater from the UHD and I have Nick's post as 
reference. My intended flow graph will be:


/radio_rx->gain_block(to remove timestamps)->radio_tx/

But I keep getting a lookup error (attached). I have isolated the line 
of error (line 196)
however I have not been able to correct it. Is there anything wrong 
fundamentally in my approach and what does the error mean:


/Error: LookupError: Path not found in tree: 
/mboards/0/dboards/B/tx_frontends/freq/value/


Output log: https://paste.ubuntu.com/p/gSnFQCDn9q/
Code: https://paste.ubuntu.com/p/XcFq3PNhZw/
usrp-probe: https://paste.ubuntu.com/p/ps6cRbRH3j/
usrp-probe-tree:https://paste.ubuntu.com/p/VMCWHkn3hW/ 




One of the problems with your graph is that the RFNOC "radio" blocks now 
always run at the native master-clock rate, and you have to insert

  a DDC/DUC block to resample to lower rates.

I don't know about the property tree problem, though.


___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP X310 Remote Configuration

[Michael West via USRP-users]

To expand on #2, the TX is limited by the 10 GbE link and the DRAM
bandwidth.  The 10 GbE link limitation is resolved by using both SFP+ ports
as 10 GbE ports.  The DRAM limitation is not so easy to overcome.  The DRAM
bandwidth is ~600 Msps, but it is used as a FIFO, so the bandwidth is cut
in half to ~300 Msps.  That bandwidth is shared by all TX channels, which
is the true limitation of the TX rate.  If a custom RFNoC replay block is
created in place of the DMA FIFO, the full 200 Msps bandwidth per channel
is available.

Regarding #3, there is an example RFNoC replay block in the works.  I
cannot say exactly when it will be available, but it will probably be
fairly soon.  I have been told a month or so.

Regards,
Michael

On Tue, Jul 31, 2018 at 7:41 AM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi Farnaz,
> Regarding #1, the USRP can be either Tx, Rx, or both, but it does not
> affect maximum streaming rates.  The 10Gbe link is bi-directional and can
> handle a maximum of 300 MS/s on a single link in both directions.  You can
> use both links such that you can receive both channels of the X310 at 200
> MS/s.
>
> Regarding #2, yes.  The USRP itself perhaps can handle the 200 MS/s per
> channel on transmit, but the PC just can't keep the streaming at that rate
> without hiccups.  The best you can get is 100 MS/s per channel on Tx.
>
> Regarding 3, not sure.
>
> Rob
>
> On Tue, Jul 31, 2018 at 10:34 AM Farnaz Chamanzadeh 
> wrote:
>
>> Dear Rob,
>>
>> 1. Can you explain if the USRP may be configured only in receive/transmit
>> mode or is it also possible to configure in a single mode (a pure
>> transmitter or a pure receiver) using both optical interfaces for the task?
>>
>> 2. In the first remark in your email, you mentioned that the
>> host-to-USRP streaming does not work at 200 MS/s for the transmit case.
>> Does it mean that in the  USRP-to-host mode it supports 200MS/s  per
>> channel in receiving mode while the host to USRP supports only 100MS/s
>> per channel?
>>
>> 3. About storing the samples on the USRP, does anyone know that if Ettus
>> has any plans to add this capability to the USRPs?
>>
>>
>> Best,
>> Farnaz
>>
>> On Mon, Jul 30, 2018 at 6:27 PM, Jason Matusiak <
>> ja...@gardettoengineering.com> wrote:
>>
>>> I've actually done this with success, unfortunately, I am not allowed to
>>> share it :(.  It wasn't too hard, I used a core in the block to hold the
>>> data, and then I just repeated it when I sent it out over and over.
>>>
>>> The catch was that there was a little bit of an issue within rfnoc at
>>> the time (you can see mailing lists conversations from back then in the
>>> archives) that kept it from kicking off at startup (an enable switch worked
>>> fine though).  Jonathon P helped with a patch to get me going, but that
>>> obviously has been mainlined by now since they have a siggen working (it
>>> didn't exist yet when I did my block).  The issue had something to do with
>>> the block sending data before everything have been initialized and came up
>>> properly.
>>>
>>> So it isn't too bad to create one.  Good luck!
>>>
>>>
>>>
>>> - Original Message -
>>> Subject: Re: [USRP-users] USRP X310 Remote Configuration
>>> From: "Rob Kossler via USRP-users" 
>>> Date: 7/30/18 9:33 am
>>> To: "Farnaz Chamanzadeh" 
>>> Cc: "usrp-users" 
>>>
>>> Perhaps look at the RFNoC siggen block. You will need to add some
>>> component such as a block memory or fifo to store the samples on the fpga
>>> and then you will need a way to populate the memory and then play it out
>>> when desired.
>>>
>>> Rob
>>>
>>> On Mon, Jul 30, 2018 at 3:49 AM Farnaz Chamanzadeh <
>>> farnaz.c...@gmail.com> wrote:
>>>
 Dear Rob,
 Thanks for your helpful response. The reason that we need to use a
 switch is due to hour host hardware limits, which only have one 10GBE.
 About the second remark in your email, do you have an example or a
 reference where a similar case was implemented which we can use  as a
 guideline for our implementation?

 Best regards,
 Farnaz

 On Thu, Jul 26, 2018 at 7:52 PM, Rob Kossler  wrote:

> Hi Farnaz,
> A couple of remarks and questions
> - Remark 1: in order to get 200 MS/s transmit streaming, you will NEED
> to have the samples on the USRP. The host-to-USRP streaming does not work
> at 200 MS/s for the transmit case (unless something has recently changed).
> The host-to-USRP max for transmit is 100 MS/s per channel
> - Remark 2: that leads into your question about having the samples
> stored on the USRP rather than streamed from host.  This is not presently 
> a
> capability, but can be added with some modest FPGA work.  I have been
> desiring such capability for a couple of years - I hope that Ettus adds
> such capability in the future.
> - Question 1: why do you plan to use a 10gbe switch with a single
> connection to the host PC?  Why not 

[USRP-users] Lookup error: Path not found in tree

[Pratik Chatterjee via USRP-users]

I am building a repeater from the UHD and I have Nick's post as reference.
My intended flow graph will be:

*radio_rx->gain_block(to remove timestamps)->radio_tx*

But I keep getting a lookup error (attached). I have isolated the line of
error (line 196)
however I have not been able to correct it. Is there anything wrong
fundamentally in my approach and what does the error mean:

*Error: LookupError: Path not found in tree:
/mboards/0/dboards/B/tx_frontends/freq/value*

Output log: https://paste.ubuntu.com/p/gSnFQCDn9q/
Code: https://paste.ubuntu.com/p/XcFq3PNhZw/
usrp-probe: https://paste.ubuntu.com/p/ps6cRbRH3j/
usrp-probe-tree: https://paste.ubuntu.com/p/VMCWHkn3hW/
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] N310 and gpsdo strange behavior

[Daniel Jepson via USRP-users]

Hi Rob,

Thanks for the heads up on the documentation bug. While digging through it
I also noticed a bug in the White Rabbit arguments. WR disciplines the
internal oscillator, so that must be explicitly selected. Below is the
correct clock/time combination to enable WR:

auto usrp =
uhd::usrp::multi_usrp::make("type=n3xx,clock_source=internal,time_source=sfp0");

-Daniel

On Thu, Aug 2, 2018 at 10:32 PM, Rob Kossler via USRP-users <
usrp-users@lists.ettus.com> wrote:

> One more small thing The device arguments "time_source" and
> "clock_source" are not listed in the device arguments table in the UHD
> manual (http://files.ettus.com/manual/page_usrp_n3xx.html#
> n3xx_usage_device_args).  They are, however, shown as examples in the
> clock/time synchronization section (http://files.ettus.com/
> manual/page_usrp_n3xx.html#n3xx_synchronization). Updating the table
> would be helpful.
>
> Rob
>
> On Thu, Aug 2, 2018 at 10:48 PM Rob Kossler  wrote:
>
>> I am learning to use the gpsdo capability of the N310 and I stumbled upon
>> something strange. I have a capability in my software for displaying a
>> message every time the "last PPS" value changes. Note that during startup,
>> I set the clock to zero on a PPS trigger.
>>
>> If I set "time_source=internal,clock_source=internal", I get the
>> following expected behavior
>> Mboard 0 last PPS time: 3
>> Mboard 0 last PPS time: 4
>> Mboard 0 last PPS time: 5
>> Mboard 0 last PPS time: 6
>> Mboard 0 last PPS time: 7
>> Mboard 0 last PPS time: 8
>> Mboard 0 last PPS time: 9
>> Mboard 0 last PPS time: 10
>> Mboard 0 last PPS time: 11
>> Mboard 0 last PPS time: 12
>> Mboard 0 last PPS time: 13
>>
>> But if I set "time_source=gpsdo,clock_source=gpsdo", I get the following
>> unexpected behavior
>> Mboard 0 last PPS time: 2.9998
>> Mboard 0 last PPS time: 3.9998
>> Mboard 0 last PPS time: 4.9998
>> Mboard 0 last PPS time: 5.9997
>> Mboard 0 last PPS time: 6.9997
>> Mboard 0 last PPS time: 7.9996
>> Mboard 0 last PPS time: 8.9996
>> Mboard 0 last PPS time: 9.9995
>> Mboard 0 last PPS time: 10.9995
>> Mboard 0 last PPS time: 11.9994
>> Mboard 0 last PPS time: 12.9994
>>
>> Note that the time is slowly "walking". It seems that the PPS and 10MHz
>> (driving the clock ticking) aren't synced.  Any suggestions?
>>
>> BTW, I verified that the sensor "gps_locked" was true before running this
>> code.  I included the source code below for this functionality.
>>
>> stop_signal_called = false;
>> std::vector dbl_vec(usrp->get_num_mboards());
>> std::cout << "Press Ctrl + C to stop looping..." << std::endl;
>> while (not stop_signal_called) {
>> for (size_t iboard = 0; iboard < usrp->get_num_mboards();
>> iboard++) {
>> std::cout << boost::format("Mboard %d last PPS time:
>> %g") % iboard % usrp->get_time_last_pps(iboard).get_real_secs() <<
>> std::endl;
>> dbl_vec[iboard] = usrp->get_time_last_pps(
>> iboard).get_real_secs();
>> }
>> while (not stop_signal_called and
>> usrp->get_time_last_pps(0).get_real_secs() == dbl_vec[0])
>> boost::this_thread::sleep(boost::posix_time::
>> milliseconds(1));
>> }
>>
>>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>


-- 

Daniel Jepson

Digital Hardware Engineer

National Instruments



O: +1.512.683.6163

daniel.jep...@ni.com
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP2r4 \w RFX2400 fails with UHD3.14

[Johannes Demel via USRP-users]

Hi all,

we just got new X310s and wanted to use them with the latest UHD 
version. They work. That's great. But we have some old USRP2s as well. 
And we want to use them with the same driver version.

We ran 'uhd_usrp_probe' for all of them. The output is below.

Essentially, there seems to be a problem with the daughterboard manager. 
We had the same experience with UHD3.12

---
[ERROR] [DBMGR] The daughterboard manager encountered a recoverable 
error in init.

Loading the "unknown" daughterboard implementations to continue.
The daughterboard cannot operate until this error is resolved.
LookupError: KeyError: key "0" not found in dict(i, 
N14adf4360_regs_t17prescaler_value_tE)

---

Also, with the latest UHD3.14 we have this new problem
-
[ERROR] [UHD] Exception caught in safe-call.
  in virtual usrp2_fifo_ctrl_impl::~usrp2_fifo_ctrl_impl()
  at /usr/local/src/uhd/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp:54
this->peek32(0); -> RuntimeError: fifo ctrl timed out looking for acks
-

Let me know if you need any more info. So far we couldn't find a 
solution to our problems here. I hope someone can point us in the 
correct direction to fix these errors.


Cheers
Johannes



Error for USRP2 with UHD3.14

[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.14.0.0-31-g98057752

[INFO] [USRP2] Opening a USRP2/N-Series device...
[INFO] [USRP2] Current recv frame size: 1472 bytes
[INFO] [USRP2] Current send frame size: 1472 bytes
[ERROR] [DBMGR] The daughterboard manager encountered a recoverable 
error in init.

Loading the "unknown" daughterboard implementations to continue.
The daughterboard cannot operate until this error is resolved.
LookupError: KeyError: key "0" not found in dict(i, 
N14adf4360_regs_t17prescaler_value_tE)


EnvironmentError: OSError: error in pthread_setschedparam
[ERROR] [UHD] Exception caught in safe-call.
  in virtual usrp2_fifo_ctrl_impl::~usrp2_fifo_ctrl_impl()
  at /usr/local/src/uhd/host/lib/usrp/usrp2/usrp2_fifo_ctrl.cpp:54
this->peek32(0); -> RuntimeError: fifo ctrl timed out looking for acks
-


As a reference. Here is the output for other setups that work.

Working USRP2 with UHD3.10
--
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.HEAD-0-gc705922a


-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes

EnvironmentError: OSError: error in pthread_setschedparam
  _
 /
|   Device: USRP2 / N-Series Device
| _
|/
|   |   Mboard: USRP2 r4
|   |   hardware: 1024
[]
|   |   FW Version: 12.3
|   |   FPGA Version: 10.0
|   |
|   |   Time sources:  none, external, _external_, mimo
|   |   Clock sources: internal, external, mimo
|   |   Sensors: mimo_locked, ref_locked
[]
|   | _
|   |/
|   |   |   RX Dboard: A
|   |   |   ID: RFX2400 (0x0027)
|   |   | _
|   |   |/
|   |   |   |   RX Frontend: 0
|   |   |   |   Name: RFX2400 RX
|   |   |   |   Antennas: TX/RX, RX2, CAL
|   |   |   |   Sensors: lo_locked
|   |   |   |   Freq range: 2300.000 to 2900.000 MHz
|   |   |   |   Gain range PGA0: 0.0 to 70.0 step 0.0 dB
|   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
|   |   |   |   Connection Type: QI
|   |   |   |   Uses LO offset: No
|   |   | _
|   |   |/
|   |   |   |   RX Codec: A
|   |   |   |   Name: ltc2284
|   |   |   |   Gain Elements: None
[]



Working X310
--
[INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_3.14.0.0-31-g98057752

[INFO] [X300] X300 initialization sequence...
[INFO] [X300] Maximum frame size: 1472 bytes.
[INFO] [X300] Radio 1x clock: 200 MHz
[INFO] [GPS] No GPSDO found
[INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 0xF1F0D000)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1316 MB/s)
[INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1306 MB/s)
[INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD1001)
[INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
[INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
[INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
  _
 /
|   Device: X-Series Device
| _
|/
|   |   Mboard: X310
|   |   revision: 11

Re: [USRP-users] UHD API

[TIMMEN Koen via USRP-users]

De : Brian Padalino [mailto:bpadal...@gmail.com]
Envoyé : jeudi 2 août 2018 16:57
À : TIMMEN Koen
Cc : USRP-users@lists.ettus.com
Objet : Re: [USRP-users] UHD API


First, let me tell you that I've done this exact thing so it's very possible.  
I also agree the current examples are poor in the UHD repository when dealing 
with most anything for RFNoC.

How did you setup your block to start and stop the transmission?  It sounds 
like maybe it's controlled using the settings registers?  A little more 
information about how you want to control your block would be useful here.

That is very good to hear.

Indeed the block is controlled through the settings registers. Sample 
generation can start by setting a certain value in a register, samples are then 
stored in a AXI FIFO at the end of the block. When the block is fully 
activated, the FIFO will communicate with the downstream block as normal.

Streaming sends the data down to your block and the block receives it over the 
main AXI streaming interface.  It's meant for larger data sets, but it isn't 
limited to that.

Have you created your own custom C++ controller block, or are you using the XML 
definition to control your block?  I write my own C++ controller blocks, 
personally, and the XML is only there for defining the ID and the input/output 
ports.

So streaming is communication from Host PC to your USRP? Not 
between two NoC blocks for example?

Since I figured I only needed ‘sr_write’ and this is available from the 
standard block controller, I did not code my own. I did verify the writing to 
the registers using the readback register and that seems to work just fine.

For what reason would you recommend me writing my own block controller?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com