Re: [Discuss-gnuradio] Any implementation of Spread Spectrum
Hi Johnathan, can you suggest me a place where I can find more information about the phase sync and the freq sync methods you used in your work. It will be of great help to me. Thanks, Ali. On Tue, Feb 3, 2009 at 6:45 PM, Johnathan Corgan < jcor...@corganenterprises.com> wrote: > On Tue, Feb 3, 2009 at 4:28 PM, Mark Kuhr wrote: > > > So your DSSS code is not yet public? How did you manage waveform > > synchronization among multiple USRPs? > > Not sure I understand your question. My DSSS implementation is a > unidirectional continuous transmitter and separate receiver, > implementing m-sequence based chipping. The receiver performs code > phase synchronization using early/prompt/late correlation power and > frequency synchronization using a Costas loop on the despread BPSK > signal. > > Or perhaps you're asking about multiple, simultaneous > transmitter/receiver pairs. Right now, this is not optimal, as > m-sequences have poor cross-correlation properties, but I'll > eventually put in Gold code generators. While this system was > designed with a completely different purpose in mind, one goal I have > is to eventually be able to use the receiver part of the code as a GPS > L1 demodulator. > > Johnathan > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > -- Mir Murtuza Ali Graduate Student Center for Wireless Communications University of Mississippi University, MS 38677 ___ 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: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
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 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.
Re: [Discuss-gnuradio] Filtering USRP FM Reception
D'oh! Took me long enough to notice that the optfir block generates coefficients, but isn't the filter itself. Putting it into the pipeline directly was a bad idea. So I have transmitter and receiver, and they run without errors... they just aren't giving me what I expect. The filtered sum of sine waves at 320 Hz, 440 Hz, and 650 Hz, when given a passband of 340 Hz and stopband of 800 Hz should produce roughly the 320 Hz sine wave (perhaps with some attenuated elements of the other signals). However, it doesn't appear to be doing so. When played at a sampling rate of 32000, the speakers produce more of a popping sound. Which is still periodic, but isn't a sine wave. The output file is stored as an attachement (which can be viewed in a hex editor or played with audio_play.py), as is the latest revision of the code. Any thoughts? ~ Francesco http://www.nabble.com/file/p22174207/filtered_reception.dat filtered_reception.dat http://www.nabble.com/file/p22174207/usrp_wfm_rcv_filt_nogui.py usrp_wfm_rcv_filt_nogui.py http://www.nabble.com/file/p22174207/wfm_tx_multisignal.py wfm_tx_multisignal.py Francesco B. wrote: > > Hey all, > > I was wondering, is there anything in particular that's peculiar about > using a filter to isolate one sine wave out of three that are being > transmitted over FM? I've attempted adding another FIR (optfir) filter > post-demod, but connecting it to the pipeline produces a long list of > small floats in the terminal (filter coefficients, perhaps?), and then the > program terminates. Otherwise, the program is identical to > usrp_wfm_rcv_nogui.py. It runs as normal when the filter is commented out, > outputting all signals at a specific FM frequency to the sound card. > However, I don't accomplish my task with that. > > What's the proper method for filtering signals, then? It looked fairly > straightforward, but perhaps optfir doesn't function as I was expecting it > to. My code is attached. > > http://www.nabble.com/file/p22029608/usrp_wfm_rcv_filt_nogui.py > usrp_wfm_rcv_filt_nogui.py > -- View this message in context: http://www.nabble.com/Filtering-USRP-FM-Reception-tp22029608p22174207.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] Problem with OTA capture examples
On Mon, Feb 23, 2009 at 03:58:05PM -0800, Vasconcelos wrote: > > Hello, I have the same problem : "audio_alsa_sink[hw:0,0]: unable to support > sampling rate 32000 > card requested 44100 instead. > audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument > Traceback (most recent call last):". How should I proceed to fix it? Please search the web before posting questions here... Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: Re: [Discuss-gnuradio] Problem with OTA capture examples
Hello, I have the same problem : "audio_alsa_sink[hw:0,0]: unable to support sampling rate 32000 card requested 44100 instead. audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last):". How should I proceed to fix it? One more thing, It's my first time using gnuradio and I would like to get some informations. Is there a book "step by step" to build RDS and interfaces with python? Thank you. -- View this message in context: http://www.nabble.com/Problem-with-OTA-capture-examples-tp21053525p22120426.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ 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] Exporting C++ hier_block2s via SWIG
On Mon, Feb 23, 2009 at 05:18:57PM +0100, Martin Braun wrote:
> I was wondering if it's possible to write a gr_hier_block2 in C++ and
> then export it to SWIG just like the the gr_blocks are.
> [...]
> Is there any easy way to do this? Basically, what I want is a
> GR_SWIG_HIERBLOCK_MAGIC() function, I suppose.
> Has anyone done something like this before?
I had a bash at it (not very elegant, though), and tried copying
gnuradio-core/src/lib/swig/gr_swig_block_magic.i into my own i-file. I
then simply modified everything from gr_block to gr_hier_block2. It now
looks like this (slightly truncated for readability):
< CODE >
%include "gnuradio.i"
%{
#include "specest_welch.h"
%}
//
class specest_welch;
typedef boost::shared_ptr specest_welch_sptr;
%template(specest_welch_sptr) boost::shared_ptr;
%rename(welch) specest_make_welch;
%inline {
gr_hier_block2_sptr specest_welch_block (specest_welch_sptr r)
{
return gr_hier_block2_sptr(r);
}
}
%pythoncode %{
specest_welch_sptr.block = lambda self: specest_welch_block(self)
specest_welch_sptr.__repr__ = lambda self: "" %
(self.name(), self.unique_id ())
%}
%ignore specest_welch;
specest_welch_sptr
specest_make_welch(unsigned fft_len, int overlap = -1, int ma_len = 8)
throw(std::invalid_argument);
class specest_welch : public gr_hier_block2
{
< CODE >
It kind of works, but not as smoothly as I could. Here's an example
python session:
< COMMAND LINE >>
[insfl4:gnuradio]% python
Python 2.5.2 (r252:60911, Jul 31 2008, 17:31:22)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from gnuradio import specest
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python2.5/site-packages/gnuradio/specest.py",
line 6, in
import _specest
ImportError:
/usr/local/lib/python2.5/site-packages/gnuradio/_specest.so: undefined
symbol: _ZN14gr_hier_block24lockEv
>>> from gnuradio import gr,specest
>>>
< COMMAND LINE >>
As you can see, I get an error when I only import specest, but not if
import gr and specest. Yep, I'm a nitpicker, but if I run 'from gnuradio
import trellis', I don't get this behaviour, so there must be a bug
somewhere down the line. If there's some SWIG experts out there, I'd
appreciate any advice, but this is already a good enough start for me.
Cheers,
MB
--
Dipl.-Ing. Martin Braun Phone: +49-(0)721-608 3790
Institut fuer Nachrichtentechnik Fax: +49-(0)721-608 6071
Universitaet Karlsruhe (TH) http://www.int.uni-karlsruhe.de/
pgpgdZi1Gl8ID.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] RFID Capture
Hello All, I am trying to capture the communications between a RFID reader and an EPC Gen 2 tag (920 MHz). I tapped directly into the antenna of a Thinkmagic M5e RFID reader. I turn it on and it starts reading the tags. When I look at the raw signal from the usrp or an Agilent signal analyzer, I can clearly make out the reader-to-tag data bursts. But, I don't see the tag-to-reader bursts. I know they should be considerably smaller in amplitude, but all I see is noise. Has anyone had any luck capturing this type of data? Any suggestions would be greatly appreciated. Thanks in advance, Kevin Yes, indeed, the backscatter signals from the RFID tags typically have quite small amplitudes, and it may be difficult to trigger on them. Try bringing the tags quite close to the reader and use various antenna alignments. Tag signals will put small notches in the carrier envelope. You might have a better chance of seeing them if you use a 3rd antenna for your receiver, positioning the tag between the reader and your receiver antenna. Paul Mathews ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: RFID Capture
Are you using the ThingMagic in monostatic mode (one antenna that does RX and TX)? If so, you probably won't be able to see the tag reply. Further down the receive path the ThingMagic has circuitry that removes the strong TX signal leaving only the tag reply, but I assume you are tapped in before that. You MIGHT have better luck if you use the reader in bistatic mode and tap in at the receive antenna, particularly if you don't use the full 1W output power. Another option would be to just put the USRP antenna near the tag, and receive both reader and tag commands there. I have had pretty good luck with that, and can decode tag responses from a few feet away. michael > Hello All, > I am trying to capture the communications between a RFID reader and > an EPC Gen 2 tag (920 MHz). I tapped directly into the antenna of a > Thinkmagic M5e RFID reader. I turn it on and it starts reading the > tags. When I look at the raw signal from the usrp or an Agilent > signal analyzer, I can clearly make out the reader-to-tag data bursts. > But, I don't see the tag-to-reader bursts. I know they should be > considerably smaller in amplitude, but all I see is noise. > Has anyone had any luck capturing this type of data? Any suggestions > would be greatly appreciated. > Thanks in advance, > Kevin -- - ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Using an external clock with 10MHz
Hello! I'm running GNURadio/OpenBTS with Ubuntu Linux and an external clock with 64MHz. Now I want to use an external oscillator with 10MHz. Is it possible to run the USRP and the daughterboards (RFX1800) with this frequency? I read the article about Clocking http://www.gnuradio.org/trac/wiki/UsrpFAQ/Clocking The OpenBTS application has similar lines: self.refclk_divisor = 16 return 64e6/self.refclk_divisor I changed it to self.refclk_divisor = 2.5 return 10e6/self.refclk_divisor Is this modification correct? Are there any other things I have to mind? Regards -Fabian- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 FPGA Programming
You are using the wrong project. Use u2_rev3. Matt Kyle Pearson wrote: I'm trying to make some modifications to the FPGA on the USRP 2 but I'm having some problems with the Xilinx project file. When I open the project, I get an error that the following files are missing: /home/matt/usrp2/fpga/top/u2_basic.v /home/matt/usrp2/fpga/control_lib/strobe_gen.v /home/matt/usrp2/fpga/control_lib/extram_interface.v /home/matt/usrp2/fpga/coregen/fifo_generator_v4_1.v Once I get into the project, it appears that other files are missing (they have a question mark next to them and I can't get to the code). These files are: fifo_xlnx_2Kx36_2clk rx_dcoffset cordic cic_strober hb_strober hb_interp small_hb_int hb_dec oneshot_2clk fifo_2clock_casc Lastly, the fpga selected is the xc3s1500, not the xc3s2000 I'm running Xilinx ISE 9.2i on Windows XP (had trouble installing it on Ubuntu 8.04 so I just put it on my Windows partition instead) and I just updated to rev. 10479 off svn. Has anyone else had these issues or is everyone else fine on Linux and/or ISE 10.1? Thanks, Kyle Pearson ___ 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
[Discuss-gnuradio] USRP2 FPGA Programming
I'm trying to make some modifications to the FPGA on the USRP 2 but I'm having some problems with the Xilinx project file. When I open the project, I get an error that the following files are missing: /home/matt/usrp2/fpga/top/u2_basic.v /home/matt/usrp2/fpga/control_lib/strobe_gen.v /home/matt/usrp2/fpga/control_lib/extram_interface.v /home/matt/usrp2/fpga/coregen/fifo_generator_v4_1.v Once I get into the project, it appears that other files are missing (they have a question mark next to them and I can't get to the code). These files are: fifo_xlnx_2Kx36_2clk rx_dcoffset cordic cic_strober hb_strober hb_interp small_hb_int hb_dec oneshot_2clk fifo_2clock_casc Lastly, the fpga selected is the xc3s1500, not the xc3s2000 I'm running Xilinx ISE 9.2i on Windows XP (had trouble installing it on Ubuntu 8.04 so I just put it on my Windows partition instead) and I just updated to rev. 10479 off svn. Has anyone else had these issues or is everyone else fine on Linux and/or ISE 10.1? Thanks, Kyle Pearson ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Exporting C++ hier_block2s via SWIG
Hi, I was wondering if it's possible to write a gr_hier_block2 in C++ and then export it to SWIG just like the the gr_blocks are. I tried using GR_SWIG_BLOCK_MAGIC, but not surprisingly the SWIG code fails to compile saying /usr/include/boost/shared_ptr.hpp:211: Error: error: cannot convert 'specest_welch* const' to 'gr_block*' in initialization. Is there any easy way to do this? Basically, what I want is a GR_SWIG_HIERBLOCK_MAGIC() function, I suppose. Has anyone done something like this before? Cheers, MB -- Dipl.-Ing. Martin Braun Phone: +49-(0)721-608 3790 Institut fuer Nachrichtentechnik Fax: +49-(0)721-608 6071 Universitaet Karlsruhe (TH) http://www.int.uni-karlsruhe.de/ pgp5mJtJ3xRYH.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] RFID Capture
(Sorry if this posts twice) Hello All, I am trying to capture the communications between a RFID reader and an EPC Gen 2 tag (920 MHz). I tapped directly into the antenna of a Thinkmagic M5e RFID reader. I turn it on and it starts reading the tags. When I look at the raw signal from the usrp or an Agilent signal analyzer, I can clearly make out the reader-to-tag data bursts. But, I don't see the tag-to-reader bursts. I know they should be considerably smaller in amplitude, but all I see is noise. Has anyone had any luck capturing this type of data? Any suggestions would be greatly appreciated. Thanks in advance, Kevin ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Guide for Reporting Errors and Asking for Help
Hello! I wrote some lines for people asking for help in the wiki [1]. For the old stagers, please look through it, it can certainly need some polishing. Especially the common-mistakes section could need some more examples. Patrick [1] http://gnuradio.org/trac/wiki/ReportingErrors -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio version & uninstall
On Mon, Feb 23, 2009 at 6:05 AM, Dimitris Symeonidis wrote: > 1) Is there a command or a file that tells me the gnuradio version > installed and used? > What I mean is: let's say I have separate folders with 3.1.1, 3.1.2, > 3.1.3 and the latest trunk. > I occasionally "sudo make uninstall" one and "sudo make install" the > other. Is there a way to know which one is currently installed? Not using the installed path, that I can think of, anyway. I use an alternative way of having multiple versions installed simultaneously using a symbolic link to select the "active" one. Each version is ./configure'd with --prefix= and installed into a custom path, then a symbolic link is made to a standard path name: /home/jcorgan/.sys-trunk /home/jcorgan/.sys-release-3.1.3 /home/jcorgan/.sys-release-3.2rc0 Then whichever I one I want to use I symbolic link: $ ln -s .sys-trunk .sys Finally, I set environment variables in .bashrc to find everything: PREFIX=/home/jcorgan/.sys export PATH=$PATH:$PREFIX/bin:/opt/microblaze/bin export LD_LOAD_LIBRARY=$PREFIX/lib export LD_LIBRARY_PATH=$PREFIX/lib export PYTHONPATH=$PREFIX/lib/python2.5/site-packages export PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig At this point switching between GNU Radio installations is as simple as deleting and making a new symbolic link, then re-running ldconfig. > 2) Connected to the previous question: the "normal" way to uninstall a > version of gnuradio is to go into the source folder and type "sudo > make uninstall". However, this requires a) that you know which version > is installed, and b) that you still have this source folder. My > question is: is there a more generic way to remove an installation of > gnuradio? Which folders should I remove? So far I have collected: > > but I'm not sure this list is complete... Below is my 'nuke-gnuradio' script, edit as needed, use at your own risk: PREFIX=/usr/local rm -rf $PREFIX/bin/gr_plot_* rm -rf $PREFIX/bin/usrp* rm -rf $PREFIX/bin/grc rm -rf $PREFIX/bin/find_usrps rm -rf $PREFIX/bin/lsusrp rm -rf $PREFIX/bin/test_all rm -rf $PREFIX/etc/gnuradio rm -rf $PREFIX/include/gnuradio rm -rf $PREFIX/include/gruel rm -rf $PREFIX/include/fpga_* rm -rf $PREFIX/include/mb_* rm -rf $PREFIX/include/mblock rm -rf $PREFIX/include/pmt* rm -rf $PREFIX/include/usrp* rm -rf $PREFIX/lib/libgnuradio* rm -rf $PREFIX/lib/libgr* rm -rf $PREFIX/lib/libmblock* rm -rf $PREFIX/lib/libpmt* rm -rf $PREFIX/lib/libusrp* rm -rf $PREFIX/lib/python2.5/site-packages/gnuradio rm -rf $PREFIX/lib/python2.5/site-packages/usrpm rm -rf $PREFIX/lib/python2.5/site-packages/grc rm -rf $PREFIX/lib/python2.5/site-packages/grc_gnuradio rm -rf $PREFIX/lib/pkgconfig/gnuradio*.pc rm -rf $PREFIX/lib/pkgconfig/gr-wxgui*.pc rm -rf $PREFIX/lib/pkgconfig/gruel.pc rm -rf $PREFIX/lib/pkgconfig/mblock.pc rm -rf $PREFIX/lib/pkgconfig/pmt.pc rm -rf $PREFIX/lib/pkgconfig/usrp*.pc rm -rf $PREFIX/share/doc/gnuradio* rm -rf $PREFIX/share/doc/usrp* rm -rf $PREFIX/share/gnuradio rm -rf $PREFIX/share/grc rm -rf $PREFIX/share/usrp ldconfig 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, 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. 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.)
> 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.
Johnathan may have additional comments...
Eric
___
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 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] New implementation for fusb_linux without allocs/frees
On Mon, Feb 23, 2009 at 07:38:14AM +0100, Stefan Bruens wrote: > Hi, > > attached is a new version for fusb_linux.cc. > > The current implementation uses three std::list lists for free, pending and > completed urbs, so submitting a single urb causes three allocs and three > frees > (pushing and popping of the list). > > The new implementation uses a circular list for the urbs, where each urb is > marked as free, pending or completed. As the total number of allocated urbs > is > constant, no allocs or frees are needed. > > Benchmark: > usrp/host/apps/test_usrp_standard_tx -B 512 -N 64 -M 128 > > old code needs ~990e6 instructions, new code 690e6 instructions. The call to > usrp_basic_tx::write goes down from 380e6 to 80e6 (so almost down to a fifth > ...), the remaining instructions is the pattern fill for the sample buffer. > > Regards, > Stefan Thanks! Stefan, please tell me again how you measured the instruction count? Also, if you haven't already, please send in the form that starts the copyright assignment. Contact me off-list if you've got any more questions about that. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New implementation for fusb_linux without allocs/frees
On Sun, Feb 22, 2009 at 10:38 PM, Stefan Bruens wrote: > attached is a new version for fusb_linux.cc. Stefan--THANKS for all the wonderful work you've been submitting; we really appreciate the kinds of optimization work you are doing. We will likely get all of it into our distribution. However, it makes it easier for us to review and apply your work if you follow the guidelines in the below Wiki page: http://gnuradio.org/trac/wiki/PatchSubmissionGuidelines Thanks, Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 &DBSRX testing
On Sun, Feb 22, 2009 at 5:11 PM, Bruce Stansby wrote: > The memory card had the original version software on it and after it > didn't work he upgrade it with UR2_rev3 & txrx.bin. The code for the DBSRX board in the USRP2 has been written and is in the trunk firmware as of r10392. However, we have not made a pre-compiled firmware image available yet that has this in it. You can get the compile included in the GNU Radio compilation by having the mb-gcc compiler installed. See the section: "How do I compile the firmware for the aeMB RISC processor?" in: http://gnuradio.org/trac/wiki/USRP2UserFAQ Alternatively, I'll be posting an updated firmware image in the next few days. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: from a function generator into the LF-RX (maximum load)
Karthik gmail.com> writes: > If you look at the LFRX the input consists of AD813x fully differential > amplifier with unity gain and a input impedance of 50 ohm. I am not sure if there are diodes which limit the signal swing, maybe looking at the schematics can help you with this. Where are the Schematics ? > From what I > understand the LFRX and Basic-RX are very similar, so the same rules > for safety apply. I read that the Basic-RX has a Transformator which gives the Safety. But the LF-RX has no Transformator! Regards Markus ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Problem to listen to FM
jingx kwan wrote am 2009-02-22 20:19: Hello, It isn't create any sound from the usrp_wfm_rcv.py command when I set to listen to the Frequency 91.5. It is running under Ubuntus 8.04 and Dell Latitude D610 notebook. I doubt that the notebook sound card doesn't support the below command line. I don't know why I can't listen to the FM. > Could you please point me to the solution? Yes, if you provide a little more information: Have you read all the READMEs, FAQs and things labeled with "doc" or "documentation"? Have searched the mailing list archives? I recommend GMANE.org. Have searched the Internet? If you'r unsure what to do first and what to write in a mail asking for help, have a look at http://www.catb.org/~esr/faqs/smart-questions.html You've told us about your computer model and your OS version, but not about your GNU Radio version. Did you install it through your OS' packet managment system or build from source viw SVN? Which version? Have you tried other commands? Did they work? Some output on the command line? Have you been able to get some sound output with the programs from gnuradio-examples/python/audio directory? If dial_tone.py is not working, you should sort this out at first. I run the following command: ./usrp_wfm_rcv.py -f 91.5M -O plughw:0,0 "It isn't create any sound" is not very specific. Please send us the copy of the output of the command. If there are errors, you have not showed us any trace of it. Patrick -- Engineers motto: cheap, good, fast: choose any two Patrick Strasser Student of Telematik, Techn. University Graz, Austria ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio version & uninstall
Two questions, related to one-another: 1) Is there a command or a file that tells me the gnuradio version installed and used? What I mean is: let's say I have separate folders with 3.1.1, 3.1.2, 3.1.3 and the latest trunk. I occasionally "sudo make uninstall" one and "sudo make install" the other. Is there a way to know which one is currently installed? 2) Connected to the previous question: the "normal" way to uninstall a version of gnuradio is to go into the source folder and type "sudo make uninstall". However, this requires a) that you know which version is installed, and b) that you still have this source folder. My question is: is there a more generic way to remove an installation of gnuradio? Which folders should I remove? So far I have collected: * /usr/local/etc/gnuradio * /usr/local/include/gnuradio * /usr/local/share/gnuradio * /usr/local/share/doc/gnuradio-3.2svn * /usr/local/lib/python2.5/site-packages/gnuradio * /usr/local/lib/python2.5/site-packages/grc_gnuradio * ~/.gnuradio but I'm not sure this list is complete... Thanx in advance... Dimitris Symeonidis "If you think you're too small to make a difference, try sleeping with a mosquito!" - Amnesty International ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Updated TX path in UCLA_ZigBee_PHY
Hi,
I've added a few changes to the IEEE 802.15.4 *TX path* in UCLA_ZigBee_PHY
and now the code works with the current gr trunk (3.1.3). The code is tested
using cc2420_txtest.py on one computer and cc2420_txtest.py on another
computer. (Since the *RX path* already has been updated by Leslie Choong, as
seen earlier in this thread, everything now works with the current gr
release!)
The changes concerns ieee802_15_4.py, ieee802_15_4_pkt.py and
cc2420_txtest.py, and are attached below. I appreciate comments!
Regards,
Sanna
Changes:
___
___
--- old_ieee/ieee802_15_4_pkt.py2009-01-27 18:22:42.0 +0100
+++ new_ieee/*ieee802_15_4_pkt.py * 2009-02-23 10:51:53.0 +0100
Send packets by calling send_pkt
"""
-def __init__(self, msgq_limit=2, pad_for_usrp=True, *args, **kwargs):
+def __init__(self, pad_for_usrp=True, *args, **kwargs):
"""
Hierarchical block for the 802_15_4 O-QPSK modulation.
@@ -157,15 +157,20 @@
See 802_15_4_mod for remaining parameters
"""
+try:
+self.msgq_limit = kwargs.pop('msgq_limit')
+except KeyError:
+pass
+
gr.hier_block2.__init__(self, "ieee802_15_4_mod_pkts",
gr.io_signature(0, 0, 0), # Input
-gr.io_signature(0, 0, 0)) # Output
+gr.io_signature(1, 1, gr.sizeof_gr_complex)) # Output
self.pad_for_usrp = pad_for_usrp
# accepts messages from the outside world
-self.pkt_input = gr.message_source(gr.sizeof_char, msgq_limit)
+self.pkt_input = gr.message_source(gr.sizeof_char, self.msgq_limit)
self.ieee802_15_4_mod = ieee802_15_4.ieee802_15_4_mod(self, *args,
**kwargs)
-self.connect(self.pkt_input, self.ieee802_15_4_mod)
+self.connect(self.pkt_input, self.ieee802_15_4_mod, self)
def send_pkt(self, seqNr, addressInfo, payload='', eof=False):
"""
___
--- old_ieee/ieee802_15_4.py2009-01-27 18:22:42.0 +0100
+++ new_ieee/*ieee802_15_4.py*2009-02-23 10:51:21.0 +0100
from gnuradio import gr, ucla
@@ -33,7 +33,7 @@
class ieee802_15_4_mod(gr.hier_block2):
-def __init__(self, spb = 2):
+def __init__(self, *args, **kwargs):
"""
Hierarchical block for cc1k FSK modulation.
@@ -43,13 +43,17 @@
@param spb: samples per baud >= 2
@type spb: integer
"""
+try:
+self.spb = kwargs.pop('spb')
+except KeyError:
+pass
+
gr.hier_block2.__init__(self, "ieee802_15_4_mod",
-gr.io_signature(0, 0, 0), # Input
-gr.io_signature(0, 0, 0)) # Output
+gr.io_signature(1, 1, 1), # Input
+gr.io_signature(1, 1, gr.sizeof_gr_complex)) # Output
-if not isinstance(spb, int) or spb < 2:
-raise TypeError, "sbp must be an integer >= 2"
-self.spb = spb
+if not isinstance(self.spb, int) or self.spb < 2:
+raise TypeError, "spb must be an integer >= 2"
self.symbolsToChips = ucla.symbols_to_chips_bi()
self.chipsToSymbols = gr.packed_to_unpacked_ii(2, gr.GR_MSB_FIRST)
@@ -60,8 +64,8 @@
# Connect
-self.connect(self.symbolsToChips, self.chipsToSymbols,
- self.symbolsToConstellation, self.pskmod, self.delay)
+self.connect(self, self.symbolsToChips, self.chipsToSymbols,
+ self.symbolsToConstellation, self.pskmod, self.delay,
self)
class ieee802_15_4_demod(gr.hier_block2):
def __init__(self, *args, **kwargs):
___
--- old_ieee/cc2420_txtest.py2009-01-27 18:22:42.0 +0100
+++ new_ieee/*cc2420_txtest.py * 2009-02-23 10:56:52.0 +0100
from gnuradio import gr, eng_notation
@@ -27,9 +27,9 @@
return (1, 0)
return (0, 0)
-class transmit_path(gr.flow_graph):
-def __init__(self, options):
-gr.flow_graph.__init__(self)
+class transmit_path(gr.top_block):
+def __init__(self, options):
+gr.top_block.__init__(self)
self.normal_gain = 8000
self.u = usrp.sink_c()
@@ -93,17 +93,17 @@
(options, args) = parser.parse_args ()
-fg = transmit_path(options)
-fg.start()
+tb = transmit_path(options)
+tb.start()
for i in range(10):
print "send message %d:"%(i+1,)
-fg.send_pkt(struct.pack('9B', 0x1, 0x80, 0x80, 0xff, 0xff, 0x10,
0x0, 0x20, 0x0))
+tb.send_pkt(struct.pack('9B', 0x1, 0x80, 0x80, 0xff, 0xff, 0x10,
0x0, 0x20, 0x0))
#this is an other example packet we could send.
-#fg.send_pkt(struct.pack('BBB', 0x1, 0x8d,
0x8d, 0xff, 0xff, 0xbd, 0x0, 0x22, 0x12, 0xbd, 0x0, 0x1, 0x0, 0xff, 0xff,
0x8e, 0xff, 0xff, 0x0, 0x3, 0x3, 0xbd, 0x0, 0x1, 0x0, 0x0, 0x0))
+
[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
