Re: [USRP-users] USRP X310 GPS or IEEE 1588 Synchronization

[akin soysal via USRP-users]

Hello,

I know that the 10GbE ethernet interface is adding an extra 500us round
trip time delay with fiber DAC. I tested it myself. 1 GbE would probably
give a similar delay as well. So do you think it would stay below our delay
budget of 250us?

Regards,
Akın

On Fri, 1 Mar 2019 00:24 Nate Temple  Hi Rob,
>
> Yes, that's correct, you can use the WR-LEN with the X310.
>
> Regards,
> Nate Temple
>
>
>
>
>
>
> On Wed, Feb 27, 2019 at 12:40 PM Rob Kossler  wrote:
>
>> Nate,
>> Although the X3xx series to not natively support White Rabbit, I believe
>> that they can get all of the benefits by using a WR-LEN in close proximity
>> to the X310.  Is that correct?
>>
>> Rob
>>
>> On Wed, Feb 27, 2019 at 11:45 AM Nate Temple via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hi Akin,
>>>
>>> The Octoclock-G would be suitable for this purpose, and yes, it does
>>> contain a GPSDO (OCXO). https://kb.ettus.com/GPSDO#GPSDO_.28OCXO.29
>>>
>>> The Octoclock-G does not contain an antenna, you must provide one to the
>>> GPS Antenna input (SMA).
>>>
>>> The X3xx series do not support IEEE 1588, however, the N3xx series USRPs
>>> do support White Rabbit, which is an extension of the IEEE-1588-2008
>>> standard. More info can be found here on it
>>> https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
>>>
>>>
>>> Regards,
>>> Nate Temple
>>>
>>> On Wed, Feb 27, 2019 at 8:31 AM akin soysal via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hello All,


 I have a question. We want to synchronize the clock of the two USRP
 X310s with a GPS or IEEE 1588 standard. I would like to synchronize the two
 USRPs with each other so that the base station and user terminal would not
 experience any synchronization issue. I also would like to synchronize one
 of the USRP X310s with an external base station, which supports IEEE 1588
 and GPS clocks, and we have a synchronization budget of about *250us*.


 I learned that the setup that worked in France is using the following
 Ettus product:


 https://www.ettus.com/product/details/OctoClock-G


 Do you think that this would suffice for our needs? It has its own GPS
 clock and antenna inside, right? It is compatible with USRP X310?


 I know that the product specification does not include IEEE 1588, so I
 am concluding that it would not be possible to use this standard for our
 scenario, do you agree?

 Thanks and regards,

 Akın
 ___
 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
>>>
>>
___
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 GPS or IEEE 1588 Synchronization

[Nate Temple via USRP-users]

Hi Rob,

Yes, that's correct, you can use the WR-LEN with the X310.

Regards,
Nate Temple






On Wed, Feb 27, 2019 at 12:40 PM Rob Kossler  wrote:

> Nate,
> Although the X3xx series to not natively support White Rabbit, I believe
> that they can get all of the benefits by using a WR-LEN in close proximity
> to the X310.  Is that correct?
>
> Rob
>
> On Wed, Feb 27, 2019 at 11:45 AM Nate Temple via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi Akin,
>>
>> The Octoclock-G would be suitable for this purpose, and yes, it does
>> contain a GPSDO (OCXO). https://kb.ettus.com/GPSDO#GPSDO_.28OCXO.29
>>
>> The Octoclock-G does not contain an antenna, you must provide one to the
>> GPS Antenna input (SMA).
>>
>> The X3xx series do not support IEEE 1588, however, the N3xx series USRPs
>> do support White Rabbit, which is an extension of the IEEE-1588-2008
>> standard. More info can be found here on it
>> https://kb.ettus.com/Using_Ethernet-Based_Synchronization_on_the_USRP%E2%84%A2_N3xx_Devices
>>
>>
>> Regards,
>> Nate Temple
>>
>> On Wed, Feb 27, 2019 at 8:31 AM akin soysal via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> Hello All,
>>>
>>>
>>> I have a question. We want to synchronize the clock of the two USRP
>>> X310s with a GPS or IEEE 1588 standard. I would like to synchronize the two
>>> USRPs with each other so that the base station and user terminal would not
>>> experience any synchronization issue. I also would like to synchronize one
>>> of the USRP X310s with an external base station, which supports IEEE 1588
>>> and GPS clocks, and we have a synchronization budget of about *250us*.
>>>
>>>
>>> I learned that the setup that worked in France is using the following
>>> Ettus product:
>>>
>>>
>>> https://www.ettus.com/product/details/OctoClock-G
>>>
>>>
>>> Do you think that this would suffice for our needs? It has its own GPS
>>> clock and antenna inside, right? It is compatible with USRP X310?
>>>
>>>
>>> I know that the product specification does not include IEEE 1588, so I
>>> am concluding that it would not be possible to use this standard for our
>>> scenario, do you agree?
>>>
>>> Thanks and regards,
>>>
>>> Akın
>>> ___
>>> 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
>>
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC FFT size > 1024

