Re: [USRP-users] [ Possible Spam ] Re: 4 Rx channels from an X310

[Josh Sendall via USRP-users]

Hi Derek,

Thanks for answering my question. That is good to hear, but does this
not apply to the BasicRx?  

When I try to use the subdevice spec "A:A A:B" (i.e. to use the same
sampling setup as a a TwinRx) with a BasicRx I get a
"uhd::assertion_error". If it is not currently supported could it be
fixed by modifying the host-side code?

Kind regards,Joshua Sendall


>>> Derek Kozel  12/09/2017 18:30 >>>
[ This email could possibly be spam. Only open if you are expecting
this mail. This sender does not have a SPF record configured for their
domain. The purpose of an SPF (Sender policy framework) record is to
prevent spammers from sending messages with forged “From” addresses from
the originating domain. It also identifies which mail servers are
permitted to send email on behalf of your domain. ]
Hello Joshua,

The default FPGA image now has two DDCs which each have two DSP chains.
The message you link to is from 2014 and we've substantially updated the
contents of the FPGA since then. Currently the TwinRX is the primary
daughtercard making use of these additional DDC chains as the others are
1RX per daughtercard.

Regards,
Derek

On Tue, Sep 12, 2017 at 3:15 AM, Josh Sendall via USRP-users
 wrote:


Hi all,

