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

[Miklos Maroti]

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
artifacts.

Miklos

>
> Best,
> Harry
>
>
> 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.
>>
>> Best,
>> Miklos
>>
>> 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
>>> 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.
>>>
>>>
>>> 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.
>>>
>>> Miklos
>>>
>>> On Thu, Oct 10, 2013 at 3:51 PM, Harry Zhang <address@hidden> wrote:
>>>
>>> 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.
>>>
>>> _______________________________________________
>>> Discuss-gnuradio mailing list
>>> address@hidden
>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>>
>>>
>