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 <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 <snehasish....@live.com> > wrote: > >> Ok I will try that. >> >> BR >> Snehasish >> >> On 22-Aug-2017, at 8:51 PM, Derek Kozel <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 < >> 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 <+91%2090511%2032173> | T: +91 33 24008400 > <+91%2033%202400%208400> | 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 accepts no liability > for any damage caused by any virus transmitted by this email. > > > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
