Hi Dominik, It would be great if you could port the ofdm transceiver that you have implemented to packet_utils. I am actually using two USRPs rev4 with RFX2400 and trying to make them communicate with each other on air using ofdm. Presently I am thinking of how to synchronize the transmitter and the receiver. The S&C based timing offset estimation that you have implemented will be very helpful to me!
Thanks, Archana On 10/18/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > Send Discuss-gnuradio mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > or, via email, send a message with subject or body 'help' to > [EMAIL PROTECTED] > > You can reach the person managing the list at > [EMAIL PROTECTED] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Discuss-gnuradio digest..." > > > Today's Topics: > > 1. Removing '.py' from system path installed Python scripts > (Johnathan Corgan) > 2. Re: looking at a wider spectrum (meggahertz) > 3. Contribution: ofdm system (Dominik Auras) > 4. Re: Removing '.py' from system path installed Python scripts > (Greg Troxel) > 5. (no subject) > 6. usrp initialization (Hans Glitsch) > 7. Re: Removing '.py' from system path installed Python scripts > (Michael Dickens) > 8. Re: Removing '.py' from system path installed Python scripts > (Greg Troxel) > 9. Re: Removing '.py' from system path installed Python scripts > (Tim Meehan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 18 Oct 2007 09:15:59 -0700 > From: Johnathan Corgan <[EMAIL PROTECTED]> > Subject: [Discuss-gnuradio] Removing '.py' from system path installed > Python scripts > To: gnuradio mailing list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1 > > A while back we did some clean up of the USRP examples, removing some > bit-rotted cruft, and moving the commonly used programs into gr-utils. > > These included things like usrp_fft.py, usrp_rx_cfile.py, and those > scripts that over time have become more utilities than examples. > > In the gr-utils component, we are now installing these into the > $prefix/bin directory, so they'll end up on the user's PATH and be > callable from anywhere without prefixing them with the examples path. > > However, a common convention on Linux, at least on Debian, Ubuntu, and > derived systems (probably Redhat too), is to strip the language specific > extension off scripts in the path. > > Would anyone have any heartache if we did this for the gr-utils scripts > as well as the relatively few other scripts we install on the path? > > usrp_fft.py -> usrp_fft > usrp_rx_cfile.py -> usrp_rx_cfile > > etc. > > It's not a critical item, but if we do this, it will need to be before > the 3.1 stable branch is officially released. > > -- > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com > > > > > ------------------------------ > > Message: 2 > Date: Thu, 18 Oct 2007 10:23:21 -0700 (PDT) > From: meggahertz <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] looking at a wider spectrum > To: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > > Thank you, I tried that last night and was able to make it 8MHz, so looks > like it works. So there is no way to take a look at the fft of the entire > spectrum supported by the RX board at once? > > > Eng. Firas wrote: > > > > Hi, > > > > Use usrp_fft.py with decimation rate of 8. In this case, you can see > 8MHz > > of spectrum. Also, you can use 8 bit data transfer with decimation rate > of > > 4 to look at 16 MHz wide spectrum. > > > > Firas > > > > > > meggahertz wrote: > >> > >> I am new to the GNU Radio and am running the usrp_wfm_rcv.py but it > only > >> shows the spectrum of width ~ 0.4Mhz. How can I look at a wider > spectrum > >> instead of just 0.4MHz around the carrier frequency? > >> > >> > > > > > > -- > View this message in context: > http://www.nabble.com/looking-at-a-wider-spectrum-tf4643642.html#a13279350 > Sent from the GnuRadio mailing list archive at Nabble.com. > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 18 Oct 2007 19:36:12 +0200 > From: Dominik Auras <[EMAIL PROTECTED]> > Subject: [Discuss-gnuradio] Contribution: ofdm system > To: 'Eric Blossom' <[EMAIL PROTECTED]> > Cc: [email protected] > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Hello, > > In the last months, we have developed an ofdm system using your gnuradio > architecture as part of a research on dynamic resource allocation. Now we > like to contribute parts of our code to the gnuradio project. We think > that > it will be useful to you since it partially employs more advanced > techniques > than in your example. If you like it, I suggest to add it as an > alternative > ofdm system. > > We are using this system on USRPs at revision 4 with daughterboards > RFX2400. > It is tested, stable and has a good performance in BER and SNR. All > hierarchical blocks are using the new style blocks. > > Here are some facts about the receiver and transmitter: > > - preamble based timing synchronization > The modified Schmidl & Cox algorithm is used to position the sampling > window > at the first preamble. Only coarse timing synchronization is done. > > - preamble based frequency offset synchronization > Before FFT, the frequency offset, divided into a fractional part and an > integer part, will be estimated based on the S&C preamble (also used for > timing sync) and a second preamble. Therefore both fine and coarse > frequency > offset estimation is performed. > > - preamble based channel estimation > The second preamble, used for frequency offset estimation, will be > exploited > to give an estimate of the current channel state. The fine timing > synchronization is absorbed into the channel transfer function (as phase > rotation), i.e. compensated for at this place. > > - pilot tone based sampling frequency offset estimation > We insert 8 pilot tones (or subcarriers) to ofdm data blocks. The sampling > frequency offset (as phase rotation) and the residual carrier frequency > offset is estimated and compensated for. Without SFO compensation, we > observed a severe drop of SNIR using the USRPs, especially between two > different charges we bought. The current algorithm acquires and tracks the > SFO and RCFO within an ofdm frame. > > - flexible channel estimator > The estimator block can easily use several ofdm blocks to estimate the > channel transfer function. It will output both the inverse ctf to be fed > to > the equalizer and the ctf. It uses a simple zero-forcing criteria. The > known > blocks' positions within the ofdm frame can be freely chosen. For example, > we used a midamble in our experiments to mitigate some special problems. > > - flexible mapper/demapper > We created a new ofdm mapper/demapper that allows to assign different > signal > constellations on different subcarriers. This can be either static or > dynamically changed. > > Please let me know if you want to have more details. > > If you accept our contribution, I will port the system to use your packet > utils and to have it behave like your systems. Please note that the system > has a modular design and uses simple gnuradio blocks if possible and > useful. > > Additionally, I personally want to thank you for your great work at the > gnuradio project. It is definitely one of the best SDR environments. > > Greetings, > Dominik Auras > > Chair of Theoretical Information Technology > RWTH Aachen University > http://www.ti.rwth-aachen.de > > > > > ------------------------------ > > Message: 4 > Date: Thu, 18 Oct 2007 16:20:13 -0400 > From: Greg Troxel <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Removing '.py' from system path > installed Python scripts > To: Johnathan Corgan <[EMAIL PROTECTED]> > Cc: gnuradio mailing list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > However, a common convention on Linux, at least on Debian, Ubuntu, and > derived systems (probably Redhat too), is to strip the language specific > extension off scripts in the path. > > Would anyone have any heartache if we did this for the gr-utils scripts > as well as the relatively few other scripts we install on the path? > > usrp_fft.py -> usrp_fft > usrp_rx_cfile.py -> usrp_rx_cfile > > > ------------------------------ > > Message: 5 > Message-ID: <[EMAIL PROTECTED]> > > It would be good if all the scripts started with a small set of prefixes > like usrp_foo and gr_foo, to avoid collisions with at least most of the > other 5000 packages. Sounds like you are headed this way. > > > > > > ------------------------------ > > Message: 6 > Date: Thu, 18 Oct 2007 13:34:50 -0700 > From: "Hans Glitsch" <[EMAIL PROTECTED]> > Subject: [Discuss-gnuradio] usrp initialization > To: "gnuradio mailing list" <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Hi, > > Please help me figure out the strange problem I'm having. > > In my system, the software is receiving four interleaved streams of > complex > data from the usrp. I am trying to receive two channels on each input of > the usrp, so I setup the usrp to ddc the center of the two channels down > to > zero frequency and then (in gnuradio) I seperate the channels by doing > another ddc to bring each channel to zero hz and then a low pass filter. > The second channel requires a conjugation before the ddc to flip it to the > positive side of the freq spectrum. > > I'm getting a strange behavior only on RX1 (input A of the Basic RX in > position1 of the usrp). If I input a signal only on channel 1, to all > four > usrp inputs it bleeds over to channel 2 at about 60% amplitude only on > RX1. > The same thing happens if I input a signal only on channel 2 -- it bleeds > over about 60% to channel 1. > > This behavior does not happen on the other three receivers at all and > continues to present itself only on RX1 even if I swap the cables > providing > signals to the four usrp inputs. I have even tried swapping the usrp, > both > basic RX boards, and the cables inside the usrp enclosure. The problem > always stays with RX1. I know the problem is somewhere in the usrp, the > way > I initialize the usrp, or in my software. > > I don't think the problem is in my software because I simply use four > instances of the same code to process all four inputs. But I'm not sure > yet. > > I'm using the following python to initialize the usrp, then I pass the > usrp > to c++ code via sm.Run_SM1680(adc._u). > > Please tell me if you see anything wrong with this. > > Thanks, > Hans > > #!/usr/bin/env python > from gnuradio import usrp, gru > from gnuradio import sm > def main(): > nchan = 4 > adc = usrp.source_c(0, 250, fpga_filename="std_4rx_0tx.rbf") > if not adc.set_nchannels(nchan): > sys.stderr.write('set_nchannels(%d) failed to set number of > channels\n' > % (nchan,)) > raise SystemExit > adc._write_oe( 0, 0xffff, 0xffff ) > adc.write_io( 0, 0xfff7, 0xffff ) > gain = 0 > subdev = adc.db[0] + adc.db[1] > subdev[0].set_gain(gain) > subdev[1].set_gain(gain) > adc.set_mux(gru.hexint(0xf3f2f1f0)) > target_freq = sm.Get_Center() > for i in range(len(subdev)): > r = usrp.tune(adc, i, subdev[i], target_freq) > if not r: > print "set_freq: failed to set subdev[%d] freq to %f" % (i, > target_freq) > raise SystemExit > sm.Run_SM1680(adc._u) > > if __name__ == "__main__": > main() > > > > > > > ------------------------------ > > Message: 7 > Date: Thu, 18 Oct 2007 16:42:17 -0400 > From: Michael Dickens <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Removing '.py' from system path > installed Python scripts > To: Johnathan Corgan <[EMAIL PROTECTED]> > Cc: gnuradio mailing list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > > Removing the '.py' works fine on OSX 10.4.10, so long as the file is > executable (a+x) and has "#!/usr/bin/env python" as the first line to > get the runtime environment correct. - MLD > > On Oct 18, 2007, at 12:15 PM, Johnathan Corgan wrote: > > usrp_fft.py -> usrp_fft > > usrp_rx_cfile.py -> usrp_rx_cfile > > > > > ------------------------------ > > Message: 8 > Date: Thu, 18 Oct 2007 17:14:05 -0400 > From: Greg Troxel <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Removing '.py' from system path > installed Python scripts > To: Michael Dickens <[EMAIL PROTECTED]> > Cc: gnuradio mailing list <[email protected]> > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=us-ascii > > Removing the '.py' works fine on OSX 10.4.10, so long as the file is > executable (a+x) and has "#!/usr/bin/env python" as the first line to > get the runtime environment correct. - MLD > > Agreed. > > But that will only really work if the version of python found as > 'python' is the same one as the version gnuradio found when it was > compiled, and the packaging system installs an interpreter as python. > In a world with multiple python versions and site-libs this leads to > incorrect behavior. > > See http://www.gnuradio.org/trac/ticket/151 > > This is an orthogonal issue to the renaming, so I don't mean to object, > and I haven't written an install script to change > > #!/usr/bin/env python > > to > > [EMAIL PROTECTED]@ > > when doing the install, so it's fair to say ENOPATCH to my mail. > > > > > > ------------------------------ > > Message: 9 > Date: Thu, 18 Oct 2007 14:18:39 -0700 > From: "Tim Meehan" <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] Removing '.py' from system path > installed Python scripts > To: "Johnathan Corgan" <[EMAIL PROTECTED]> > Cc: gnuradio mailing list <[email protected]> > Message-ID: > <[EMAIL PROTECTED]> > Content-Type: text/plain; charset="iso-8859-1" > > ** > Can this be handled with symbolic links rather then renaming the scripts? > > On 10/18/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote: > > > > A while back we did some clean up of the USRP examples, removing some > > bit-rotted cruft, and moving the commonly used programs into gr-utils. > > > > These included things like usrp_fft.py, usrp_rx_cfile.py, and those > > scripts that over time have become more utilities than examples. > > > > In the gr-utils component, we are now installing these into the > > $prefix/bin directory, so they'll end up on the user's PATH and be > > callable from anywhere without prefixing them with the examples path. > > > > However, a common convention on Linux, at least on Debian, Ubuntu, and > > derived systems (probably Redhat too), is to strip the language specific > > extension off scripts in the path. > > > > Would anyone have any heartache if we did this for the gr-utils scripts > > as well as the relatively few other scripts we install on the path? > > > > usrp_fft.py -> usrp_fft > > usrp_rx_cfile.py -> usrp_rx_cfile > > > > etc. > > > > It's not a critical item, but if we do this, it will need to be before > > the 3.1 stable branch is officially released. > > > > -- > > Johnathan Corgan > > Corgan Enterprises LLC > > http://corganenterprises.com > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > [email protected] > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.gnu.org/pipermail/discuss-gnuradio/attachments/20071018/93df8ae9/attachment.html > > ------------------------------ > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > End of Discuss-gnuradio Digest, Vol 59, Issue 49 > ************************************************ > -- Archana Ragothaman Master's in Telecommunications Graduate Research Assistant MIND Lab,UMIACS University of Maryland, College Park Email: [EMAIL PROTECTED] Phone: 240-422-7887
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
