[USRP-users] Clock setting in RFNOC

Marcus Müller marcus.mueller at ettus.com
Mon Mar 14 13:00:27 EDT 2016


Hi wwd,
well, the bottleneck here is the fact that benchmark_rate needs to
receive the samples with the CPU. The FPGA has no problems keeping up
with the rate.

Best regards,
Marcus

On 03/14/2016 04:37 PM, wwd wrote:
> Hello Marcus,
>
> Sorry to ask you again this question, but I didn't receive your reply
> last time.
>
> Because my objective of project is to migrate a GNSS system written in
> VHDl using Virtex-4 to E310. The original idea is using 60MHz
> sampling  to cover equally 1.023MHz on L1/L2 bands, 10.23MHz on L5
> band or 511.5kHz for GLONASS. So at the first time, my concept of
> using RFNOC on E310 is like this:
>
>
>
> And in the last email, you told me, the maximum master clock rate of
> AD9316 is 30.72MHz in the dual-channel rx case. So because for the Gps
> application, I only need single channel to receive the signal, could I
> set the frequency to 60MHz?
>
> And even when I tried to configure the sample rate to 30MHz using the
> command:
> *./benchmark_rate --rx_rate 30e6*
> It gave me some error messages like below:
> *linux; GNU C++ version 4.9.2; Boost_105700;
> UHD_003.010.rfnoc-0-3cd361cb**
> **......**
> **-- [Device3] updating RX streamer to RX Terminator 0**
> **--   New tick_rate == 3e+07  New samp_rate == 3e+07 New scaling ==
> 3.05185e-05**
> **Testing receive rate 30.000000 Msps on 1 channels**
> **--   [0/Radio_0] sr_write(124, 00000000, 0)**
> **-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0**
> **--   [0/Radio_0] sr_write(152, E0000001, 0)**
> **--   [0/Radio_0] sr_write(153, 00000000, 0)**
> **--   [0/Radio_0] sr_write(154, 00000000, 0)**
> **-- radio_ctrl_impl::handle_overrun()**
> **-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0**
> **--   [0/Radio_0] sr_write(152, E0000001, 0)**
> **--   [0/Radio_0] sr_write(153, 00000000, 0)**
> **--   [0/Radio_0] sr_write(154, 00000000, 0)**
> **O-- radio_ctrl_impl::handle_overrun()**
> **-- [0/Radio_0] radio_ctrl_impl::issue_stream_cmd() 0**
> **--   [0/Radio_0] sr_write(152, E0000001, 0)**
> **--   [0/Radio_0] sr_write(153, 00000000, 0)**
> **--   [0/Radio_0] sr_write(154, 00000000, 0)
> ......
> **Benchmark rate summary:**
> **  Num received samples:    64157030**
> **  Num dropped samples:     224727651**
> **  Num overflows detected:  3998**
> **  Num transmitted samples: 0**
> **  Num sequence errors:     0**
> **  Num underflows detected: 0**
> **  Num late commands:       0**
> **  Num timeouts:            0**
> **
> **
> **Done!*
>
> And the best case without errors is when we set the rate to 10MHz. So
> is that meaning we can set the maximum sample rate to 10MHz?
>
> TIA.
>
> Weidong
>
> On 16-02-22 04:04 PM, wwd via USRP-users wrote:
>> Marcus,
>>  
>> Thanks for your explanations.
>>
>> So in e310 could I use single channel so I can use 60MHz for sample
>> rate? I notice in RFNOC there are two radio cores, is that the reason
>> we can only use dual-channel by default? If it is limited by the
>> material, we must change of old project to adapt it.
>>
>> And why the sample rate is limited to 16MHz but not 30.72MHz?
>> UHD Warning:
>>     The hardware does not support the requested RX sample rate:
>>     Target sample rate: 30.000000 MSps
>>     Actual sample rate: 16.000000 MSps
>>
>> I find in Multi_usrp.cpp file, there are two functions used to set
>> the sample rate:
>>     void set_rx_rate(double rate, size_t chan){
>>         if (chan != ALL_CHANS){
>>             _tree->access<double>(rx_dsp_root(chan) / "rate" /
>> "value").set(rate);
>>             do_samp_rate_warning_message(rate, get_rx_rate(chan), "RX");
>>             return;
>>         }
>>         for (size_t c = 0; c < get_rx_num_channels(); c++){
>>             set_rx_rate(rate, c);
>>         }
>>     }
>>
>>     double get_rx_rate(size_t chan){
>>         return _tree->access<double>(rx_dsp_root(chan) / "rate" /
>> "value").get();
>>     }
>>
>> But because of lacking some knowledge of C++, I couldn't find how
>> this function _tree->access<double>(rx_dsp_root(chan) / "rate" /
>> "value").set(rate); works. So could you explain it to me?
>>
>> Thanks a lot.
>>
>> Weidong
>>
>>
>>
>> On 16-02-22 01:34 PM, Marcus Müller wrote:
>>> Dear Weidong,
>>>
>>> On 02/22/2016 04:48 PM, wwd wrote:
>>>>
>>>> The sample rate is fixed by 60MHz, and for the GPS L1 C/A signal,
>>>> the bandwidth is 20.46MHz, for Galileo E1, the bandwidth is at
>>>> least 16MHz. So I must respect all these setting by default.
>>> So, architectural, there's nothing you can do about the maximum
>>> master clock rate of the AD9361, which is 30.72MHz in the
>>> dual-channel rx case.
>>>
>>> So, still, I don't understand why you would need 60MS/s to represent
>>> 16MHz of bandwidth -- Nyquist says 16MS/s would be enough. The same
>>> for 20.46MHz. Could you explain why you'd need 60MS/s? Notice that
>>> the AD9361 really can't do 60MS/s when operating in dual-channel
>>> mode; that's not a restriction of the digital signal processing, but
>>> of the way the AD9361 is built.
>>>
>>> Best regards,
>>> Marcus
>>>>
>>>> Best regards,
>>>>
>>>> Weidong
>>>>
>>>>
>>>> On 16-02-19 04:21 PM, Marcus Müller wrote:
>>>>> I made that figure for exactly emails like these :) other than
>>>>> that, see the general notes in the UHD manual.
>>>>>
>>>>> All the bandwidth considerations apply, no matter how you process
>>>>> the output of the ADC. The bandwidth you're setting is a analog
>>>>> thing that happens *before* the ADC.
>>>>>
>>>>> Can you explain a little bit why you want to use these specific
>>>>> settings? To me, they don't make too much sense, but I'm lacking
>>>>> your application's background.
>>>>>
>>>>> Best regards,
>>>>> Marcus
>>>>>
>>>>> Am 19. Februar 2016 21:30:32 MEZ, schrieb wwd <wwd_usrp at hotmail.com>:
>>>>>
>>>>>     Dear Marcus,
>>>>>
>>>>>     Could you kindly tell me where I can find these explanations
>>>>>     of the receiver you used in the last email? And we are using
>>>>>     the Rfnoc version of UHD on E310. Is that possible the
>>>>>     bandwidth is limited to maximum 16 MHz?
>>>>>
>>>>>     Best regards,
>>>>>
>>>>>     Weidong
>>>>>
>>>>>
>>>>>
>>>>>     On 16-02-19 03:20 AM, Marcus Müller wrote:
>>>>>>     Dear Weidong,
>>>>>>
>>>>>>     On 19.02.2016 05:12, wwd wrote:
>>>>>>>     Thanks Marcus,
>>>>>>>
>>>>>>>     The reason I want to use 8bits data is we have a program of
>>>>>>>     Matlab using the 8bits data file.
>>>>>>     Ok, then you'll either have to modify the rx_samples_to_file
>>>>>>     example or modify your matlab code :)
>>>>>>>
>>>>>>>     And now I have another question of configuration the Rx
>>>>>>>     procedure.
>>>>>>>
>>>>>>>     I want to receive a series of GPS L1 signal, the central
>>>>>>>     frequency is 1575.42MHz, the IF is 15MHz, the sample
>>>>>>>     frequency is 60MHz and the band width of IF is 24MHz.
>>>>>>     The AD936x is a direct conversion receiver, so IF=0, as you
>>>>>>     notice below.
>>>>>>     /Digitally/, you can emulate an IF receiver by tuning
>>>>>>     somewhere else, and digitally shifting by what you call IF:
>>>>>>     bandwidth and tuning offset
>>>>>>     There's a few observation's here:
>>>>>>
>>>>>>      1. $f_\text{offset}+ \frac12 b_\text{sample} \le
>>>>>>         b_\text{analog}$, otherwise your signal will be cut off
>>>>>>         by the analog filter. In your case,
>>>>>>         $f_\text{offset}=\SI{15}{\mega\hertz}$, and
>>>>>>         $b_\text{sample}=f_\text{sample}=\SI{60}{\mega\hertz}$,
>>>>>>         and because $\left(15+\frac12
>>>>>>         60\right)\si{\mega\hertz}=\SI{45}{\mega\hertz}>\SI{24}{\mega\hertz}=b_\text{analog}$,
>>>>>>         this can't work.
>>>>>>      2. You sample at a rate much bigger than the bandwidth you
>>>>>>         seem interested in. That is wasteful. You don't get any
>>>>>>         positive effect out of that.
>>>>>>      3. The frequency shift by $f_\text{offset}$ is done
>>>>>>         digitally, mathematically by multiplying with an
>>>>>>         $e^{j2\pi \frac{f_\text{offset}{f_\text{MCR}}$, and
>>>>>>         $f_text{MCR}$ is the master clock rate, ie. the physical
>>>>>>         sampling rate before decimation. Now, this directly leads
>>>>>>         to a second constraint: $f_\text{offset}+ \frac12
>>>>>>         b_\text{sample} \le f_\text{MCR}$, or else the observed
>>>>>>         band will just "wrap" at the edge of the Nyquist band.
>>>>>>         Since the maximum MCR for the AD936x/B2x0 is 61.72 MHz,
>>>>>>         you're violating that one, too.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>     After that I set the "bw" variable to 24000000, and the
>>>>>>>     usrp->set_rx_bandwidth(bw, radio_id);method is supposed to
>>>>>>>     set the band width of the filter of ADC.
>>>>>>>
>>>>>>>     But I had these results below:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     Setting RX Freq: 1175.420000 MHz...
>>>>>>>     Actual RX Freq: 1167.420000 MHz...
>>>>>>>
>>>>>>>     Setting RX Gain: 20.000000 dB...
>>>>>>>     Actual RX Gain: 20.000000 dB...
>>>>>>>
>>>>>>>     Setting RX Bandwidth: 24.000000 MHz...
>>>>>>>     Actual RX Bandwidth: 16.000000 MHz...
>>>>>>>
>>>>>>>     Waiting for "lo_locked": ++++++++++ locked.
>>>>>>>
>>>>>>>     I tried other value of Rx bw, it is limited to 16MHz. What
>>>>>>>     am I missing here?
>>>>>>     Probably just some sanity check confused by your settings, or
>>>>>>     maybe actually a limit of UHD or the AD9361; what version of
>>>>>>     UHD are you using?
>>>>>>
>>>>>>     Best regards,
>>>>>>     Marcus
>>>>>>
>>>>>>>
>>>>>>>     Thanks again,
>>>>>>>
>>>>>>>     Weidong
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>     On 16-02-18 06:06 AM, Marcus Müller wrote:
>>>>>>>>     Hi Weidong,
>>>>>>>>>     1. Could we choose 8-bit(sc8 or int8_t) type?  
>>>>>>>>
>>>>>>>>     the type you specify for rx_samples_to_file is the on-disk
>>>>>>>>     storage type. I don't know whether using 8 bit integers
>>>>>>>>     really makes that much sense, unless your storage really
>>>>>>>>     only closely fails to keep up with the data rate caused by
>>>>>>>>     the "short" format (which is 4B/S, e.g. at 10MS/s, you need
>>>>>>>>     to be able to write 40MB/s, sustained).
>>>>>>>>
>>>>>>>>     Now, the point is that of course, you'll lose quite some
>>>>>>>>     accuracy/get quite some quantization noise when using only
>>>>>>>>     8bit. Hence, there's no cpu_format=8bit converter for the
>>>>>>>>     on-the-wire sample formats that we use with the B2x0.
>>>>>>>>
>>>>>>>>     So, yes, you can add that functionality easily to
>>>>>>>>     rx_samples_to_file yourself by instead of writing what you
>>>>>>>>     get for short/"sc16" you only write the MSB, but I really
>>>>>>>>     wouldn't recommend that unless you're very sure of what
>>>>>>>>     you're doing.
>>>>>>>>
>>>>>>>>     Hence my question: Why do you want an 8bit storage format?
>>>>>>>>
>>>>>>>>     Also, I'd also like to stress the example nature of
>>>>>>>>     rx_samples_to_file: it's not meant to be an overly
>>>>>>>>     optimized application for receiving samples, it's really
>>>>>>>>     just meant as an example of how to implement something that
>>>>>>>>     does what you want yourself.
>>>>>>>>
>>>>>>>>>     2. On the AD9361 Reference Manual, in the Digital
>>>>>>>>>     Interface Specification part, it presents several mode of
>>>>>>>>>     transfer of IQ sample data. So how could we know which
>>>>>>>>>     sample data is I, which sample data is Q in the saved file?
>>>>>>>>     The job of the USRP is to take the digital signal that
>>>>>>>>     comes from the AD936x and process it, and package it, and
>>>>>>>>     exchange it with your PC. UHD's job is to know how to
>>>>>>>>     interpret the packets coming from the USRP. Don't worry, it
>>>>>>>>     does the right thing.
>>>>>>>>
>>>>>>>>     Best regards,
>>>>>>>>     Marcus
>>>>>>>>
>>>>>>>>     On 17.02.2016 23:06, wwd wrote:
>>>>>>>>>     Thanks Marcus,
>>>>>>>>>
>>>>>>>>>     I have some other questions about the sample type. In
>>>>>>>>>     Rx_samples_to_file.cpp, we can define an argument named
>>>>>>>>>     "type". And it is the sample type according to the
>>>>>>>>>     explanation.  It indicates three types: double, float and
>>>>>>>>>     short.
>>>>>>>>>
>>>>>>>>>     1. Could we choose 8-bit(sc8 or int8_t) type? 
>>>>>>>>>
>>>>>>>>>     2. On the AD9361 Reference Manual, in the Digital
>>>>>>>>>     Interface Specification part, it presents several mode of
>>>>>>>>>     transfer of IQ sample data. So how could we know which
>>>>>>>>>     sample data is I, which sample data is Q in the saved file?
>>>>>>>>>
>>>>>>>>>     Thanks again,
>>>>>>>>>
>>>>>>>>>     Weidong 
>>>>>>>>>
>>>>>>>>>     On 16-02-12 04:47 PM, Marcus Müller wrote:
>>>>>>>>>>     You can specify that as tuning request. See the tuning
>>>>>>>>>>     notes on the "general" page of the UHD manual.
>>>>>>>>>>
>>>>>>>>>>     Best regards,
>>>>>>>>>>     Marcus
>>>>>>>>>>
>>>>>>>>>>     Am 12. Februar 2016 21:37:37 MEZ, schrieb wwd via
>>>>>>>>>>     USRP-users <usrp-users at lists.ettus.com>:
>>>>>>>>>>
>>>>>>>>>>         Thanks Martin,
>>>>>>>>>>
>>>>>>>>>>         For tuning process, I am not totally understand. I can set the center 
>>>>>>>>>>         frequency at 1575.42MHz, the sampling frequency at 60MHz. And then the 
>>>>>>>>>>         tuning bloc can automatically set the LO to 1560.42MHz? And I could have 
>>>>>>>>>>         15MHz as IF? But if I want IF = 20 MHz? How the tuning system knows 
>>>>>>>>>>         which IF frequency I want.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         On 16-02-12 02:52 PM, Martin Braun via USRP-users wrote:
>>>>>>>>>>
>>>>>>>>>>             Weidong, when you do a regular tune, that's
>>>>>>>>>>             exactly what happens. No need to access
>>>>>>>>>>             lower-level functions. Your make system should
>>>>>>>>>>             only build whatever's necessary if you modify
>>>>>>>>>>             files (which you don't need to do for this use
>>>>>>>>>>             case). M On 02/12/2016 10:09 AM, wwd via
>>>>>>>>>>             USRP-users wrote:
>>>>>>>>>>
>>>>>>>>>>                 Hi Jonathon, I have a question about how to
>>>>>>>>>>                 set up the Local oscillator of E310. Now I
>>>>>>>>>>                 need move the received GPS signal from
>>>>>>>>>>                 1575.42MHz to 15MHz. So I want to apply a
>>>>>>>>>>                 1560.42MHz to the Mixer in AD9361. I fond a
>>>>>>>>>>                 function in lib/usrp/e300/e300_impl.cpp,
>>>>>>>>>>                 named _update_fe_lo_freq(fe, freq). But I
>>>>>>>>>>                 don't know how to use it in the
>>>>>>>>>>                 example/rx_sample_to_file.cpp. Could you
>>>>>>>>>>                 explain to how to do it, which head-file I
>>>>>>>>>>                 must include? I couldn't find an example of
>>>>>>>>>>                 it. And another question is, if I just change
>>>>>>>>>>                 one file in example file directory, could I
>>>>>>>>>>                 only compile this file instead of the whole
>>>>>>>>>>                 uhd system? Thanks, Weidong On 16-02-05 12:09
>>>>>>>>>>                 PM, Jonathon Pendlum wrote:
>>>>>>>>>>
>>>>>>>>>>                     Hi, No, bus_clk is used with our DMA code
>>>>>>>>>>                     and clocking the RFNoC crossbar. In
>>>>>>>>>>                     general, you should never need to adjust
>>>>>>>>>>                     bus_clk's frequency. Instead, set
>>>>>>>>>>                     master_clock_rate to 60 MHz and make sure
>>>>>>>>>>                     you hook up radio_clk to ce_clk for your
>>>>>>>>>>                     computation engines. Jonathon On Thu, Feb
>>>>>>>>>>                     4, 2016 at 7:22 PM, wwd via USRP-users
>>>>>>>>>>                     <usrp-users at lists.ettus.com
>>>>>>>>>>                     <mailto:usrp-users at lists.ettus.com>>
>>>>>>>>>>                     wrote: Thanks Jonathon, And could we set
>>>>>>>>>>                     the bus_clk the same as radio_clk?
>>>>>>>>>>                     Because I am trying to migrate an old
>>>>>>>>>>                     GNSS system to E310, the old one uses
>>>>>>>>>>                     60MHz in its FPGA and ADC. Weidong On
>>>>>>>>>>                     16-02-02 02:15 PM, Jonathon Pendlum wrote:
>>>>>>>>>>
>>>>>>>>>>                         Hi, master_clock_rate will only
>>>>>>>>>>                         affect radio_clk. If you set ce_clk =
>>>>>>>>>>                         radio_clk (which is the default) in
>>>>>>>>>>                         your rfnoc_auto_ce_inst_*.v file,
>>>>>>>>>>                         then it will affect the clock rate of
>>>>>>>>>>                         the rfnoc blocks as well. bus_clk is
>>>>>>>>>>                         generally always a fixed frequency:
>>>>>>>>>>                         50 MHz for E310, 166.67 MHz for X3x0.
>>>>>>>>>>                         Jonathon On Tue, Feb 2, 2016 at 7:27
>>>>>>>>>>                         AM, wwd via USRP-users
>>>>>>>>>>                         <<mailto:usrp-users at lists.ettus.com>usrp-users at lists.ettus.com>
>>>>>>>>>>                         wrote: Hi all, I have a simple
>>>>>>>>>>                         question about clock setting in
>>>>>>>>>>                         RFNOC. The args Master_clock_rate is
>>>>>>>>>>                         for setting the sample clock of ADC,
>>>>>>>>>>                         for example, I set it at 60MHz. Will
>>>>>>>>>>                         it set the same clock rate at the
>>>>>>>>>>                         signal radio_clk in bloc Radio, the
>>>>>>>>>>                         bus_clk and ce_clk in Noc_block_fft,
>>>>>>>>>>                         for example? Thanks Weidong
>>>>>>>>>>                         ------------------------------------------------------------------------
>>>>>>>>>>                         USRP-users mailing list
>>>>>>>>>>                         USRP-users at lists.ettus.com
>>>>>>>>>>                         <mailto:USRP-users at lists.ettus.com>
>>>>>>>>>>                         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>>                     ------------------------------------------------------------------------
>>>>>>>>>>                     USRP-users mailing list
>>>>>>>>>>                     USRP-users at lists.ettus.com
>>>>>>>>>>                     <mailto:USRP-users at lists.ettus.com>
>>>>>>>>>>                     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>>                 ------------------------------------------------------------------------
>>>>>>>>>>                 USRP-users mailing list
>>>>>>>>>>                 USRP-users at lists.ettus.com
>>>>>>>>>>                 http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>>             ------------------------------------------------------------------------
>>>>>>>>>>             USRP-users mailing list
>>>>>>>>>>             USRP-users at lists.ettus.com
>>>>>>>>>>             http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>         ------------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>>         USRP-users mailing list
>>>>>>>>>>         USRP-users at lists.ettus.com
>>>>>>>>>>         http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>>>>
>>>>>>>>>>     -- Sent from my Android device with K-9 Mail. Please
>>>>>>>>>>     excuse my brevity. 
>>>>>
>>>>> -- Sent from my Android device with K-9 Mail. Please excuse my
>>>>> brevity. 
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users at lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160314/bc04a8cb/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 21750 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160314/bc04a8cb/attachment.png>


More information about the USRP-users mailing list