[USRP-users] Zeros are not zero?

Jim Hunziker jhunziker at bcisensors.com
Tue Dec 23 15:15:09 EST 2014


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/2964f8c4/attachment-0002.html>


More information about the USRP-users mailing list