Hi, "time_spec_t" can be set with one 'double' as in your code or with one 'int64' and one 'double' as indicated in the second example below (where the first is the integer portion and the second is the fractional portion) . If you use just one double, it is likely the cause of the precision issue. See these examples below (produced by Gemini). Rob
// Get the absolute time in split format (full precision preserved) uhd::time_spec_t timeInit = usrp->get_time_now() + uhd::time_spec_t(0.25); // Create a high-precision relative time specifier for your delta (e.g., 100 ns) uhd::time_spec_t delta_t = uhd::time_spec_t(0, 1e-7); // Operators safely combine full seconds and fractional parts without losing resolution stream_cmd.time_spec = timeInit + delta_t; On Fri, Jun 19, 2026 at 3:57 AM Rubén Serrano via USRP-users < [email protected]> wrote: > 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] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
