Hi Harry -
Actually, the name `tick_rate` is somewhat confusing. The tick_rate refers
to the clock rate that the DSP chain runs at. Here is a bit of code
regarding the tick_rate from the USRP2 / N-Series implementation that might
make things a little more clear:
_tree->create<double>(mb_path / "tick_rate")
.publish(boost::bind(&usrp2_clock_ctrl::get_master_clock_rate,
_mbc[mb].clock))
.subscribe(boost::bind(&usrp2_impl::update_tick_rate, this,
_1));
Marcus explained things correctly in his e-mail. So, on an N-Series device,
the time step between samples is 1/100e6 = 10 ns.
Cheers,
Ben
On Tue, Nov 26, 2013 at 5:49 AM, Harry Zhang <zhang...@gmail.com> wrote:
> Dear Marcus,
> Thank you for your reply.
> I'm confused about two concepts. Referring to the file time_spec.hpp
> in UHD, fractional sec is calculated according to the parameter ticks and
> tick_rate. So I think the time granularity is '1/tick_rate' which is
> 0.1us using 10Mhz clock. But for the timestamp of sample stream, the
> granularity is the sample duration. Is it correct?
>
> Best,
> Harry
>
> 2013/11/26 20:12, Marcus Müller wrote:
>
>> Hi Harry,
>>
>> as far as I know, the granularity of a time stamp is the sample duration
>> at the downsampled side.
>> As for the 10MHz: The 10MHz clock is used to derive different other
>> clocks, especially the rx ADC and tx DAC clocks, which are an order of
>> magnitude higher; bear in mind that when you request e.g. "5MHz samle rate"
>> you still get the 100MHz* samples of the ADC, but downsampled by a factor
>> of 20.
>>
>> Please also bear in mind that due to physics, processing etc the
>> timestamp of the rx side is delayed to the actual reception of "that
>> sample", and that this delay is largely constant when receiving using the
>> same settings, but my change based on sampling rate and other factors.
>>
>> Greetings
>> Marcus
>>
>> *for USRP2 arch, if I remember correctly.
>> On 26.11.2013 13:04, Harry Zhang wrote:
>>
>>> Hi,
>>> Since we can get receive time of rx_stream's first sample via rx tags, I
>>> have two questions about the time granularity. Given the internal clock
>>> is 10Mhz, is the time granularity 0.1us? The fractional second is stored
>>> double type. Does it mean the last digits of the fractional sec are
>>> invalid?
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>
>>
>> _______________________________________________
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