I have been looking through some previous posts on the mailing list,
for example [USRP-users] subdev spec for two channels with USRP X310
(
http://http//lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-July/010010.html)
 which suggests that it should not be possible to receive 4 channels
(with the standard FPGA image and UHD) on an X300/X310, due to them only
having 2 DDC blocks.

However I then saw this project 
( https://github.com/EttusResearch/gr-doa) (gr-doa), which seems to
suggest that, using the standard FPGA image, one can run 4 channels
using 2 TwinRx daughter boards. Would that not still require 4 DDC
blocks, or can a DDC block be configured to process 2 real streams?

Kind regards,
Joshua Sendall 




Joshua Sendall
Radar Signal Analyst
Defense, Peace, Safety and Security (DPSS)
Council for Scientific and Industrial Research (CSIR) 
Building 44 - Room C 433
CSIR, Meiring Naude Road, Pretoria 
Tel: 012 841 3575



This message is subject to the CSIR's copyright terms and conditions,
e-mail legal notice, and implemented Open Document Format (ODF)
standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.

Please consider the environment before printing this email.

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



--

This message is subject to the CSIR's copyright terms and conditions, e-mail 
legal notice, and implemented Open Document Format (ODF) standard. 
The full disclaimer details can be found at 
http://www.csir.co.za/disclaimer.html. 

Please consider the environment before printing this email. <>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Support with setting usrp sampling rate to 150MSPS

[Snehasish Kar via USRP-users]

Hi,


I am capturing 75 MHz using 100 MSps sample rate as well as using 200 MSps 
sample rate but I am not getting the near-end bands with 100 MSps while I am 
getting those with 200 MSps. What I have done is capture the data and then pass 
it through a polyphase channelizer to give me 200 K bandwidth channels and then 
I am upsampling that data to 1 MSps or 2 Msps and passing through gr-gsm 
receiver. With 200 MSps I am getting correct data whereas with 100 MSps I am 
not. But according to usrp specs my sampling rate as 1.25*75 MHz should be 
enough but that is not happening. Please help.


Regards,

Snehasish


From: Derek Kozel 
Sent: Wednesday, August 23, 2017 12:15:11 PM
To: Koyel Das
Cc: Snehasish Kar; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] Support with setting usrp sampling rate to 150MSPS

Hello Koyel,

This is a fundamental problem that increasing sample rate takes more processing 
power to handle but provides more bandwidth of spectrum. How wide is the signal 
you need to process? The general recommendation is that you sample at 1.25 
times your bandwidth. This provides 20% more spectrum than is necessary, but 
means that your signal is minimally affected by the digital filters used in the 
decimation in the FPGA. This is part of how the 160 MHz bandwidth of the UBX is 
derived from the 200 MHz sampling rate of an X310 (what is inside the 2954R).

The default FPGA image is limited to integer decimation rates as described in 
the manual.
http://files.ettus.com/manual/page_general.html#general_sampleratenotes

GSM 1800 covers 170 MHz so even with the full sampling rate the outermost edges 
will be attenuated by both the analog filters and the digital filters. If you 
only want to look at the uplink or downlink individually then you can observe 
the 75 MHz bandwidth with 100 MS/s and easily meet the recommended maximum of 
80% occupied bandwidth.

For non-integer decimation rates such as 200e6/150e6 = 4/3 you would have to 
implement a rational resampler as a custom RFNoC block to support that 
decimation rate, certainly possible but additional work.

Regards,
Derek

On Wed, Aug 23, 2017 at 7:17 AM, Koyel Das 
mailto:koyel@vehere.com>> wrote:
Hi,

Many thanks for your reply. Yes 200 MSps works.

But taking 200 MSps will increase the amount of data considerably and increase 
the processing time and very less amount of data is decoded from large amount 
of input samples compared to lower sampling frequencies. What is the solution 
to these problems?

Regards,
Koyel

On Tue, Aug 22, 2017 at 9:14 PM, Snehasish Kar 
mailto:snehasish@live.com>> wrote:
Ok I will try that.

BR
Snehasish

On 22-Aug-2017, at 8:51 PM, Derek Kozel 
mailto:derek.ko...@ettus.com>> wrote:

Try 200MS/s. The FPGA can only decimate integer amounts from the ADC rate, 
which is 200MS/s.

On Tue, Aug 22, 2017 at 5:15 PM, Snehasish Kar via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:
Hello
I am trying to receive gsm 1800 band using NI USRP 2954R, but when I am trying 
to set the sampling rate of uhd_source in gnuradio to 150 MSPS, it's giving an 
error message saying hardware does not support sampling rate above 100MSPS.

Please help!

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




--

Koyel Das

Senior Product Engineer

Vehere | Proactive Communications Intelligence & Cyber Defence

M: +919051132173 | T: +91 33 
24008400 | F: +91 33 247988100 | W: 
www.vehere.com


Vehere is the proud recipient of the Fastest Growing Technology Company Awards 
in India & Asia since 2012!


The content of this e-mail is confidential and intended solely for the use of 
the addressee. The text of this email (including any attachments) may contain 
information, which is proprietary and/or confidential or privileged in nature 
belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ 
subsidiaries. If you are not the addressee, or the person responsible for 
delivering it to the addressee, any disclosure, copying, distribution or any 
action taken or omitted to be taken in reliance on it is prohibited and may be 
unlawful. If you have received this e-mail in error, please notify the sender 
and remove this communication entirely from your system. The recipient 
acknowledges that no guarantee or any warranty is given as to completeness and 
accuracy of the content of the email. The recipient further acknowledges that 
the views contained in the email message are those of the sender and may not 
necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and 
accessing the attachment please check and scan for virus. WARNING: Computer 
viruses can be transmitted via email. The recipient should check this email and 
any attachments for the presence of viruses. The company acc

[USRP-users] Building FPGA image containing OOT blocks using Vivado

[Torres Figueroa, Luis Angel via USRP-users]

Hi Jason/folks,

Do you know how to generate an FPGA image from Vivado GUI that includes an OOT 
block created using rfnocmodtool?

I created an OOT block using rfnocmodtool, run a testbench to verify that it 
was ok, then generated a bit file with the uhd_image_builder.py script and 
programmed it onto the USRP successfully: I could see the custom block listed 
among the RFNoC blocks.

However, when trying to create the same image from Vivado modifying the 
rfnoc_ce_auto_inst_x300.v file by including my own block and adding the 
dependent Verilog files to the design, even though I can run the 
synthesis/implementation and generate a bit file, after loading it to the URSP 
I can’t see any block.

Do you know whether I have to modify some extra files apart from the 
rfnoc_ce_auto_inst_x300.v? The purpose behind this is to build images of new 
OTT blocks using exclusively Vivado GUI.

Best,
Luis

Von: Jason Matusiak 
Datum: Freitag, 18. August 2017 um 18:42
An: "Torres Figueroa, Luis Angel" , 
"usrp-users@lists.ettus.com" 
Betreff: Re: [USRP-users] Building FPGA image

I'm glad you got it working.  There are a lot of critical warnings and things 
of that ilk that scroll by, but as long as you don't get any errors and your 
project meets timing, I wouldn't worry too much about them.

Happy FPGAing.

On 08/18/2017 09:26 AM, Torres Figueroa, Luis Angel wrote:
Hi Jason,

It worked. I downloaded the source files from rfnoc-devel branch in the 
repository again and build it without choosing the option you mentioned.

I have still some critical warnings, but the image has been correctly generated 
and I could use it in the URSP. Also, all the timing constraints were now met. 
Thanks for the advice!

ImplementationDesign Initialization
[Designutils 20-1280] Could not find module 'fifo_4k_2clk'. The XDC file 
/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/fifo_4k_2clk/fifo_4k_2clk/fifo_4k_2clk.xdc
 will not be read for any cell of this module.
[Designutils 20-1280] Could not find module 'axi_hb31'. The XDC file 
/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/axi_hb31/fir_compiler_v7_2_5/constraints/fir_compiler_v7_2.xdc
 will not be read for any cell of this module.
[Designutils 20-1280] Could not find module 'fifo_4k_2clk'. The XDC file 
/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/build-ip/xc7k410tffg900-2/fifo_4k_2clk/fifo_4k_2clk/fifo_4k_2clk_clocks.xdc
 will not be read for any cell of this module.
[Common 17-55] 'set_property' expects at least one object. 
["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":293]
[Common 17-55] 'set_property' expects at least one object. 
["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":294]
[Common 17-55] 'set_property' expects at least one object. 
["/home/rfnoc-devel/source/uhd/fpga-src/usrp3/top/x300/timing.xdc":295]

Best,
Luis

Von: Jason Matusiak 

Datum: Mittwoch, 16. August 2017 um 17:09
An: "Torres Figueroa, Luis Angel" 
,
 "usrp-users@lists.ettus.com" 

Betreff: Re: [USRP-users] Building FPGA image

I've done it many times.  When you open it and you do a save-as of the project, 
make sure that you don't check the option box to copy the files over, you want 
to leave them in their current location.


On 08/16/2017 10:15 AM, Torres Figueroa, Luis Angel via USRP-users wrote:
Hi folks,

Has someone of you loaded the whole usrp_x310_fpga_RFNOC_HG design into Vivado 
2015.4 and created the FPGA image using its graphical Interface? I am still 
unable to do so.

I want to create a standard FPGA image using Vivado GUI.

I have first run the command “make X310_RFNOC_HG GUI=1”, saved the whole RTS 
design and reopened it as project mode, and then tried to create the bitstream 
from the GUI itself but it doesn’t work.

I have also tried adding the x300.v file, the constraints and all its dependent 
files into the design, and then done the synthesis, implementation and 
generated the bitstream, but when I loaded it onto the USRP I can’t recognize 
any block using the command uhd_usrp_probe. This is the error I get:

[ERROR] [UHD] Exception caught in safe-call.
  in virtual ctrl_iface_impl::~ctrl_iface_impl()
  at ~/uhd/host/lib/rfnoc/ctrl_iface.cpp:76
this->peek32(0); -> EnvironmentError: IOError: Block ctrl (CE_04_Port_70) no 
response packet - AssertionError: bool(buff)
  in uint64_t ctrl_iface_impl::wait_for_ack(bool)
  at ~/uhd/host/lib/rfnoc/ctrl_iface.cpp:197

Best,
Luis A. Torres





___

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/list

[USRP-users] Simple device question

[ROBIN TORTORA via USRP-users]

Peeps,


I have an X310 on windows with 3.10.2 and a single UBX daughtercard.


get_rx_num_channels always returns 2 even though there is only a single 
daughtercard installed.


I am guessing this is really returning the number of DDCs present?


Is there a simple way to get the number of actual channels present a la the 
number of daughtercards, etc.?


I am building a flexible data recorder and would like to to be able to adapt to 
different daughtercard configurations, so polling the device to get its 
configuration at runtime is important...


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

Re: [USRP-users] Simple device question

[Marcus D. Leech via USRP-users]

You could run uhd_usrp_probe and parse the output. 

On 2017-09-13 15:30, ROBIN TORTORA via USRP-users wrote:

> Peeps, 
> 
> I have an X310 on windows with 3.10.2 and a single UBX daughtercard. 
> 
> get_rx_num_channels always returns 2 even though there is only a single 
> daughtercard installed. 
> 
> I am guessing this is really returning the number of DDCs present? 
> 
> Is there a simple way to get the number of actual channels present a la the 
> number of daughtercards, etc.? 
> 
> I am building a flexible data recorder and would like to to be able to adapt 
> to different daughtercard configurations, so polling the device to get its 
> configuration at runtime is important... 
> 
> Thanks, 
> ___
> 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] Simple device question

