[USRP-users] Clock setting in RFNOC

wwd wwd_usrp at hotmail.com
Mon Mar 14 11:37:26 EDT 2016


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/8097723d/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jigachga.png
Type: image/png
Size: 21750 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160314/8097723d/attachment.png>


More information about the USRP-users mailing list