Re: [Discuss-gnuradio] Active Radar

[Eric Blossom]

On Wed, Jun 14, 2006 at 02:00:27PM -0400, Lee Patton wrote:
> Hi, folks -
> 
> I'm trying to build an active pulsed radar using GR/USRP. Right now I am
> only concerned with the transmission and reception of pulses.  All radar
> signal processing will happen offline.  I know Eric is working on
> passive radar. Has anyone tried active yet? 

Sounds like fun!

> I have a start on the Tx and Rx blocks, but I'm looking for suggestions
> -- especially with regard to timing and synchronization. The following
> is an overview of what I've got so far:
> 
> Tx. Block:  Basically, the constructor accepts the pulse repetition
> frequency and a file containing the baseband transmit signal.  The work
> method looks at the system time each call to determine whether or not it
> should let loose another pulse.
> 
> Rx. Block:  I can't possibly log all samples due to memory limitations.
> So, the work method attempts to record only a time gated subset of the
> received samples.  (This works for my application because I have an idea
> where the target is.)  The Rx block constructor  accepts a pointer to
> the Tx block so that it can access the time of transmission for the last
> pulse. It also accepts the delay to wait before recording pulse data, as
> well as the number of samples to record for each pulse.
> 
> The real problem is timing and synchronization.  Below is a block
> diagram that helps illustrate the problem.
> 
>          |---------  Ta  -------------|------ Tb ----|  
> Tx Block --> GR Scheduler --> USB --> USRP --> real world
>    .                                                   |
>    .                                                   |
>    .                                                delay T
>    .                                                   |
>    .                                                   |
>   \ /                                                 \ /
>    '                                                   '
> Rx Block <-- GR Scheduler <-- USB <-- USRP <-- real world
>          |---------  Ra  -------------|------ Rb ----|  
> 
> 
> I'm trying to measure T, but there are unknown delays:
> 
>  - Ta, time pulse is put into the buffer until time it reaches USRP. 
>  - Tb, time pulse reaches USRP until time it leaves antenna
>  - Rb, time pulse arrives at antenna until time it reaches USB
>  - Ra, time pulse leaves USRP until time it is recorded in Rx. block
> 
> I assume Tb & Rb will be relatively constant and Ta & Ra will be more
> variable.  I have access to a digital RF memory. So, I hope to measure
> the aggregate of Ta and Tb. I'm not sure I have the equipment to measure
> Ra & Rb.
> 
> Obviously, I need very precise timing and synchronization. I need to
> transmit at very precise intervals, and record at very precise times
> after *real world* transmission.  I'm thinking of counting samples
> instead of using the system clock to determine relative times, but I
> haven't figured out how to synchronize this between Tx and Rx blocks.
> 
> Also, ideally, I would be able to transmit at 3kHz with a pulse width of
> 13us.  Our application won't let me deviate too much from that, but I'll
> have to take what I can get.
> 
> I will be very appreciative of any insights anyone has into this
> problem.
> 
> 
> Thanks and regards
>  - Lee

Hi Lee,

If you solve all these problems, I'd be most appreciative ;)

I don't have a short term fix for you, but the basic path we're going
to be headed down will include "inband signaling" on the USB and Tx
and Rx timestamps in the packets.

This is part of what the mblock proposal from BBN is trying to make
easier to do.  The ultimate timing control will be in the FPGA.
Imagine a free running counter in the FPGA clocked at the master clock
rate (64M).  On the receive path, each USB packet will have a fixed
length header that includes the sample clock value that corresponds to
the first sample in the packet.

On TX, the idea is to have a timestamp in the header that says "do not
transmit before time t".  There will be some way to map "frames"
(variable length things possibly bigger or smaller than a USB packet),
into something we keep track of across the USB.

With these two primitive operations, what you're trying to do gets
much easier.

If you have the time and inclination to work on any of the low level
timing stuff, I can definitely assist.  We'll need it sooner or later,
and if you're interested in working on it now, that would be great!

It shouldn't take more than a couple of days effort to work out the
format of the packets across the USB and a basic plan of attack.  The
code in the FX2 won't need any changes, it just passes them along.

The verilog will need substantial work, and the host code will need a
bit of tweaking, but that shouldn't be hard.  Pretty much just a
matter of adding and removing a header from the packet.

Last month I had a very successful trip to Virginia Tech, and we got a
lot done together.  I'm willing to consider doing something similar at
Wright, particularly if there are at least two or three people who are
interested and willing to invest some time and effort.  

I'll make the same offer to any other group of GNU Radio users: if
you've got people who are mostly up to speed, are trying to use GNU
Radio do get something done, and are willing to to invest the time and
effort, I'm willing to consider a visit to your site to work with you
on getting your problems solved.  All of this is subject to my
availability, funding for travel, etc.

Eric