[Marcus Müller via USRP-users]

I'd actually recommend doing `uhd_usrp_probe --tree` and figure out
which value you need from that. We don't actually guarantee the
stability of the output of the plain-text uhd_usrp_probe.

Best regards,

Marcus

On 09/13/2017 10:01 PM, Marcus D. Leech via USRP-users wrote:
>
> You could run uhd_usrp_probe and parse the output.
>
>  
>
>  
>
>  
>
> On 2017-09-13 15:30, ROBIN TORTORA via USRP-users wrote:
>
>> Peeps,
>>
>>  
>>
>> I have an X310 on windows with 3.10.2 and a single UBX daughtercard.
>>
>>  
>>
>> get_rx_num_channels always returns 2 even though there is only a
>> single daughtercard installed.
>>
>>  
>>
>> I am guessing this is really returning the number of DDCs present?
>>
>>  
>>
>> Is there a simple way to get the number of actual channels present a
>> la the number of daughtercards, etc.?
>>
>>  
>>
>> I am building a flexible data recorder and would like to to be able
>> to adapt to different daughtercard configurations, so polling the
>> device to get its configuration at runtime is important...
>>
>>  
>>
>> Thanks,
>>
>>
>> ___
>> 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] Questions on inserting an encoder/modulator in the B200 fpga tx-chain

