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
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
