How to get multipe rx_time tags while receiving continuously

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.

On Thu, Oct 31, 2013 at 3:46 AM, Harry Z. [email protected] 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

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

Dear Miklos,
Yes, I do never stop receive program. I’m using USRP N210, WBX,
Ubuntu12.04 and UHD3.5.3. I’m writing a document in detail, which will
be sent to you later today.

Best,
Harry

Hi Harry,

You never stop the receiver on node B and C, right? You should not
observe anything like that if you do not have dropped packets. Are you
using USRP2’s?

Miklos