[Ezequiel Alfíe via USRP-users]

Hello list.
I am working on a customization of the fpga code for the USRP B200.

My intention is to put an encoder/modulator inside the fpga (i dont care
for rx for now). I want to do this before the digital upconverter.
The samples coming from the USB bus will not be I/Q samples, but a type of
data which will be encoded/modulated.

I have read most of the code surrunding `radio_legacy.v`. And I have a few
questions regarding the clocks/rates, the run/strobe protocol, and other
stuff:

1) Is it true that only the strobe lines control the sampling rate? In
which cases the `run` signal is off? underflows? When `run` is off, does
the transmitter become effectively disabled?

2) Is the `radio_clk` signal in radio_legacy.v what UHD calls clock rate?
(i've seen also the term `master clock rate` which I guess is just the same)

3) What are the minimum and maximum frequencies of the clock rate?

4) Is the digital up-converter responsible of converting between
sample_rate and  clock rate? (i guess it is)

4) does UHD also set the AD936x internal upconverter? should I care about
that?

5) If I remove the digital up-converter (duc), and replace it with a latch
or pass-through which has the assignment `strobe_out <= 1'b1;`, then I
guess the sample rate becomes equal to the clock rate. In this case, should
I change the UHD code to indicate that I do not have a duc? or will it
suffice to set the clock_rate with UHD? [nb: i want to do this because of
the fpga area the duc/ddc consumes]

6) If I put a block which consumes samples from the tx_ctrl block, may I
strobe at whichever clock edge I want? In other words, may I have a one
sample rate going from USB->Tx_ctrl, and another going through the duc->dac
? I understand that if I remove the DUC then the USB->Tx_ctrl average rate
must be lower than the output rate

7) do any of you, have a complete and working example of a
encoder/modulator put in the tx chain before the duc?
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Simple device question

[ROBIN TORTORA via USRP-users]

OK, I can walk the tree and map channels to populated slots based on the name, 
assuming Unknown is an unpopulated slot...


Would be nice to have a better abstraction there...


I have noticed that IQ will stream from unpopulated daughtercard slots...  Is 
this expected?


In testing my app I have only 1 card per x310, yet I got 2x100 MSA streams from 
a single device...

