[USRP-users] rx data structure of E310

wwd wwd_usrp at hotmail.com
Thu Mar 31 10:52:49 EDT 2016


For the first step, what I am trying to do is a very simple test 
implementation.

I use a signal waveform generator to generate a sinus signal, then let 
it pass through E310 and save the samples to SD card. Finally, I try to 
plot the samples to verify all the configurations in E310 are corrects.

So what I have done is:

 1.
    Image Freq=80MHz, Vp-p=60mV
 2.
    Image

The center frequency=79.999MHz, I suppose I will get 1KHz after LO; the 
sample rate=10MHz; Master_clock_rate=60MHz; and I use this type of SD card
Image
The UHD and FPGA, I am using the newest RFNOC version:uhd-rfnoc-radio-redo
Therefore, I have some warning of overrun, but it doesn't have serious 
problem for my results.

 3. In MATLAB, I separate each 16bits data one for Q and one for I. Then
    I pull out the higher 12bits, because I think they are real data
    after ADC and do the two's complement to transfer it to signed int.
    So finally I have two figures of sample data, one for I and the
    other is Q:


Image





















But they don't have the same amplitude, and don't have the different on 
phase. So I want to know what's the problem could be, am I missing 
something.
And I have another silly question is the master_clock_rate is the 
frequency applied on ADC and sample rate is between usrp and host pc, in 
E310 is between FPGA and ARM cpu, or it is the final frequency after the 
decimating filters after ADC?

Thanks,

Weidong



On 16-03-31 04:18 AM, Marcus Müller wrote:
> Dear Wwd,
>
> the "set_bandwidth()" method is now fully operational.
> I'm still not sure what your purpose is; again, usually, the default 
> behaviour works quite fine.
> What are you trying to do?
>
> Best regards,
> Marcus
>
> On 31.03.2016 02:55, wwd wrote:
>> Thanks Marcus,
>>
>> According AD9361 configuration note pdf, the rx signal path shows 
>> like below:
>>
>> So all these filters are configurable in UHD? I did some search on 
>> google, and found this old message:
>> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-February/008576.html
>>
>>  Mr./Igor Rubaszewski/  asked how to configure the analog filters, 
>> and Mr. Marcus Leech responded it is on the roadmap. So are there 
>> some developments?
>>
>> Thanks again.
>>
>> Weidong
>>
>> On 16-03-30 10:41 AM, Marcus Müller wrote:
>>> To add to what Marcus said, we get this question rather often, "I'd 
>>> like to see the signal like it was seen by the ADC"; in fact, many 
>>> high-speed ADCs do integrate some kind of DSP themselves, and 
>>> especially the AD9361 used in the E310 is extremely mighty when it 
>>> comes to that. So the core question here is always:
>>>
>>> what do you need *really*?
>>>
>>> As Marcus explained, the values that the host CPU will see are 
>>> proportional to the voltage the ADC sees, but not exactly the 
>>> digital numbers the ADC gives; that's necessary, simply because the 
>>> CPU doesn't really know 12 bit values, so there has to be some 
>>> mapping to 16bit or 32bit values, just to be able to deal with the 
>>> values computationally.
>>> Then, this is baseband radio; what you get is just something 
>>> /equivalent/ to the RF passband, anyway. UHD keeps that equivalence 
>>> (aside from filter imperfections, but we can consider these 
>>> separately, if your application demands it; for most purposes, UHD 
>>> does really fine), so you're not having any disadvantage by the DSP 
>>> chain.
>>>
>>> Best regards,
>>> Marcus M
>>>
>>> On 30.03.2016 16:32, mleech at ripnet.com wrote:
>>>>
>>>> The data you see within your application or Gnu Radio flow-graph is 
>>>> not identical to what comes off the ADC.
>>>>
>>>> The ADC data are passed through DSP filtering including DDC 
>>>> processing if necessary, and decimation, typically.
>>>>
>>>> Further, the data are then formatted for the wire in either 8-bit 
>>>> or 16-bit format, then UHD can convert it into a number of 
>>>> different   formats for the CPU side of the house.
>>>>
>>>> The bits you get in the application are linearly-proportional to 
>>>> what comes off the ADC, but not exactly what comes off the ADC.
>>>>
>>>> On 2016-03-30 09:45, wwd via USRP-users wrote:
>>>>
>>>>> Dear Marcus,
>>>>>
>>>>> I have a basic question about the data structure in FPGA and UHD.
>>>>>
>>>>> When I looked at the FPGA source code, I found these codes:
>>>>>
>>>>> //------------------------------------------------------------------
>>>>>   // CODEC capture/gen
>>>>> //------------------------------------------------------------------
>>>>>   wire mimo;
>>>>>   wire codec_arst;
>>>>>   wire [11:0] rx_i0, rx_q0, rx_i1, rx_q1, tx_i0, tx_q0, tx_i1, tx_q1;
>>>>>   wire [31:0] rx_data0, rx_data1, tx_data0, tx_data1;
>>>>> *assign rx_data0      = {rx_i0,4'd0,rx_q0,4'd0};**
>>>>> **  assign rx_data1      = {rx_i1,4'd0,rx_q1,4'd0};*
>>>>>   assign {tx_i0,tx_q0} = {tx_data0[31:20],tx_data0[15:4]};
>>>>>   assign {tx_i1,tx_q1} = {tx_data1[31:20],tx_data1[15:4]};
>>>>>
>>>>>
>>>>> I want to make sure if in the UHD side, the rx data keeps the same 
>>>>> structure. And the data samples are carried in two's complement 
>>>>> format.
>>>>>
>>>>> 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
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160331/022fd3cb/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ebeigefg.jpeg
Type: image/jpeg
Size: 164739 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160331/022fd3cb/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: aigbdhgb.png
Type: image/png
Size: 11380 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160331/022fd3cb/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jabdgcid.jpeg
Type: image/jpeg
Size: 38979 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160331/022fd3cb/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: icjchjfg.png
Type: image/png
Size: 125162 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160331/022fd3cb/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 20615 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20160331/022fd3cb/attachment-0002.png>


More information about the USRP-users mailing list