|
| From: | Archana Ragothaman |
| Subject: | [Discuss-gnuradio] Re: Discuss-gnuradio Digest, Vol 59, Issue 49 |
| Date: | Fri, 19 Oct 2007 11:04:43 -0300 |
Send Discuss-gnuradio mailing list submissions to
address@hidden
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
address@hidden
You can reach the person managing the list at
address@hidden
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 < address@hidden>
Subject: [Discuss-gnuradio] Removing '.py' from system path installed
Python scripts
To: gnuradio mailing list < address@hidden>
Message-ID: <address@hidden>
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 <address@hidden>
Subject: Re: [Discuss-gnuradio] looking at a wider spectrum
To: address@hidden
Message-ID: <address@hidden>
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 <address@hidden>
Subject: [Discuss-gnuradio] Contribution: ofdm system
To: 'Eric Blossom' <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden >
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 <address@hidden>
Subject: Re: [Discuss-gnuradio] Removing '.py' from system path
installed Python scripts
To: Johnathan Corgan <address@hidden>
Cc: gnuradio mailing list <address@hidden>
Message-ID: <address@hidden>
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: < address@hidden>
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" < address@hidden>
Subject: [Discuss-gnuradio] usrp initialization
To: "gnuradio mailing list" <address@hidden>
Message-ID: <address@hidden >
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 < address@hidden>
Subject: Re: [Discuss-gnuradio] Removing '.py' from system path
installed Python scripts
To: Johnathan Corgan < address@hidden>
Cc: gnuradio mailing list <address@hidden>
Message-ID: < address@hidden>
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 <address@hidden>
Subject: Re: [Discuss-gnuradio] Removing '.py' from system path
installed Python scripts
To: Michael Dickens <address@hidden>
Cc: gnuradio mailing list <address@hidden>
Message-ID: < address@hidden>
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
address@hidden@
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" <address@hidden>
Subject: Re: [Discuss-gnuradio] Removing '.py' from system path
installed Python scripts
To: "Johnathan Corgan" <address@hidden>
Cc: gnuradio mailing list <address@hidden >
Message-ID:
<address@hidden>
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 <address@hidden> 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
> address@hidden
> 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
address@hidden
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
End of Discuss-gnuradio Digest, Vol 59, Issue 49
************************************************
| [Prev in Thread] | Current Thread | [Next in Thread] |