[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Time synchronization between two USRPs without ex

From: Harry Zhang
Subject: Re: [Discuss-gnuradio] Time synchronization between two USRPs without external signal
Date: Sat, 26 Oct 2013 11:25:29 +0800
User-agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8

Dear Miklos,
I got a weird problem while running the sync method(Node A transmit the sync messages,node A and B receive them). I control A transmit continuously for 0.2sec and stop for 2sec,repeat this.In the 0.2 sec period, node A could transmit 20 sync message and the difference of A and B's receive timestamp remain stable(such as 3.205122sec), the standard deviation of it is about 5us,which is good. But when transmitting again after 3sec stop, the difference of A and B's receive timestamp is completely different with the previous one(changed to 3.245897sec but also stable). The difference is about .Considering the clock drift is small(about 2.5ppm),the the difference of receive timestamp between node A and B should remain unchanged in several minutes.So I think it's not caused by the clock drift in such a short time.
    What maybe cause this problem?
    Thanks in advance.

Best Regard,

2013/10/16 20:20, Miklos Maroti wrote:
Hi Harry,

On Sat, Oct 12, 2013 at 3:12 PM, Harry Zhang <address@hidden> wrote:
Dear Miklos,
     Thank you for your inspiring reply.
     1.I do think this method sounds like a receiver-receiver sync while sync
message's transmitter A also doing beacon node C's function ( (1)sending
sync message and (2)recording receive time which would be sended to B for
sync).Is it correct?
Well, it is a transmitter-receiver synchronization, since only two
nodes are involved A and B, and only A sends, B only receives. The
real problem is to correlate samples with time, and I have used the RX
chain sample counter as "time" both on node A and B. You cannot use PC
time because of large errors over ethernet/USB so you have to use the
clock of the FPGA.

     2.For 1us accuracy, does it mean the sample rate must be more than 1e6?
Yes, of course. But you can even synchronize at 10 times the sampling
rate (hard, but not impossible), i.e. you would use 1e6 sampling rate
and get 1e7 precision.

     3.Does "close to zero samples" means the sample_rate*sample_offset
produces larger error when I use it for getting sync message's receive time?
close to zero samples is complex numbers 1e^-4 + 1e^-4*j. The reason I
do not use zero complex numbers is because I am afraid that the FPGA
switches off the TX chain if you continuously try to transmit zeros. I
am not sure that it does, you can experiment with that.

     4.The 1us is the jitter caused by sample duration.What about the jitter
produced by tx/rx tags? I do think 160us is mainly caused by the difference
between actual time when message leaving/arriving antenna and tx/rx tags's
time.What's your opinion?
I do not know about the tx/rx tags. Of course the FPGA needs time to
do the DSP, so it is possible that what you are seeing is the DSP
time. However, the DSP time should be almost completely deterministic,
so it cannot be a jitter just some time offset. If you see a jitter,
then I think it must be caused by either ethernet or some DSP startup



2013/10/12 19:17, Miklos Maroti wrote:
Hi Harry,

First, you should always transmit from node A, but when you want to be
silent, then transmit something very close to zero complex numbers.
This will ensure, that you have a nice continuous stream of data going
out, and you can plan to do anything you want with sampling rate
precision (better than 1us). Once you can do this, then transmit some
pseudo random sequence from node A, e.g. BPSK with 2 samples per bit,
and it is possible to synchronize to that with sampling rate precision
again. Now comes the trick: node A not only transmits continuously,
but it also receives continuously just like node B (with an antenna or
just overhearing in the board). Both A and B synchronizes to the
signal transmitted by A. In case of node A you do not have to worry of
slightly different clocks, so once you are synchronized you will never
get out of sync if you count the number of samples. In the case of
node B it is harder, since node A might run a little faster or slower,
so you will get out of sync, so you have to maintain synchronization.
At this point, you have achieved synchronization of the two USRP
nodes: you can stop sending periodically (continue spending close to
zero samples) and then you can sample some data from node C, doing
beam forming (depends on modulation), or whatever. You can correlate
the received samples at node B with the received samples at node A
with close to one sample precision (better than 1us).

If you do not want to transmit all the time, then you can use TX tags,
but it gets a little trickier, and I think there is some bug in the
FPGA hardware to cause very rarely one sample shift between the TX and
RX chain. I am not absolutely sure about this, but I could not explain
something in any other way.


On Sat, Oct 12, 2013 at 10:10 AM, Harry Zhang <address@hidden> wrote:
Dear Miklos,
      I'm glad to hear from you.
      The idea of this experiment is quite similar to the core of your
paper "The flooding time synchronization protocol". It's a
transmitter-receiver sync method using precious tx/rx timestamp to
synchronize transmitter's and receiver's local timer.
      On the transmitter side, sync message is transmitted every 1 sec.
rx tags, it's easy to get the average receive interval is 1.0003sec and
jitter is around 320us. Considering the interval jitter is 2*(rx
jitter), the sync accuracy is 160us.
      I wanna break into USRP FPGA to achieve 1us or less accuracy. And I
don't understand your "continuously transmission". Could give me some

2013/10/12 9:03, Miklos Maroti wrote:

Hi Harrz,

What do you mean by 160us precision? How did you measure it or compute
it exactly? I do not understand your goal, but it is quite simple to
synchronize two usrps with continuous transmission to within one
sample and if you continuously receive the transmitted signal on the
transmitter side, then you can avoid all time stamping problems and
effectively synchronize the tx and rx chains of a single usrp.


On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang <address@hidden> wrote:

I have implemented time synchronization between two USRPs without GPSDO,
MIMO cable or referring to computer's time.It's a sender-receiver method
based on message exchange. It will be included in my next paper soon.
I use the tx_time and tx_sob tag to transmit the message at the planned
time. When this message researches the receiver, I can get the receive
time via rx_time tags. The transmit and receive time of tx tags and rx
tags are recorded in USRP motherboard without the jitter of Ethernet
cable or operating system. So I think it could achieve the best accuracy
without modifying FPGA.
The experiment shows the accuracy is around 160us. I think it's mostly
caused by the jitter of the tx tag's time. I wanna achieve better
accuracy than this and the best way is adding a hardware timestamp
module in FPGA. Is this way feasible?
As for now, I wanna get a depth understanding of the implementing of tx
tag,so I will know the accuracy limit of this method. But I'm not
familiar with the FPGA, so could anyone describe how tx_time tag
implemented or give me some documents about this?
Thanks in advance.

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]