On Mon, Feb 23, 2009 at 12:43 AM, Nick Withers <[email protected]> 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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
