Derek,
I'm very happy to hear that it's the tiniest of additional overhead!
Thanks!
On Thu, Jun 7, 2018 at 2:32 PM Derek Kozel <derek.ko...@ettus.com> wrote:
> Dave,
>
> It is most tunes (as often as needed when changing the frequency would
> change the IQ correction value). The overhead is, I believe, just a single
> write and thus completely inconsequential when compared to the usual length
> of synthesizer SPI writes and switch selection that tuning can cause.
>
> Regards,
> Derek
>
> On Thu, Jun 7, 2018 at 7:08 PM, Dave NotTelling via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Robin,
>> Thanks for your feedback!
>>
>> Marcus,
>> And that overhead is just on the initial tune, or for all tunes? I
>> do mostly timed commands, so should I allow for a little more time before
>> the deadline to send the timed command out?
>>
>> Thanks all!
>>
>> On Thu, Jun 7, 2018 at 1:56 PM Marcus D. Leech via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> On 06/07/2018 01:04 PM, Dave NotTelling via USRP-users wrote:
>>> > Is there a processing requirement impact to using the calibration CSV
>>> > file? Does using the cal data have any impact on tuning time for the
>>> > radio itself?
>>> >
>>> > Thanks!
>>> >
>>> The calibration values are stuffed into some machinery in the FPGA when
>>> tuning happens. So, there's a little extra command-channel overhead.
>>>
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> USRP-users@lists.ettus.com
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
