[USRP-users] Precise transmit control of X310

Martin Braun martin.braun at ettus.com
Thu Oct 29 15:04:08 EDT 2015

Marcus is right, the most important aspect being that we're trying to
abstract the tick rate out of the time spec.


On 28.10.2015 03:01, Marcus Müller via USRP-users wrote:
> Hi Carel,
> to be honest, that's a good question and I can't answer it, because I
> wasn't around when the timespec_t was changed from having a counter for
> "ticks" in the fractional seconds to double fractional nanoseconds, to
> double fractional seconds later on.
> Rationale here might be:
> an integer for the fractional seconds would only make sense if you're
> actually counting in multiples of the tick rate of the individual device
> that will execute the command; it doesn't make sense to tell a device
> that runs with a fixed rate of 100MHz to tune at 12.5ns, but with a B200
> that might as well run at 32MHz, that might make a lot more sense than
> using whole nanoseconds. And then, there are 4G-compatible tick rates
> like 184.32MHz ... . So the double gives you enough precision let you
> correctly represent any "ticked" time for any of the foreseeable devices.
> Best regards,
> Marcus
> On 28.10.2015 06:32, Carel Combrink wrote:
>> Hi Marcus,
>> Thank you for the answers, it helps a lot. 
>>     Regarding the time stamps: Internally (and on the wire), the time
>>     stamps are transmitted as to fixed point numbers for the full
>>     seconds and the fractions of the second. 
>> Â 
>> Out of curiosity (if I may ask), why is uhd::time_spec_t using a
>> double instead of something like a unsigned long for the fraction
>> part? The timespec struct (in time.h) handles it using a time_t and a
>> long. 
>> Regards,
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

More information about the USRP-users mailing list