Tom,
Thanks for your reply.
I got a weird problem when using rx_time tags. I have three nodes,
node A sends 10 packets within 0.2 sec ,stops for 1sec sends 10 packets
, stops..., sends....,stops.... . Node B and C receive it and record
the receive time using (rx_time+ sample_count*sample_rate).
Considerating the clock offset between B and C, the difference of B and
C's receive time must remain stable. But every time after A stops for
1sec, the receive time's difference varies several hundreds of
microsecond. I'm stumped by this problem.
Could you give me some advice. Thank you in advance.
Harry
2013/11/1 22:26, Tom Rondeau wrote:
> On Thu, Oct 31, 2013 at 3:46 AM, Harry Zhang <zhangnow@gmail.com> wrote:
>> Hi,
>> As far as I know rx_time tag is associated with the first sample of a
>> receive stream. If I wanna get multiple rx_time tags while receiving
>> continuous data, should I stop and issue a new stream again and again
>> for getting more rx_time tags.
>> Thank you.
> Harry,
>
> We want to minimize tags through the flowgraph since it adds overhead.
> The UHD driver only sends an rx_time tag whenever one is necessary.
> That means that if there is a chance that the host has become
> unsynchronized, it sends an updated tag. So there's one at the
> beginning of the stream to set the initial time. Then, if a dropped
> packet or overflow are detected, it sends a new rx_time tag.
>
> Between time tags, you can count samples and you know the sample rate,
> so you know the time of every sample based on that initial rx_time tag
> (to within the tolerance of the sample clock on the USRP).
>
> Tom
>
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment