discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] USRP for two way ranging


From: Mattia Rizzi
Subject: Re: [Discuss-gnuradio] USRP for two way ranging
Date: Wed, 27 Jul 2011 12:27:53 +0200

Thank you all.
Perphas my idea was not explained very well.
The basic assumption is that i can calculate time since i can count samples.
If i receive an echo starting from RX sample nr. 12000 and another echo starting from sample nr. 13230, then i can say that the time between two echo is 1230*Ts.
The problem was how to time-correlate between the rx stream and the tx stream from USRP.
Let’s assume (for clarity) that USRP1 has 64Ms/s ADC and 64 Ms/s DAC.
Before starting acquisition&transmission, i pre-fill the tx buffer of the USRP with some dummy samples (preventing underflows) and set
rx_sample_counter = 0; tx_sample_counter=1000 (dummy samples).
At t=0 i start acquisition&transmission.
After Ts, the first incoming sample is sampled and the first rx sample is transmitted.
So, i detect an echo starting from sample nr.12000 and i prepare a reply. I prepare the samples for transmission, looking tx_sample_counter and with a simple subtraction i can calculate the time elapsed between the acquisition of sample nr.12000 and the departure of the first sample associated to the reply.
It can’t work?
 
Sent: Wednesday, July 27, 2011 4:27 AM
Subject: Re: [Discuss-gnuradio] USRP for two way ranging
 
Also, take a look at this brief related discussion from a few weeks ago:
http://lists.gnu.org/archive/html/discuss-gnuradio/2011-06/msg00103.html
 
Kunal


On Tue, Jul 26, 2011 at 8:49 PM, Colby Boyer <address@hidden> wrote:
You would need a very very accurate real time guarantee on how long it would take to process/detect an echo, and then to respond to it. To my knowledge the GNURadio framework cannot make that guarantee, in general. I would not try to depend on getting an accurate time for signal processing delay and Linux delay.
 
Look at the UHD driver and see if you can be creative with the driver calls. That is your best bet, honestly. With UHD you can schedule clock accurate transmit bursts and receive bursts.
 
--Colby
 
 
On Tue, Jul 26, 2011 at 5:33 PM, Mattia Rizzi <address@hidden> wrote:
The two device are not clock syncronized.
My end goal is clock syncroniztation & ranging.
The true problem is if it’s possible to compute the time difference between an incoming sample and a outgoing sample from USRP. This is critical since i have to compute the time elapsed (due to calculation & delays from Linux) between the received echo and the outgoing reply. I suggested a method to do this task, can it work?
Thanks
 
Sent: Wednesday, July 27, 2011 2:17 AM
Subject: Re: [Discuss-gnuradio] USRP for two way ranging
 
This might be possible to do if both devices have access to the same and very accurate clock, e.g. GPS. 
 
What is your end goal?

On Tue, Jul 26, 2011 at 3:59 PM, Mattia Rizzi <address@hidden> wrote:
Hello.
I need to implent a two way ranging. A device send an “echo”, a second device discover the “echo” and send a reply, then the first device can calculate the distance. For a correct distance evalutation, the second device must calculate the time elapsed between the discover of the first echo and the reply response.
Let’s assume that the second device is a SDR with gnu radio & USRP1 device.
The problem is: how to time-correlate the streaming sample received from the USRP and the streaming sample transmitted to the usrp.
If i pre-fill the usrp transmit buffer with dummy data (preventing underflows) before starting acquisition&transmission, then i can correlate the two streams, right? (Yes, with the hypothesis that i don’t miss data from usb).
Thank you

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 
 

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

 

reply via email to

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