[USRP-users] Re: UHD -RFNoC graph construction

[Jonathon Pendlum]

Hello Arjan,

This is a known issue and a fix for it should be released in the next few
weeks on the UHD master branch. Another option is to revert to UHD 3.15
until the fix is released.

Jonathon

On Sat, May 29, 2021 at 11:08 AM  wrote:

> Hi all, I'm trying to build an RFNoC graph (x300 with a TwinRX radio
> module):
>
> import uhd
>
> graph = uhd.rfnoc.RfnocGraph("addr=192.168.10.2")
>
> sa = uhd.usrp.StreamArgs("fc32", "sc16")
>
> rx_streamer0 = graph.create_rx_streamer(1, sa)
> rx_streamer1 = graph.create_rx_streamer(1, sa)
>
> graph.connect("0/Radio#0", 0, "0/DDC#0", 0, False)
> graph.connect("0/Radio#0", 1, "0/DDC#0", 1, False)
>
> graph.connect("0/DDC#0", 0, rx_streamer0, 0)
> graph.connect("0/DDC#0", 1,  rx_streamer1, 0)
>
> graph.commit()
>
> after the “*graph.commit()*” instruction, it the code complains with the
> following error message:
>
>[ERROR] [RFNOC::GRAPH::DETAIL] 0/DDC#0: RfnocError: ResolveError: 
> Attempting to overwrite property `mtu@INPUT_EDGE:1' with a new value after it 
> was locked!
>
> Traceback (most recent call last):
>
>   File "script2.py", line 62, in 
>
> graph.commit()
> RuntimeError: RfnocError: ResolveError: Attempting to overwrite property 
> `mtu@INPUT_EDGE:1' with a new value after it was locked!
>
> Does anyone have any experience or any hints in creating an rfnoc graph
> using the UHD python API?
>
> Best regads,
>
> Arjan Feta
> ___
> 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] Re: Center frequency drift on USRP B-series even with Octoclock

[Viktor Erdelyi]

Hi Aneesh,

Thanks for your comment. I used a Intel(R) Core(TM) i7-8850H CPU for the 
B-series experiment (which is somewhat weaker than the "AMD Ryzen 9 
3900X 12-Core Processor" I used with the X310s, but the sampling rate 
was only 1MHz in both cases, so it should be fine). The software is 
basically a (self-made) JVM-based controller that communicates over 
sockets with a (self-made) C++-based server that uses UHD 4.0 under the 
hood. The whole thing is running on CentOS/Fedora. I attached the 
terminal outputs in case it helps, but I don't see any overruns/underruns.


As for the use case, I'm trying to use this to compare phase offsets 
across different receiver locations (given a fixed transmitter), so I 
need a constant (and ideally zero) frequency offset, otherwise the IQ 
vector keeps rotating back and forth as the frequencies drift apart.


Best regards,
Viktor

On 6/3/21 8:53 PM, aneesh patel wrote:

Viktor,

Cool benchmark.

Do you have some specifics on what's driving the b-series like host 
CPU specs, software, any stdout output like overruns etc.?


There seems to be an issue with the external clock implementation on 
the b series unless that's actually how it's supposed to look (!).


For the for factor, power, price, etc. I'd say the internal looks 
pretty good for *most things.


Best of luck. Hopefully someone with experience chines in on the setup!

Aneesh


Sent from Yahoo Mail on Android 



On Thu, Jun 3, 2021 at 7:37 AM, Viktor Erdelyi
 wrote:

Dear all,

First post here. I have done some measurements with USRP B-series
and X-series, and I noticed that, in the case of the B-series, the
center frequency drifts even with an Octoclock 10MHz REF. (The
drift is smaller than without Octoclock, though.) Is this
expected? Is the X-series just so much better, or is there
something else going on?

Details of the experiment:

  * I sent a sine wave (constant I, constant Q) from one USRP to
another at 5.9GHz and looked at the spectrogram of the
received signal. The ideal result of such an experiment would
be a straight vertical line at 0 Hz (i.e. 5.9GHz).
  * I added an image of the relevant spectrograms below. The left
side of the figure is TX = USRP B205, RX = USRP B210, internal
vs. external (Octoclock) REF. The right side of the figure is
TX = USRP X310, RX = (another) USRP X310, internal vs.
external (Octoclock) REF.
  * The two X310s have UBX-160 daughterboards.
  * I check for LO_locked and ref_locked before doing TX/RX.

I would appreciate any insights.

Thanks,
Viktor


___
USRP-users mailing list -- usrp-users@lists.ettus.com

To unsubscribe send an email to usrp-users-le...@lists.ettus.com


