Hi everyone,

I am currently using two Ettus x440 devices. To develop my application 
correctly I need to send and receive two signals between them (each device has 
to implement one transmitter and one receiver). This signal exchange must occur 
on different time. The thing is that, this time mismatching, must occur in 
short times, in order of nanoseconds, so I need to control the "sender" and 
"receiver" objects with high time resolutions. The code related to what I am 
saying is the following one:

// in the receiver this is the command which controls the time where the 
receiver is began to listen

                    *stream_cmd.time_spec = timeInit+uhd::time_spec_t(ATdma);*  
  

// in the transmitter this is the command which controls the time where the 
transmitter is began to send the signal buffered

                    *md.time_spec = timeInit+uhd::time_spec_t(ATdma);*

// with timeInit = usrp->uhd::get_time_now()+uhd::time_spec_t(0.25) & ATdma = 
double(1e-7)

My questions here are the following:

 1 - When ATdma is lower than tenths-hundreds of microseconds, the time 
controlled by the previous lines are changed to zero, so there is no 
displacement between simples. Does uhd::time_spec_t has no the enough 
resolution to represent this kind of decimals? Or maybe is the hardware which 
does not support this kind of resolutions?

 2 - If it is a negative answer on 1st questions, maybe the problem could be 
given by the data type (double)? I do not think that the problem could be given 
by the data type, because this kind of data use floated point for the number 
representation, but maybe I am wrong.

 3 - If none of those question is the problem, could I use 
"to_tick"/"from_tick" functions to achieve those resolutions? I tried to do 
this, but I do not know how, if time_pect_t variable always set the time with a 
integer part and a fractional part, and tick functions only gives integers, 
right?

Thank you all for read/respond to my questions. I hope I would have explained 
my self on a properly manner.
_______________________________________________
USRP-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to