[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:
> 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,
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
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,
>> 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