Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
On Mon, Feb 23, 2009 at 7:53 PM, Nick Withers n...@nickwithers.com wrote: Yes, certainly feeling a little overwhelmed! You wouldn't be the first. 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. For the reasons I mentioned, then, your are better off with the USRP2. 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! You need to calculate the overall data rate that needs to be sent to the host, which depends on your PRF, baseband sample rate, and range gate duration. 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... Yes, but it's not a big deal. The bigger issue I encountered was accounting for the turn-around time in the transmitter power amplifier and antenna switch. It was almost a microsecond after the end of the chirp before the PA sensed the end of the power burst and switched to receive. This limited the minimum range to a few hundred meters. 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...? You will run out of room very quickly with the USRP1 if you use these. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
Just resending as this didn't seem to get through to the list...
Presumably I must be subscribed to post?
On Tue, 2009-02-17 at 20:37 +1100, Nick Withers wrote:
Hi all,
I'm new to GNURadio / the USRP, but am working on a project, as part of
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).
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 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?
Any tips appreciated!
--
Nick Withers
email: n...@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
signature.asc
Description: This is a digitally signed message part
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
On Mon, Feb 23, 2009 at 12:43 AM, Nick Withers n...@nickwithers.com 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
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
On Mon, 2009-02-23 at 19:43 +1100, Nick Withers wrote:
Just resending as this didn't seem to get through to the list...
Presumably I must be subscribed to post?
On Tue, 2009-02-17 at 20:37 +1100, Nick Withers wrote:
Hi all,
I'm new to GNURadio / the USRP, but am working on a project, as part of
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).
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 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
You could also use the first mirror frequency
When the DUC is set to 44 MHz you get a signal at 44 Mhz and a mirror at
128-44=84 Mhz. (second niquist zone)
84 Mhz is as low as you can go with this setup, but maybe 84 MHz is
close enough to 70 for you to use.
(You would need a bandfilter to only keep this mirror)
Success,
Martin
(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?
Any tips appreciated!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
On Mon, 2009-02-23 at 07:19 -0800, Johnathan Corgan wrote:
On Mon, Feb 23, 2009 at 12:43 AM, Nick Withers n...@nickwithers.com 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
Re: [Discuss-gnuradio] Re: Pulse-doppler RADAR wind profiler project and how to bypass interpolation, DAC filtering, etc.
On Mon, 2009-02-23 at 07:45 -0800, Eric Blossom wrote:
On Mon, Feb 23, 2009 at 07:43:08PM +1100, Nick Withers wrote:
Just resending as this didn't seem to get through to the list...
Presumably I must be subscribed to post?
Yep.
On Tue, 2009-02-17 at 20:37 +1100, Nick Withers wrote:
Hi all,
I'm new to GNURadio / the USRP, but am working on a project, as part of
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).
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 :-)
Looks interesting. Good luck with it!
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 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),
OK.
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)).
It's a complicated part. And there are a few bugs in the data sheet
(mostly mislabeled diagrams). I don't have mine in front of me, but
look for the section on configuring the DAC. There are many diagrams
showing possible configurations, depending on whether you want real or
complex output. We've got it configured for complex output so that we
can use the digital upconverter.
Which I want (have?) to use to, to get to 70 MHz.
They call it the coarse and fine
modulator. We use both features. You can have it interpolate less on
chip (we use 4), but then you've got to feed it data at a faster rate,
and the filtering will be worse. We drive the The two DACs with two
streams at 128 MS/s. (Without looking at the data sheet and/or the
code, I don't remember how we do that. I think it's interleaved, but
it may be pumped on opposite clock edges.)
Can you say more about your requirements? E.g., what RF range are you
trying to access? Center and bandwidth of your desired signal? Is it
centered at 70MHz or is 70MHz the top? Will you be using an external
upconverter? (I'm clueless about what RF range is used for wind
measurement.)
For my part I want to transmit and receive at 70 MHz (externally it'll
be mixed up/down to/from 1280 MHz). I've got a 5 MHz to play with, with
should be more than enough, I believe.
I've been told I need to do coherent detection to maximise the SNR
(which'll be really, really low, circa -40 dB, owing to the returned
signal being bounced off air...).
I'm currently trying to set up a CORDIC mixer in the FPGA between 26 MHz
and 32 MHz so that I can throw this to the DUC and have it produce a 70
MHz output wave. There's an external analog 5 MHz filter at the
transmitter output.
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?
Depending on how much you're changing around the DAC configuration,
you may be able to do all the AD8962 reconfiguation from python on the
host. usrp_basic has _write_9862 and _read_9862 methods that are
exported to python. You can probably reuse the usrp_basic and maybe
usrp_standard, depending on your situation. The stuff you don't need
you can ignore.
Good stuff, cheers. I was a bit worried about using these low-level
functionality methods after initialising the standard code.
Johnathan may have additional comments...
You've both been very helpful!
Eric
--
Nick Withers
email: n...@nickwithers.com
Web: http://www.nickwithers.com
Mobile: +61 414 397 446
signature.asc
Description: This is a digitally signed message part
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