> On September 13, 2017 at 4:55 PM Marcus Müller via USRP-users 
>  wrote:
> 
> 
> I'd actually recommend doing `uhd_usrp_probe --tree` and figure out which 
> value you need from that. We don't actually guarantee the stability of the 
> output of the plain-text uhd_usrp_probe.
> 
> Best regards,
> 
> Marcus
> 
> On 09/13/2017 10:01 PM, Marcus D. Leech via USRP-users wrote:
> 
> > > 
> > You could run uhd_usrp_probe and parse the output.
> > 
> >  
> > 
> >  
> > 
> >  
> > 
> > On 2017-09-13 15:30, ROBIN TORTORA via USRP-users wrote:
> > 
> > > > > 
> > > Peeps,
> > > 
> > >  
> > > 
> > > I have an X310 on windows with 3.10.2 and a single UBX 
> > > daughtercard.
> > > 
> > >  
> > > 
> > > get_rx_num_channels always returns 2 even though there is 
> > > only a single daughtercard installed.
> > > 
> > >  
> > > 
> > > I am guessing this is really returning the number of DDCs 
> > > present?
> > > 
> > >  
> > > 
> > > Is there a simple way to get the number of actual channels 
> > > present a la the number of daughtercards, etc.?
> > > 
> > >  
> > > 
> > > I am building a flexible data recorder and would like to to 
> > > be able to adapt to different daughtercard configurations, so polling the 
> > > device to get its configuration at runtime is important...
> > > 
> > >  
> > > 
> > > Thanks,
> > > 
> > > 
> > > ___
> > > USRP-users mailing list
> > > USRP-users@lists.ettus.com mailto: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 mailto: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] Simple device question

[Marcus Müller via USRP-users]

Hi Robin,

The property tree is the abstraction here; you can query it!

Alos, instead of walking the parsed output of some UHD utility, I'd
recommend you just directly query the USRP in the  C++/C/Python...
directly, using UHD.

> I have noticed that IQ will stream from unpopulated daughtercard
> slots...  Is this expected?
>
Yes! Point is that you could have a custom daughterboard there that
doesn't come with an EEPROM containing an ID that UHD understands and
still want it to give you samples (you'd of course be better of if you
just wrote a small daughterboard driver for that).

Best regards,

Marcus


On 09/13/2017 11:39 PM, ROBIN TORTORA wrote:
>
> OK, I can walk the tree and map channels to populated slots based on
> the name, assuming Unknown is an unpopulated slot...
>
>
> Would be nice to have a better abstraction there...
>
>
> I have noticed that IQ will stream from unpopulated daughtercard
> slots...  Is this expected?
>
>
> In testing my app I have only 1 card per x310, yet I got 2x100 MSA
> streams from a single device...
>
>> On September 13, 2017 at 4:55 PM Marcus Müller via USRP-users
>>  wrote:
>>
>> I'd actually recommend doing `uhd_usrp_probe --tree` and figure out
>> which value you need from that. We don't actually guarantee the
>> stability of the output of the plain-text uhd_usrp_probe.
>>
>> Best regards,
>>
>> Marcus
>>
>> On 09/13/2017 10:01 PM, Marcus D. Leech via USRP-users wrote:
>>>
>>> You could run uhd_usrp_probe and parse the output.
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> On 2017-09-13 15:30, ROBIN TORTORA via USRP-users wrote:
>>>
 Peeps,

  

 I have an X310 on windows with 3.10.2 and a single UBX daughtercard.

  

 get_rx_num_channels always returns 2 even though there is only a
 single daughtercard installed.

  

 I am guessing this is really returning the number of DDCs present?

  

 Is there a simple way to get the number of actual channels present
 a la the number of daughtercards, etc.?

  

 I am building a flexible data recorder and would like to to be able
 to adapt to different daughtercard configurations, so polling the
 device to get its configuration at runtime is important...

  

 Thanks,


 ___
 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 mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Support with setting usrp sampling rate to 150MSPS

[Marcus Müller via USRP-users]

Hi Snehasish,

knowing the roll-off of the halfband filters in the USRP, this is rather
surprising. So, my best guess is that there's might be a problem with
your software, but I can't really assess that.


Best regards,

Marcus


On 09/13/2017 12:41 PM, Snehasish Kar via USRP-users wrote:

