Re: [USRP-users] Consequences of late command

[Fabian Schwartau via USRP-users]

Hi Darek,

I thought I solved this issue but it came up again.
From time to time I get the late command error. I get it when calling 
the revc method for the receive stream. In that moment there is no data 
returned from the call (return value is 0). I get these results a couple 
of times and after that the error code indicates timeout error and I get 
no more data - never. My program is stuck while waiting for the 
requested data to arrive.
If I understood corretly this should not be the case. I should get the 
data anyway, right?


Best regards,
Fabian

Am 07.06.2018 um 13:47 schrieb Derek Kozel:

Hello Fabian,

Commands which are late will be executed anyways and return the error 
notification which you are seeing. Commands after it are also executed. 
Depending on your application it is often possible to structure the 
commands such that get_time_now only needs to be called in the beginning 
and the act of receiving can be used to keep track of the device time. 
The TwinRX fast frequency hopping example does this, allowing for 
continuous and stable frequency hopping and burst receiving at a very 
high rate.


Regards,
Derek

On Thu, Jun 7, 2018 at 12:12 PM, Fabian Schwartau via USRP-users 
mailto:usrp-users@lists.ettus.com>> wrote:


Hi everyone,

I am currently working with timed commands to perform synchronized
reception of multiple channels. As the timing is quite critilical I
would like to use quite low delay I add to usrp->get_time_now() for
the next command(s). However, sometimes it happens (even with quite
high values like 20ms) that I get an late command error when reading
the data from the stream. I guess this can happen from time to time
if the thread was interrupted by the OS to do other stuff. And this
is not a problem, if it happens just from time to time. But I don't
know how to handle the problem.
Is the command that was too late executed anyway? What about the
commands after that?
Is there is simple way to get in a clean state after receiving this
error? Like delete all commands in the queue and clear all buffers?

I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are
synchronized over all boards.

Best regards,
Fabian

___
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

Re: [USRP-users] Consequences of late command

[Derek Kozel via USRP-users]

Hello Fabian,

Commands which are late will be executed anyways and return the error
notification which you are seeing. Commands after it are also executed.
Depending on your application it is often possible to structure the
commands such that get_time_now only needs to be called in the beginning
and the act of receiving can be used to keep track of the device time. The
TwinRX fast frequency hopping example does this, allowing for continuous
and stable frequency hopping and burst receiving at a very high rate.

Regards,
Derek

On Thu, Jun 7, 2018 at 12:12 PM, Fabian Schwartau via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi everyone,
>
> I am currently working with timed commands to perform synchronized
> reception of multiple channels. As the timing is quite critilical I would
> like to use quite low delay I add to usrp->get_time_now() for the next
> command(s). However, sometimes it happens (even with quite high values like
> 20ms) that I get an late command error when reading the data from the
> stream. I guess this can happen from time to time if the thread was
> interrupted by the OS to do other stuff. And this is not a problem, if it
> happens just from time to time. But I don't know how to handle the problem.
> Is the command that was too late executed anyway? What about the commands
> after that?
> Is there is simple way to get in a clean state after receiving this error?
> Like delete all commands in the queue and clear all buffers?
>
> I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are
> synchronized over all boards.
>
> Best regards,
> Fabian
>
> ___
> 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] Consequences of late command

[Fabian Schwartau via USRP-users]

Hi everyone,

I am currently working with timed commands to perform synchronized 
reception of multiple channels. As the timing is quite critilical I 
would like to use quite low delay I add to usrp->get_time_now() for the 
next command(s). However, sometimes it happens (even with quite high 
values like 20ms) that I get an late command error when reading the data 
from the stream. I guess this can happen from time to time if the thread 
was interrupted by the OS to do other stuff. And this is not a problem, 
if it happens just from time to time. But I don't know how to handle the 
problem.
Is the command that was too late executed anyway? What about the 
commands after that?
Is there is simple way to get in a clean state after receiving this 
error? Like delete all commands in the queue and clear all buffers?


I am using two USRP X310 with each 2 TwinRX. PPS, 10 MHz and LOs are 
synchronized over all boards.


Best regards,
Fabian

___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com