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

[Nick Withers]

On Mon, 2009-02-23 at 07:19 -0800, Johnathan Corgan wrote:
> 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!

Yes, certainly feeling a little overwhelmed!

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

Thanks very much, dare say I'll take you up on this!

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

At this point, that's pretty well what I want to do. I want to smack as
much as possible in the FPGA (well, on the non-PC side of the USB,
anyway) and essentially only transfer configuration information and
returned base-band samples to / from the PC.

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

I *believe* that this suits me down to the ground, given that I want to
do as much as possible in the FPGA...

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

Should be plenty, I think, given that I want to throw baseband samples
back to the PC... But I may well be missing something here!

> 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've come across this a couple of times in Googlin', but didn't quite
know what it was - thanks, I'll have a closer look.
> 
> 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.

As I understand it, I should be right with timing if I do "everything"
on the USRP... No? I'm going to need to do some work on ensuring
pipeline delays between the FPGA and the RF world are configured
properly...

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

I was planning (down the road, mind you) on doing Barker codes on the
USRP1 FPGA, using a local (CORDIC?) oscillator. I can't think of any
reason why this wouldn't work... But then I probably wouldn't be able
to! :-)

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

This would be good, yes. I'm currently fiddling with the Altera IP
(soft) multipliers, which would I imagine allow me to do this...?

> 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!

Thanks very much for your interest and help, it's very helpful and
confidence-building!

> Johnathan
-- 
Nick Withers
email: address@hidden
Web: http://www.nickwithers.com
Mobile: +61 414 397 446

signature.asc
Description: This is a digitally signed message part