I have noticed that IQ will stream from unpopulated daughtercard
slots...  Is this expected?

> Hi,
>
>
> I am capturing 75 MHz using 100 MSps sample rate as well as using 200
> MSps sample rate but I am not getting the near-end bands with 100 MSps
> while I am getting those with 200 MSps. What I have done is capture
> the data and then pass it through a polyphase channelizer to give me
> 200 K bandwidth channels and then I am upsampling that data to 1 MSps
> or 2 Msps and passing through gr-gsm receiver. With 200 MSps I am
> getting correct data whereas with 100 MSps I am not. But according to
> usrp specs my sampling rate as 1.25*75 MHz should be enough but that
> is not happening. Please help.
>
>
> Regards,
>
> Snehasish
>
> 
> *From:* Derek Kozel 
> *Sent:* Wednesday, August 23, 2017 12:15:11 PM
> *To:* Koyel Das
> *Cc:* Snehasish Kar; usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] Support with setting usrp sampling rate to
> 150MSPS
>  
> Hello Koyel,
>
> This is a fundamental problem that increasing sample rate takes more
> processing power to handle but provides more bandwidth of spectrum.
> How wide is the signal you need to process? The general recommendation
> is that you sample at 1.25 times your bandwidth. This provides 20%
> more spectrum than is necessary, but means that your signal is
> minimally affected by the digital filters used in the decimation in
> the FPGA. This is part of how the 160 MHz bandwidth of the UBX is
> derived from the 200 MHz sampling rate of an X310 (what is inside the
> 2954R).
>
> The default FPGA image is limited to integer decimation rates as
> described in the manual.
> http://files.ettus.com/manual/page_general.html#general_sampleratenotes
>
> GSM 1800 covers 170 MHz so even with the full sampling rate the
> outermost edges will be attenuated by both the analog filters and the
> digital filters. If you only want to look at the uplink or downlink
> individually then you can observe the 75 MHz bandwidth with 100 MS/s
> and easily meet the recommended maximum of 80% occupied bandwidth.
>
> For non-integer decimation rates such as 200e6/150e6 = 4/3 you would
> have to implement a rational resampler as a custom RFNoC block to
> support that decimation rate, certainly possible but additional work.
>
> Regards,
> Derek
>
> On Wed, Aug 23, 2017 at 7:17 AM, Koyel Das  > wrote:
>
> Hi,
>
> Many thanks for your reply. Yes 200 MSps works.
>
> But taking 200 MSps will increase the amount of data considerably
> and increase the processing time and very less amount of data is
> decoded from large amount of input samples compared to lower
> sampling frequencies. What is the solution to these problems? 
>
> Regards,
> Koyel
>
> On Tue, Aug 22, 2017 at 9:14 PM, Snehasish Kar
> mailto:snehasish@live.com>> wrote:
>
> Ok I will try that.
>
> BR
> Snehasish 
>
> On 22-Aug-2017, at 8:51 PM, Derek Kozel  > wrote:
>
>> Try 200MS/s. The FPGA can only decimate integer amounts from
>> the ADC rate, which is 200MS/s.
>>
>> On Tue, Aug 22, 2017 at 5:15 PM, Snehasish Kar via USRP-users
>> > > wrote:
>>
>> Hello
>> I am trying to receive gsm 1800 band using NI USRP 2954R,
>> but when I am trying to set the sampling rate of
>> uhd_source in gnuradio to 150 MSPS, it's giving an error
>> message saying hardware does not support sampling rate
>> above 100MSPS.
>>
>> Please help!
>>
>> BR
>> Snehasish
>> ___
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> 
>> 
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>> 
>> 
>>
>>
>
>
>
> -- 
>
> Koyel Das 
>
> Senior Product Engineer 
>
> Vehere | Proactive Communications Intelligence & Cyber Defence 
>
> M: +919051132173  | T: +91 33 24008400
>  | F: +91 33 247988100 | W:
> www.vehere.com  
>
>
> Vehere is the proud recipient of the Fastest Growing Technology
> Company Awards in India & Asia since 2012! 
>
>
> The content of this e-mail is confidential and intended solely for
> the use of the addressee. The text of this email (including any
> attachment