Forum: GNU Radio Time synchronization between two USRPs without external signal

B9ce6049ae836a643465aa4ba3d279e0?d=identicon&s=25 Harry Zhang (Guest)
on 2013-10-10 15:53
(Received via mailing list)
Hi,
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.
Db9007730414df194ad858610ab362e3?d=identicon&s=25 Miklos Maroti (Guest)
on 2013-10-12 03:04
(Received via mailing list)
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.

Miklos
B9ce6049ae836a643465aa4ba3d279e0?d=identicon&s=25 Harry Zhang (Guest)
on 2013-10-12 10:11
(Received via mailing list)
Dear Miklos,
     I'm glad to hear from you.
     The idea of this experiment is quite similar to the core of your
honored 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.
Using rx tags, it's easy to get the average receive interval is
1.0003sec and the jitter is around 320us. Considering the interval
jitter is 2*(rx jitter+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
details.
Db9007730414df194ad858610ab362e3?d=identicon&s=25 Miklos Maroti (Guest)
on 2013-10-12 13:19
(Received via mailing list)
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.

Best,
Miklos
B9ce6049ae836a643465aa4ba3d279e0?d=identicon&s=25 Harry Zhang (Guest)
on 2013-10-12 15:13
(Received via mailing list)
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?
     2.For 1us accuracy, does it mean the sample rate must be more than
1e6?
     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?
     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?

Best,
Harry
Db9007730414df194ad858610ab362e3?d=identicon&s=25 Miklos Maroti (Guest)
on 2013-10-16 14:21
(Received via mailing list)
Hi Harry,

On Sat, Oct 12, 2013 at 3:12 PM, Harry Zhang <zhangnow@gmail.com> 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
artifacts.

Miklos
B9ce6049ae836a643465aa4ba3d279e0?d=identicon&s=25 Harry Zhang (Guest)
on 2013-10-26 05:27
(Received via mailing list)
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,
Harry
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.