Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.

[Johnathan Corgan]

On Mon, Feb 23, 2009 at 12:43 AM, Nick Withers <address@hidden> wrote:

> my honours for a Bachelor of Engineering degree, to implement a
> pulse-doppler RADAR wind profiler (some information at
> http://nickwithers.com/usrp-wind-profiler).

Welcome.  You've chosen a rather more advanced application of GNU
Radio and the USRP than most beginners, but have fun!

> If anyone's interested, perhaps doing something similar, or with tips
> they can offer off the top of their noggin I'd love to hear from you :-)
>
> I'm basing my work off Johnathan Corgan's radar-mono code (thanks
> Johnathan!) and have a couple of questions I was hoping someone could
> point me in the right direction with (dare say I'll be getting referred
> straight to the FAQ, it's all a bit overwhelming!).

I'd be happy to answer questions on or off the list for you.

The gr-radar-mono code is a couple years old at this point, and was a
fairly purpose-specific implementation of custom FPGA code for USRP1.
Using the FPGA was the only way to obtain the kind of strict timing
and more importantly the sample rates needed for that project.  Also,
there is no radar specific processing done there; the code works only
as a timed chirp transmitter and receiver and records the raw returns
to file for offline processing.

>> I want, if possible, to bypass the DAC's interpolation, filtering etc.
>> (the chief reason being to avoid the 44 MHz upper-bound on signals I can
>> output from it (I'm using the Basic{T|R}X boards and aiming to work
>> around 70 MHz), see http://www.gnuradio.org/trac/wiki/UsrpFAQ/DUC
>> (incidentally, I've done a crap job of finding supporting information in
>> the AD9862 data sheet)). Do I need to rewrite the C++ code (e.g.,
>> usrp/host/lib/legacy/usrp_standard.cc) if I want to continue to use
>> usrp_source_?() / usrp_sink_?() and such from Python? Any tips on how I
>> go about doing it? Can / should I just rewrite the DAC configuration
>> from within the FPGA when it's initialised?

You can of course modify the libusrp C++ code to change the AD9862
register configuration, but that's not the biggest challenge you'll
have.  The GNU Radio gr-usrp component that creates the source and
sink blocks are designed to operating in "continuous streaming" mode;
that is, they provide continuous samples with no boundaries or timing
relationship between the TX and RX side.  Furthermore, depending on
the range resolution you need, the 8 MHz of passband bandwidth that
the USRP1 can transport over the USB may not be enough.

There is an alternative, low-level, C++ only (no Python) interface to
the USRP1 written to use the "mblock" library, and provides the
ability to read and write timed, fixed length sample vectors.  This is
a harder task than writing streaming applications in Python, and still
has the 8 MHz bandwidth limitation, but it would let you accomplish
what you want.  See the 'in-band' code that is maintained by George
Nychis at CMU.

I'd recommend using the USRP2 for this project, for three reasons.
First, if you decide to implement your application on the host, you
have much more bandwidth between the host and the USRP2 (~25 MHz),
which would give you higher range resolution.  Second, the libusrp2
C++ interface has the timed transmit and receive functionality without
the need for the mblock library, so going the low-level C++ route is
easier than with the USRP1.

But most importantly, the USRP2 FPGA has much more room and is
explicitly organized to make writing custom FPGA images easier, using
native Linux tools from Xilinx.  If you have HDL programming skills, I
think this is the shortest route to get what you want.  Your waveform
generation can occur in logic, and its easy to generate FM chirps or
Barker codes or whatever you need.  You can use state machines to
handle sequencing of TX and RX, and with the Spartan3 multipliers, you
can even do de-chirping or cross-correlation of your receive waveform
before it gets to the host.  The host code in this case would be RX
only and could be done in the Python streaming domain.

Anyway, good luck with whatever route you choose to go, and keep us posted!

Johnathan