[Rob Kossler via USRP-users]

Hi,
I would like to implement an RFNoC FFT that can work for lengths > 1024.
Here's what I think I know:

   - Current size for CE-to-CE packets is restricted to 8000 bytes (2000
   samples)
   - Current RFNoC FFT size is tied to packet size and thus 1024 is the max
   FFT size that can fit in a packet

After reviewing previous posts and Xilinx FFT IP core documentation, it
seems that all I need to do is add packet resize logic at the input and
output of the block.  Specifically, I am thinking of using
"packet_resizer.v" at both input and output (but only modifying tuser in
the output instance).

Questions

   - Is this a good approach?
   - Anything special that I need to take care of?
   - Does the selection of FFT architecture (pipelined, radix-4, etc) have
   any relevance concerning this issue?

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

Re: [USRP-users] Hardware clocks, X310

[Jason Matusiak via USRP-users]

Cherif.  I will attempt to take a stab at a few of your questions.  Don't take 
my answers as 100% right

1 - All the blocks run at the same rate, but I am pretty sure you can implement 
an MMCM within your block to lower the rate for your needs and then back up to 
the crossbar rate.  Don't quote me, but I feel like I had this conversation 
with someone a few years back on the mailing list.
2 - The ADC/DAC are tied to the master clock rate (in the case of the X310, 
either 186.32MHz, or 200MHz)
3 - I don't believe so unless you do what I mentioned in the first comment.

All that said, I believe a lot of stuff can be tweaked under the hood, but it 
is hard to say what that will break, and it isn't exactly supported.


From: USRP-users  on behalf of Cherif Diouf 
via USRP-users 
Sent: Thursday, February 28, 2019 10:05 AM
To: usrp-users@lists.ettus.com
Subject: [USRP-users] Hardware clocks, X310


Hello guys,



I am a researcher working with the X310 USRP. I have a couple of questions 
regarding the Hardware clocks.

The bus_clock and radio_clk are by default respectively set at 166 MHz and 200 
MHz.

And if I am right the crossbar clock ce_clk is also at 200 MHz. Is there a 
solution to bring it down to ce_clk = 50 MHz, in that case

1)  Does it mean that all the Kintex XC410T blocks will run at 50 MHz ? Is 
this safe?

2)   What about the ADC and DAC and their sampling clock?

3)  Finally can we have different RFnoc blocks running at different clock 
frequencies and still have the  crossbar  running at a given clock frequency?



Best Regards

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

Re: [USRP-users] Hardware clocks, X310

[Ian Buckley via USRP-users]

Cherif,
1) Changing the radio clock frequency is not simple and would leave you an 
immense amount of knock on problems to address.
2) ADC and DAC are tightly coupled to the radio clk, they run on low jitter 
versions of the same clock.
3) Absolutely, and that is the beauty of streaming style packet buses like the 
AXI4 stream protocol that the X310 is built around. It’s a relatively easy task 
to cross this type of bus into a different clock domain, do work on the 
payload, and cross it back. The modular RTL code supplied by Ettus already 
contains all the functional blocks you would need to do this.

So saying that it’s always a good thing to minimize the number of clock domains 
in a design as it adds significant overhead and complexity, not to mention a 
verification burden. Evaluate hard if you really need another frequency, 
especially when its an integer fraction of a clock that already exists. 200MHz 
is not a hard frequency to attain in Virtex-7 with well designed logic. 
-Ian


