[USRP-users] Zeros are not zero?

Michael West michael.west at ettus.com
Tue Dec 23 22:41:14 EST 2014


Hi Jim,

Attached is a patch that sets the SR_CODEC_IDLE register to the same values
as the TX DC offset.  That should give you what you need.  Please give it a
try and let me know if it works for you.  We are also looking into a more
permanent and appropriate fix for the issue to be included in a future
release of UHD.

Best regards,
Michael

On Tue, Dec 23, 2014 at 4:18 PM, Michael West <michael.west at ettus.com>
wrote:
>
> 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/8cb3bed1/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x300_zeros_at_idle.patch
Type: text/x-patch
Size: 2858 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141223/8cb3bed1/attachment.patch>


More information about the USRP-users mailing list