=== Controller output 
===
19:25:00.237 [main] INFO USRPNativeClient - Setting 10MHz REF source to external
19:25:00.239 [main] INFO USRPNativeClient - Setting PPS source to internal
19:25:00.240 [main] INFO main.radio.USRPMaker - Configuring USRP B205mini for 
TX...
19:25:00.241 [main] INFO USRPNativeClient - Setting TX subdevice to A:A
19:25:00.273 [main] INFO USRPNativeClient - Setting TX Gain to 60.0
19:25:00.316 [main] INFO USRPNativeClient - Setting TX SamplingRate to 1 MHz
19:25:00.676 [main] INFO USRPNativeClient - Setting TX Antenna to TX/RX
19:25:00.677 [main] INFO USRPNativeClient - Setting TX Bandwidth to 5.6E7
19:25:00.679 [main] INFO USRPNativeClient - Setting up TX streamer
19:25:02.622 [main] INFO USRPNativeClient - Setting 10MHz REF source to external
19:25:02.629 [main] INFO USRPNativeClient - Setting PPS source to internal
19:25:02.630 [main] INFO main.radio.USRPMaker - Configuring USRP B210_RF_A for 
RX...
19:25:02.630 [main] INFO USRPNativeClient - Setting RX subdevice to A:A
19:25:02.663 [main] INFO USRPNativeClient - Setting RX Gain to 76.5
19:25:02.705 [main] INFO USRPNativeClient - Setting RX SamplingRate to 1 MHz
19:25:03.157 [main] INFO USRPNativeClient - Setting RX Antenna to RX2
19:25:03.158 [main] INFO USRPNativeClient - Setting RX Bandwidth to 5.6E7
19:25:03.202 [main] INFO USRPNativeClient - Setting up RX streamer
19:25:03.270 [DefaultDispatcher-worker-2] INFO USRPNativeClient - Setting USRP 
time to 0.0 NOW
19:25:03.273 [DefaultDispatcher-worker-3] INFO USRPNativeClient - Setting USRP 
time to 0.0 NOW
19:25:03.315 [DefaultDispatcher-worker-3] INFO USRPNativeClient - Getting USRP 
time --> 0.002631
19:25:03.315 [DefaultDispatcher-worker-1] INFO USRPNativeClient - Getting USRP 
time --> 0.04193
19:25:03.319 [main] INFO DeviceSynchronizer - Sync er

[USRP-users] Re: Center frequency drift on USRP B-series even with Octoclock

[aneesh patel via USRP-users]

Great info and thanks for the use case. Makes sense for the precision you need 
for your situation.
Since really it's just IO, basic driver calls, and instrumentation and your 
specs support all of that (assuming no weird nuances / I say this to cover 
myself ha), your sample methods seems great. 
Given there is no issue with the b-series hardware (I actually can't recall if 
that's in spec for real life use cases but I actually learned something here 
from looking at your charts if it is), it seems you need the higher precision X 
series to get right to work unless there is a whiz-bang solution for realtime 
clock drift corrections at the precision you need for the b-series.
Best of luck! Lots of experience in this forum.
Aneesh 
Sent from Yahoo Mail on Android 
 
  On Thu, Jun 3, 2021 at 8:39 AM, Viktor Erdelyi 
wrote:   ___
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] Re: Center frequency drift on USRP B-series even with Octoclock

[Marcus D Leech]

Different synthesizers have different phase noise properties. 

I suspect that if so the same test at lower frequencies on the B2xx things will 
improve. 

Also the external-clock PLL in the B205 is much poorer than on the other family 
members—B200 and B210. 

Sent from my iPhone

> On Jun 3, 2021, at 9:05 AM, aneesh patel via USRP-users 
>  wrote:
> 
> 
> Great info and thanks for the use case. Makes sense for the precision you 
> need for your situation.
> 
> Since really it's just IO, basic driver calls, and instrumentation and your 
> specs support all of that (assuming no weird nuances / I say this to cover 
> myself ha), your sample methods seems great. 
> 
> Given there is no issue with the b-series hardware (I actually can't recall 
> if that's in spec for real life use cases but I actually learned something 
> here from looking at your charts if it is), it seems you need the higher 
> precision X series to get right to work unless there is a whiz-bang solution 
> for realtime clock drift corrections at the precision you need for the 
> b-series.
> 
> Best of luck! Lots of experience in this forum.
> 
> Aneesh 
> 
> Sent from Yahoo Mail on Android
> 
> On Thu, Jun 3, 2021 at 8:39 AM, Viktor Erdelyi
>  wrote:
> ___
> 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 mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com

[USRP-users] Re: Center frequency drift on USRP B-series even with Octoclock

[Viktor Erdelyi]

You're right Marcus, 0.9GHz seems to be better indeed (see image). Also 
thanks for the input on the B205 PLL.


May I ask in what way phase noise can affect the signal's frequency? 
According to an NI webpage [1], it "deals with very short time scales 
and produces effects that look more like unwanted modulation changing 
the shape of the waveform rather than a wandering frequency". Am I 
missing something?


[1] 
https://www.ni.com/en-us/innovations/white-papers/20/global-synchronization-and-clock-disciplining-with-ni-usrp-293x-.html


Thanks,
Viktor


___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com