> On Feb 28, 2019, at 7:05 AM, Cherif Diouf via USRP-users 
>  wrote:
> 
> Hello guys,
>  
> I am a researcher working with the X310 USRP. I have a couple of questions 
> regarding the Hardware clocks.
> The bus_clock and radio_clk are by default respectively set at 166 MHz and 
> 200 MHz.
> And if I am right the crossbar clock ce_clk is also at 200 MHz. Is there a 
> solution to bring it down to ce_clk = 50 MHz, in that case
> 1)  Does it mean that all the Kintex XC410T blocks will run at 50 MHz ? 
> Is this safe?
> 2)   What about the ADC and DAC and their sampling clock?
> 3)  Finally can we have different RFnoc blocks running at different clock 
> frequencies and still have the  crossbar  running at a given clock frequency?
>  
> Best Regards
> Cherif
> ___
> 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

[USRP-users] Hardware clocks, X310

[Cherif Diouf via USRP-users]

Hello guys,

I am a researcher working with the X310 USRP. I have a couple of questions 
regarding the Hardware clocks.
The bus_clock and radio_clk are by default respectively set at 166 MHz and 200 
MHz.
And if I am right the crossbar clock ce_clk is also at 200 MHz. Is there a 
solution to bring it down to ce_clk = 50 MHz, in that case

1)  Does it mean that all the Kintex XC410T blocks will run at 50 MHz ? Is 
this safe?

2)   What about the ADC and DAC and their sampling clock?

3)  Finally can we have different RFnoc blocks running at different clock 
frequencies and still have the  crossbar  running at a given clock frequency?

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

Re: [USRP-users] Combining bandwidth of two B200

[Marcus D. Leech via USRP-users]

On 02/28/2019 01:30 AM, Arun kumar Verma via USRP-users wrote:

Dear User

I am trying to combine bandwidth of two USRP B200 and get the final 
bandwidth of around 100MHz. Our target is monitor the complete WiFi 
band 2.4-2.5Ghz.


I am attaching the image file for grc file. Any suggestions?

Arun

Use the rotator block to shift the basebands instead of your "signal 
source + multiplier"


Also, you'll need a very fast computer to do this.


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

Re: [USRP-users] Passing arguments to an RFNOC block

[Paul Boven via USRP-users]

Hi Jonathon,

Thanks for looking at the block, and spotting the mistake.
Unfortunately that doesn't stop the swig part from failing, so I'll keep 
digging further.


Regards, Paul Boven.

On 28/02/2019 04:19, Jonathon Pendlum wrote:

Hi Paul,

Your Nocscript has an error on line 47, you are a missing a comma: 
LE($config 1) should be LE($config, 1). That may not be the source of 
your issue, but try fixing that first.


Jonathon

On Thu, Feb 28, 2019 at 1:14 AM Paul Boven via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi everyone,

As part of the VLBI[1] backend that I'm making in RFNOC, my first step
is to make a rational resampler. It takes the 100MS/s signal from a
TwinRX, and reduces it to 80MS/s. This can be done with a 5:4
resampler.
In order to make this work, I'm using the axi_rate_change block.

Although the block works in simulation, I keep running into problems
with the GRC integration, in particular SWIG throwing run-time errors.

The problem seems to be in the way that the arguments (N, M, config)
are
passed around, but studying other blocks like the DDC block hasn't
provided the clues for me to get past this hurdle.

The resampler itself does work, which I tested by having it emit zeroes
instead of the 'deleted' samples, and using a 'keen 1 in N' in GRC
itself.

At the moment, the block exits in VLBI_swig.py in set_arg:
return _VLBI_swig_resamplerd5x4_sptr_set_arg(self, *args)
RuntimeError: SyntaxError: Parsing Stopped at: $N, 5)

If you're familiar with RFNOC, can you please have a look at:

http://www.jive.nl/~boven/rfnoc-VLBI

It contains the source, and also a compiled bitfile for the X310 for
your convenience (but use at your own risk, of course).

Regards, Paul Boven.

[1] Very Long Baseline Interferometry

___
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