[USRP-users] Bug in timed switching of sample rate

Marcus D. Leech patchvonbraun at gmail.com
Mon Feb 4 07:39:28 EST 2019

On 02/04/2019 07:05 AM, Fabian Schwartau wrote:
> Hi,
> thanks for the update.
> Where can I access the bugtracker to keep track on this issue? Or is 
> it an internal one?
> Is there a plan to implement this feature in the near future?
> Best regards,
> Fabian
The *public* repo tracks issues here:


But the issue is being tracked on the *internal* bugtracker, to which 
you don't have access.  Making it work is fairly difficult, I 
understand, and
   requires some structural upheaval.

> Am 29.01.2019 um 16:11 schrieb Marcus D. Leech:
>> On 01/29/2019 09:23 AM, Fabian Schwartau via USRP-users wrote:
>>> Hi Xavier,
>>> sorry for the late answer. I missed your mail.
>>> It might be related, but I don't know exactly. I am not a software 
>>> expert and it is driving me crazy. In my case it seems like it makes 
>>> no difference if I time the command or not, it is executed right 
>>> away. As the record instruction is set in the future (after the 
>>> timed sample rate switch), the recording fails to too few/many 
>>> samples as the USRP switched the sample rate too early and messed up 
>>> the record command.
>>> Marcus also did not came back yet, so I am still stucked and I wrote 
>>> a work-a-round to wait for all operations beeing finished before 
>>> executing the sample rate switch. But this is quite bad, as I need a 
>>> lot of time until I can send a new command with the changed sample 
>>> rate. As I am continously switching frequency/sample rate and other 
>>> parameters, waiting for the command buffer to be empty is currently 
>>> cusuming most of the time and my switching rate is very limited.
>>> Hope this can be fixed at some point.
>>> Best regards,
>>> Fabian
>> Based on the bugtracker data from R&D, making DDC/DUC rate changes 
>> (which is sample-rate changes) covered by timed commands is
>>    a pending feature.

More information about the USRP-users mailing list