[USRP-users] Zeros are not zero?

Michael West michael.west at ettus.com
Tue Dec 23 19:18:42 EST 2014


Hi Jim,

Thanks for the information.  We will look into this right away.

Regards,
Michael

On Tue, Dec 23, 2014 at 12:15 PM, Jim Hunziker <jhunziker at bcisensors.com>
wrote:
>
> Here is the fix for this problem.
>
> The original problem is that the DAC sends out uncalibrated zeros when the
> transmitter is not transmitting. So when it does start transmitting, there
> are bad transients related to the jump from uncalibrated zeros to
> calibrated zeros. This makes using scheduled transmissions (providing a
> time_spec_t to the transmit function) not possible without a data quality
> problem.
>
> To fix it, the X300 needs to set the SR_CODEC_IDLE register to the
> calibrated I and Q values (as read from the calibration file for the
> desired output frequency). I verified it by putting the following line in
> UHD's x300_impl.cpp:setup_radio function.
>
>     perif.ctrl->poke32(TOREG(250), 0xf448f448);
>
> 0xf448 was picked because our calibration file says I and Q need a -0.045
> offset at our transmit frequency.
>
> When you fix this yourselves, you should do it in the part of the UHD code
> where the transmit frequency is changed so that you can look up the proper
> correction in the calibration file.
>
> Please let me know when you have a patch. This problem is keeping us from
> using scheduled transmissions (and thus ATR). Thanks
>
> --
> Jim Hunziker
> BCI Systems and Software Engineering
> jhunziker at bcisensors.com
>
> On Mon, Nov 17, 2014 at 7:28 PM, Michael West <michael.west at ettus.com>
> wrote:
>
>> Hi Jim,
>>
>> It looks like it will take some time to investigate and resolve the
>> issue.  I have filed a bug so we will continue to look into it.  As a
>> workaround for the time being, just keep the stream running and insert
>> zeros where you need them.
>>
>> Regards,
>> Michael
>>
>> On Mon, Nov 17, 2014 at 2:39 PM, Michael West <michael.west at ettus.com>
>> wrote:
>>
>>> Hi Jim,
>>>
>>> Thanks for trying that.  Let me take a closer look at the UHD and FPGA
>>> code to see what is going on and get back to you.
>>>
>>> Regards,
>>> Michael
>>>
>>> On Mon, Nov 17, 2014 at 7:44 AM, Jim Hunziker <jhunziker at bcisensors.com>
>>> wrote:
>>>
>>>> Attached is the scope plot with the patch applied. I verified that the
>>>> patch was active by making a build with an exit(0) above the change to
>>>> force the program to exit. It did, so I removed the exit(0) and ran again.
>>>>
>>>> You can see in the plot that our LFM pulse surrounded by zeros is
>>>> riding on top of the calibration (manually set to 0.3 I, 0.3 Q in the
>>>> calibration file). The time when no transmission is scheduled is still
>>>> uncalibrated.
>>>>
>>>> The plot is the I+ signal from the DAQ test point. (The I- is just the
>>>> mirror image, as expected.)
>>>>
>>>> --
>>>> Jim Hunziker
>>>> BCI Systems and Software Engineering
>>>> jhunziker at bcisensors.com
>>>>
>>>> On Fri, Nov 14, 2014 at 7:38 PM, Michael West <michael.west at ettus.com>
>>>> wrote:
>>>>
>>>>> Hi Jim,
>>>>>
>>>>> This may be due to the ATR.  The TX mixer is disabled, the gain is
>>>>> reduced to 0, and the TX antenna is deselected when in the idle state.  The
>>>>> attached patch configures the ATR the same for the idle and TX states for
>>>>> the CBX daughter board.  Give it a try and let me know if anything changes.
>>>>>
>>>>> Regards,
>>>>> Michael
>>>>>
>>>>> On Fri, Nov 14, 2014 at 11:52 AM, Jim Hunziker via USRP-users <
>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>
>>>>>> After some further investigation, we've found that the problem is
>>>>>> still there. We're now looking at the I+ and I- outputs of the DAQ on the
>>>>>> X310 using a scope.
>>>>>>
>>>>>> The calibration offset is only being applied when a scheduled
>>>>>> transmission is taking place. This missing calibration offset is causing
>>>>>> the "zeros are not zero" problem.
>>>>>>
>>>>>> I don't see how the X310 can be used with time_specs set without
>>>>>> disabling calibration. (We're using a CBX-120, by the way.)
>>>>>>
>>>>>> Please see the attached document for plots.
>>>>>>
>>>>>> --
>>>>>> Jim Hunziker
>>>>>> BCI Systems and Software Engineering
>>>>>> jhunziker at bcisensors.com
>>>>>>
>>>>>> On Wed, Nov 12, 2014 at 11:29 AM, Marcus Müller <
>>>>>> usrp-users at lists.ettus.com> wrote:
>>>>>>
>>>>>>>  > How does the device choose the lo_off when you
>>>>>>> don't specify it?
>>>>>>>
>>>>>>> It tries to make the LO offset as small as possible, which gets more
>>>>>>> intuitive if you think about the USRP, by user expectation, has to work
>>>>>>> like a direct downconversion receiver.
>>>>>>>
>>>>>>> Also, 15MHz LO offset is *much*; with the standard daughterboards,
>>>>>>> you'll only get 40MHz analog bandwidth, meaning that you get +-20MHz around
>>>>>>> the physically tuned frequency; for the -120 Daughterboards, it's +-60MHz.
>>>>>>> So, if you're on a 40MHz daughterboard, and you use 15MHz offset tuning,
>>>>>>> and get a sample rate of 10MHz, you will see the filter rolloff in the
>>>>>>> upper part of your digital spectrum.
>>>>>>>
>>>>>>> >Does it bounce around every scheduled transmission?
>>>>>>>
>>>>>>>
>>>>>>> Yes (kind of). Unless you specify otherwise, UHD will determine
>>>>>>> "optimal" tuning by the "as close as possible" algorithm. If you, for
>>>>>>> example, want to tune to different center frequencies within the analog
>>>>>>> bandwidth, you can use the same tune_request magic to only tune your DSP --
>>>>>>> making tuning a lot faster, in most cases.
>>>>>>>
>>>>>>> Greetings,
>>>>>>> Marcus
>>>>>>> On 11/12/2014 05:15 PM, Jim Hunziker via USRP-users wrote:
>>>>>>>
>>>>>>> I changed my tune request from allowing it to use an automatic lo_off
>>>>>>> parameter to forcing it to use 15 MHz. This fixed the problem completely. I
>>>>>>> don't know why this worked. How does the device choose the lo_off when you
>>>>>>> don't specify it? Does it bounce around every scheduled transmission?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing listUSRP-users at lists.ettus.comhttp://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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/d4486300/attachment-0002.html>


More information about the USRP-users mailing list