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:
https://github.com/EttusResearch/uhd/issues
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.
_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
