Re: [Discuss-gnuradio] half USRP
Hi Alberto, the USRP2 is only 1xTX and 1xRX. However, the USRP2 costs more than the USRP1 because of its bigger FPGA and faster ADC/DAC (in addition to SDRAM and other hardware). In short, the cost savings are minimal if you would remove one RX and one TX from the USRP1 (you might be able to choose a smaller ADC/DAC, and save some connectors). However, you could save quiet some space (half of the board). Hope that helps. Cheers, Thomas On Mon, May 18, 2009 at 8:33 AM, Alberto Trentadue albtrenta...@tiscali.it wrote: Hello This is for Matt. I'm not aware about USRP requirement's history, hence I'm asking. I apologise immediately if the question is stupid enough... :-) have you ever think about a simplified USRP, or 1/2 USRP, having only 1 side TX and RX? Would it make a cost difference (maybe on a large volume basis)? Would it save some space? Reason for asking is that many (most?) applications are 1+1 channel, and saving space may allow more compact boxes, etc etc. Thanks for your answer alberto. E' arrivato Tiscali Mobile! Acquista la tua SIM Tiscali a soli €5 e scopri la semplicità e la convenienza del nuovo servizio per il tuo cellulare. Passa a Tiscali Mobile http://abbonati.tiscali.it/promo/tiscalimobile/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] BPSK Demodulator (i.e. Receiver) Award/Challenge
Hi Rene, If you execute the benchmark_rx.py file with the following command: python benchmark_rx.py --help Then you will see that under modulations it says dbpsk. The demodulator itself is implemented somewhere else. You can find all the different demodulation blocks in: gnuradio-core/src/python/gnuradio/blks2impl. Here, you will find a file called dbpsk.py. As was mentioned earlier, to make DBPSK into BPSK, just remove the self.diffenc, the differential decoder, from the connect method. Now, even with this modification, you will most likely not be able to communicate with your satellite. You will have to know a lot of details on the communication protocol your satellite uses, packet framing, etc., in addition to the right hardware and daughterboards. Note that eventually, you will have to modify your GNU Radio installation. Thus, it is almost impossible to evade knowing how to code and to understand the working of GNU Radio. Just searching for BPSK in files won't help you further... Cheers, Thomas On Thu, May 7, 2009 at 1:46 AM, René Fléron r...@space.dtu.dk wrote: DBPSK is differential BPSK. However our transmitter sends 'ordinary' BPSK not the differential version, so I cannot use the DBPSK version. -René Josh Blum-2 wrote: The DBPSK blocks are in GRC under DPSK, there is a drop down to choose between DBPSK, DQPSK, D8PSK. Also, see the packet encoder/decoder to accompany the DPSK modulator blocks. A helpful example: http://gnuradio.org/trac/browser/gnuradio/trunk/grc/examples/simple/dpsk_loopback.grc -Josh Jason Uher wrote: I seriously doubt that making a regular BPSK receiver that goes all-the-way, i.e. recovers the transmitted data has ever been done. We haven't found any trace of anything be it commercial, research or DIY. Have you looked at the examples in the 'digital' folder? The benchmark_rx and benchmark_tx do DBPSK, DQPSK, and others 'all the way', if you are set on BPSK you simply comment out the differential encoder/decoder in modulator/demodulator script. Jason ___ 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 -- View this message in context: http://www.nabble.com/BPSK-Demodulator-%28i.e.-Receiver%29-Award-Challenge-tp23404610p23422603.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 -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] os.popen broken pipe error
python pipes are buffered. if your command produces a lot of output, then the pipes can fill up, if you don't read from them. One solution is to move to the subprocess module: http://docs.python.org/library/subprocess.html#module-subprocess Cheers, Thomas On Sun, Apr 12, 2009 at 9:52 PM, satar...@eden.rutgers.edu wrote: On Sun, Apr 12, 2009 at 08:42:59PM -0400, satar...@eden.rutgers.edu wrote: Hi, I am trying to open one python script from another using the following code: command = 'python send.py -d %d -s %d -c %d -n %d -f trash_file.txt' %(dest_addr, sender_addr, cmd, seqno) os.popen(command) I get the broken pipe error for some reason. Can anyone please explain what is happening? Following are the file links if you want to reproduce the error: A broken pipe occurs when when you attempt to write on a pipe without a reader (See man 7 pipe). You're not specifying the second argument to os.popen. It defaults to 'r'. Do you want 'w'? See the python library reference for more info. http://www.eden.rutgers.edu/~aanchan/input.txt http://www.eden.rutgers.edu/~aanchan/send.py http://www.eden.rutgers.edu/~aanchan/transceiver.py http://www.eden.rutgers.edu/~aanchan/trash_file.txt I am calling send.py from transceiver.py. The txt files are used as inputs. thanks and regards, -Sumit Eric I was surprised actually when I got the above mentioned bug because I had have always been giving only one argument, when I wanted the command to be executed on the shell. Anyway, the problem was actually solved when I stored the output of the above command in a text file (rx_ack_log.txt) as follows: command = 'python send.py -d %d -s %d -c %d -n %d -f trash_file.txt rx_ack_log.txt' %(dest_addr, sender_addr, cmd, seqno) os.popen(command) thanks for the help! regards, -Sumit ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UCLA_ZigBee_THY (802.15.4) updated to GR 3.1.3?
Hi Sanna, Yes, the code has been updated, but it didn't just yet make it into CGRAN. For now, you can get the code from github: http://github.com/septikus/gnuradio-802.15.4-demodulation/tree/master Note that the code was ported by Leslie, who is also on this list. Cheers, Thomas On Mon, Feb 16, 2009 at 5:15 AM, Dimitris Symeonidis azim...@gmail.com wrote: Here's a quick guide, provided by Firas to a similar question of mine: http://lists.gnu.org/archive/html/discuss-gnuradio/2008-08/msg00222.html you might also want to talk with Leslie Choong: http://lists.gnu.org/archive/html/discuss-gnuradio/2008-10/msg00463.html Dimitris Symeonidis If you think you're too small to make a difference, try sleeping with a mosquito! - Amnesty International On Mon, Feb 16, 2009 at 13:55, Sanna Leidelof s.leide...@gmail.com wrote: Hi, Has anyone updated Thomas Schmid's UCLA_ZigBee_PHY project to work with top_block and hier_block2 in the current GNU Radio 3.1.3 release? I am in the beginning of my master's thesis and hoped that I could use Schmid's code to get started with my implementation of a IEEE 802.15.4 text message transceiver. I checked out the code from CGRAN: https://www.cgran.org/cgran/projects/ucla_zigbee_phy/trunk ucla_zigbee_phy , but unfortunately this code is based on flow_graph and hier_block from the old trunk... If no such code exists, is there any guideline available to transform a project from using hier_block to hier_block2 and flow_graph to top_block? I am a newbie at GNU Radio, is this difficult? Regards, Sanna ___ 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 -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Macbook Pro and USRP2
There are some issues with some GigE chipsets and the USRP2. See http://gnuradio.org/trac/wiki/USRP2GigEReports for more details. It seems that the Marvell chip is not in that list yet. However, its cousin is. Cheers, Thomas On Mon, Jan 19, 2009 at 1:01 PM, Marco Aurelio marco.casar...@gmail.com wrote: Why do you need to know the chipset? I think gnuradio should work with any chipset Marco Casaroli Inatel On Fri, Jan 16, 2009 at 11:17 PM, Leslie Choong septi...@gmail.com wrote: Thanks for your input Mike. I'm planning on installing a Linux distro (likely Ubuntu) on the MBP. I did do a number of Google searches trying to identify the chipset, but was unable to get the exact chipset. -Leslie On Fri, Jan 16, 2009 at 5:13 PM, Michael Dickens m...@alum.mit.edu wrote: Hi Leslie - I don't know what chipset my MBP uses; I can find out if you really want (I'm sure Googling for it would work eventually). That said: If I understand the current state of the USRP2 software, at this time it doesn't matter because the USRP2 software component of GNU Radio currently requires Linux. Although I'm sure folks are working towards broadening OS support, who knows when that might happen. I'm not actively doing GNU Radio development at this time (in the 'ebb' part of the flow), so maybe someone who's more in turn with USRP2 programming could correct me if I'm wrong. - MLD ___ 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 -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: forced GPL in CGRAN? gr-ucla code in BBN repo not GPL?
Right. I forgot that my code is a BSD license (UCLA policy states that if we can choose, we should choose BSD). I also remember that we had this discussion, or at least a similar one, before. I will check in my archives if I can find it again. Cheers, Thomas On Wed, Oct 15, 2008 at 8:55 AM, George Nychis [EMAIL PROTECTED] wrote: Alright, I was hoping someone could clear this up for me in terms of the GPL, and we all know how vague it can be. Sorry to toss a private statement public, Eric, but you mention: the license they pick must be compatible with the GPLv3, otherwise they can't use the existing code Is this really true? The gr-ucla code might be a good example: I have permission from Thomas to put the gr-ucla code in CGRAN, but something that surprised me is that it is not under the GPL: http://acert.ir.bbn.com/viewvc/gr-ucla/trunk/README?revision=24view=markup It doesn't re-use any GNU Radio code that I can find in the repository, but it will of course link to GNU Radio libraries. Through some google searching, its a large dispute whether linking to a GPL library forces the linker to be under the GPL. It isn't explicit. From http://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible ... If you just want to install two separate programs in the same system, it is not necessary that their licenses be compatible, because this does not combine them into a larger work. ... to me, that states gr-ucla does not need to be under the GPL. Thoughts? - George -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) http://gresci.blogspot.com/ - Science articles on green technology ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: forced GPL in CGRAN? gr-ucla code in BBN repo not GPL?
I remember trying to get the OK from UCLA that I could assign my code to the FSF, but my email to the administration was never answered. I will try again and see if I can change the license to GPL. Though we might have to remove some of the sos code, which isn't really needed (SOS is just an example embedded OS that uses 802.15.4 radios). Thomas On Wed, Oct 15, 2008 at 6:00 PM, Greg Troxel [EMAIL PROTECTED] wrote: [Discussion about gr-ucla's BSD license and GPLv3 compatibility.] http://www.gnu.org/licenses/gpl-3.0.html http://www.softwarefreedom.org/resources/2008/compliance-guide.html I have looked at these. UCLA has placed code under a 3-clause BSD licenes. As far as I understand, that's a GPL compatible non-copyleft free software license under the FSF taxonomy, and there's no problem linking that code with GPLv3 code. See http://www.gnu.org/philosophy/license-list.html#GPLCompatibleLicenses and search for modified BSD licenes. Anything that includes any gr_*.h header directly or indirectly is going to be a work based on the earlier work and must be licensed under the GPL. This seems to be the FSF's interpretation; I'm not the least bit sure that's settled copyright law. One can't use text in the GPL to decide what meets the derived work test under copyright law. Including a header and calling functions does not in my view make the source file a derived work, but IANAL. If one distributes a combined work -- and none of Thomas, UCLA, or BBN have done so, to my knowledge -- then in order to have permission to redistribute the GR parts, the distributor has to be able to grant permission to copy the entire source under GPL. The BSD license grants adequate permission to do that, which is why it's considered GPL-compatible, so there's no issue doing that. But, just because someone distributes the code under the GPL doesn't mean others can't go back to the original BSD-licensed code and copy it under those terms. Stepping way back from law, DARPA funded research and wanted the results to be broadly available, under a BSD license rather than GPL, in order to ease tech transfer (in ways the FSF objects to, by enabling proprietary derivative works). BBN's GNU Radio work is assigned and hence GPL, because we tried to meet each community on its own terms. UCLA has a more permissive license, and I think that's fine too. The important thing is that others in the community have the ability to modify, improve, and redistribute the code, and the BSD license certainly permits that. So I don't think there is actually any problem at all. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) http://gresci.blogspot.com/ - Science articles on green technology ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any GR MacOS X 10.5 Intel Users?
I use SDCC 2.8.0 from macports. Seems to work without any problems. On Sun, Oct 5, 2008 at 4:31 PM, Michael Dickens [EMAIL PROTECTED] wrote: Thomas - Thanks for the feedback; it looks from our testing as if Apple's 10.5.5 tweaked some internal USB parameters to tighten down timing or something. Some USRPs' USB transport is on the sloppy side now compared to 10.5.4 (and previous), while others are not. Really not sure what the issue is, but it seems as though it's very few folks with the issue so I'm not going to bother investigating further. Are you using SDCC 2.8.0 from MacPorts, or some other version? If the latter, could you try the former? This is reversible if it doesn't work ... 0) If you have SDCC 2.4.0 installed by my script, then you need to remove it first; else go to (1): curl -o sdcc-2.4.0-i386_rm.sh http://www.nd.edu/~mdickens/GNURadio/sdcc-2.4.0-i386_rm.sh chmod a+x sdcc-2.4.0-i386_rm.sh sudo ./sdcc-2.4.0-i386_rm.sh 1) now update MacPorts and install its SDCC: sudo port sync sudo port upgrade sdcc 2) then go to your GNU Radio install trunk: cd usrp make clean cd .. make sudo make install 3) then go and try the usrp benchmark (in gnuradio-examples/python/usrp) or some other USRP / USB transfer demo / example / application. If it works, then I think SDCC 2.8.0 on Intel-Mac is working. Thanks! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) http://gresci.blogspot.com/ - Science articles on green technology ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Any GR MacOS X 10.5 Intel Users?
Hi Michael,
Just finished reinstalling GNU Radio on Mac OS X 10.5. Worked like a
charm and was very easy to do. The only difference to the guide that
one can find on the web is that now we need guile in addition to the
other prerequisites. following is my command sequence, and my
.bash_login:
.bash_login
export PATH=/opt/local/bin:$PATH
export PYTHON_VERSION=`python -V 21 | sed -e '[EMAIL PROTECTED]@ @2' | awk '{
print $2 }'`
export PYTHON_ROOT=`which python | sed -e 's@/bin/python@@g'`
PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages
# for GNU Radio default prefix;
# change /usr/local to reflect the correct configure prefix
if [ ${PYTHON_ROOT} != /usr/local ]; then
PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python${PYTHON_VERSION}/site-packages
fi
export PYTHONPATH
#gnuradio stuff
export GR=$HOME/gr
export PKG_CONFIG_PATH=$GR/lib/pkgconfig:/opt/local/lib/pkgconfig
export CPATH=$GR/include:/opt/local/include
export LDFLAGS=-L$GR/lib -L/opt/local/lib
###
Commands to install GNU Radio:
1. install darwin port and XCode
2. sudo port install gawk subversion autoconf automake libtool
pkgconfig swig boost cppunit fftw-3-single python_select py25-numpy
py25-wxpython libusb sdcc guile
3. svn co http://gnuradio.org/svn/gnuradio/trunk gnuradio
4. Replace libtoolize with glibtoolize in bootstrap
5. ./bootstrap
6. ./configure
7. make -j 4
8. sudo make install
Cheers,
Thomas
On Tue, Sep 30, 2008 at 11:27 AM, Michael Dickens [EMAIL PROTECTED] wrote:
On Sep 30, 2008, at 11:50 AM, Thomas Schmid wrote:
I tried to install GNU Radio on 10.5.5, but it didn't work. Shortly
after the install, I had a HD crash, and thus have to start from
scratch at some point. I can write down what I am doing for others, if
that would be helpful?
Can't hurt; I'm always in favor of other OSX users providing input as to how
well GR / USRP is working for them, or that functionality broke on the
latest system update, or whatever. We're testing GR / USRPs in our labs on
both PPC and Intel Macs, running 10.4 and 10.5, and it really seems as
though updating to 10.5.5 causes fusb to work intermittently. Bad Apple ...
One question that I remember I had during the install: Which python
should I use? While installing some of the port packages, port
automatically installed an additional python, and thus I had two
pythons, both 2.5, installed, and I think that this was one of the
conflicts that I had at the end. Since Mac OS X already comes with
2.5, I think port should not reinstall one, though how can I force
port to do so?
Here's -much- more info than you asked for on how Python works on OSX ...
Mac OS X 10.4 comes with Python 2.3. 10.5 comes with 2.5. MacPorts (and
Fink) provide the latest 2.5.X release, which Apple generally doesn't even
with system updates. I know from discussions with MacPorts developers that
they try to stay away from Apple's pre-installed packages as much as
possible, relying on them only when there is no other choice. Since Python
can reasonably easily be compiled / installed on OSX, with or without
Framework, MacPorts makes all Python packages dependent on their own version
of Python (I tried to convince them that it would be desirable to have a
+apple variable to use Apple's provided Python, but none of the MP
developers liked that idea). MacPorts also includes a package called
python_select which allows choosing which version to use (Apple's, Fink's,
MacPort's, self-installed, whatever).
Having multiple versions of Python installed is OK, so long as the
environment PATH and PYTHONPATH are set correctly to point to the same
Python version scripts. For example, if the first Python in the PATH is
2.3, and the PYTHONPATH includes directories for 2.5, then that will be a
problem. I include in my ~/.bash_login file something like:
+
export PYTHON_VERSION=`python -V 21 | sed -e '[EMAIL PROTECTED]@ @2' | awk
'{ print $2
}'`
export PYTHON_ROOT=`which python | sed -e 's@/bin/python@@g'`
PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages
# for GNU Radio default prefix;
# change /usr/local to reflect the correct configure prefix
if [ ${PYTHON_ROOT} != /usr/local ]; then
PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python${PYTHON_VERSION}/site-packages
fi
export PYTHONPATH
+
which, of course, depends on the installed version of Python not changing
... else one would need to source ~/.bash_login to get these environment
variables updated. IIRC, for non-Framework installs of Python, the default
(intrinsic) PYTHONPATH includes
'${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages'. For the
Framework version on OSX, this is NOT included by default because the Python
binary knows about the Framework install location and looks there instead.
Hence this particular part of the PYTHONPATH must be included on OSX. I
submitted a quick and simple patch to MacPorts for the default
Re: [Discuss-gnuradio] Any GR MacOS X 10.5 Intel Users?
Hi Michael, I tried to install GNU Radio on 10.5.5, but it didn't work. Shortly after the install, I had a HD crash, and thus have to start from scratch at some point. I can write down what I am doing for others, if that would be helpful? One question that I remember I had during the install: Which python should I use? While installing some of the port packages, port automatically installed an additional python, and thus I had two pythons, both 2.5, installed, and I think that this was one of the conflicts that I had at the end. Since Mac OS X already comes with 2.5, I think port should not reinstall one, though how can I force port to do so? Cheers, Thomas On Tue, Sep 30, 2008 at 8:30 AM, Michael Dickens [EMAIL PROTECTED] wrote: Anyone out there using GNU Radio on Mac OS X 10.5 for Intel? The PPC-Mac seems to continue to work, but the Intel-Mac update to 10.5.5 looks like it breaks GR's fusb code. So if anyone is using GNU Radio on 10.5.5 for Intel successfully or not, I'd like to hear so I can start debugging one way (GR's fusb_darwin implementation) or the other (my OSX 10.5.5 Intel-iMac install). On a related note, it looks like SDCC 2.8.0 overcomes the compile bug issue that's plagued Intel-Mac GNU Radio users for a year or so now. Initial testing looks like both the pre-compiled package and latest MacPorts installs work the same when compiling the USRP code. This again, if anyone is using Intel-Mac, I'd like to hear your experiences using SDCC 2.8.0. Thanks! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) http://gresci.blogspot.com/ - Science articles on green technology ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Predictable latency?
This is correct. Your samples go through buffers, and therefore it is hard to predict the latency each and every sample will have to get from software to the USRP. I did a study on this a while back. If you are interested, you can find the paper here: http://nesl.ee.ucla.edu/document/show/242 What you can do though is calculate the minimum and the maximum latency that the samples will have. Also, I am not sure how far the mblock and GNU Radio is in regards to timestamping outgoing samples (I didn't follow the GNU Radio development lately) is, but if you can tell the USRP when to send out which sample, then you could easily predict the latency itself. Cheers, Thomas On Tue, Aug 19, 2008 at 8:14 AM, Chris Stankevitz [EMAIL PROTECTED] wrote: Geib, Jeffrey (Civilian) wrote: I have an application where I don't necessarily care what the latency is, but I need it to be predictable and/or constant. Is there a way to achieve this with the USRP hardware? USRP supplies data via USB. I believe the delay of USB data through the operating system and into your application is not predictable or constant. Chris ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Don't complain; Just work harder - Randy Pausch Thomas Schmid, Ph.D. Candidate Networked Embedded Systems Laboratory (NESL) University of California, Los Angeles (UCLA) http://gresci.blogspot.com/ - Science articles on green technology ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recommended RF Front End for USRP
Hi Ranga On 12/8/06, M. Ranganathan [EMAIL PROTECTED] wrote: Hello! I am a newcomper to SDR. I have scoured the mailing list but I cant find a definitive answer on the following questions (I suppose its been asked but I cant seem to find answers in the archives at any rate): 1. Can anybody recommend an RF Front end to be used with the USRP from Ettus research? I just got the Basic RX / Basic Tx daughterboard, motherboard + power supply and am looking for recommendations on what to buy so I can experiment with these things. My budget is a few hundred bucks. Can somebody recommend specific products one can buy off the shelf to hook into the Basic RX ? I want to be able to recieve RF signals from a walkie talkie radio and play them on my computer. This really depends on what you want to do. If you want to play with WiFi, Bluetooth etc, then you would need the RFX2400 for the 2.4GHz spectrum. If your walkie talkie uses the 400MHz ISM band (most likely), then you need the RFX400. 2. What is the simplest meaningful thing one can do to get started with SDR? (I am looking to bootstrap myself into this before trying to do anything serious so a fun learning project is what I am looking for.) The simplest thing is to hook up a metallic wire and try to receive AM/FM radio. Look at the examples in gnuradio-example. They will help you further. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fusb_nblock and fusb_block_size
Hi Eric,
Thank you for the clarifications. I traced the code back to
usrp_basic.cc, but got lost there. I will have a look at
fusb_linux.{h/cc}.
Thomas
On 11/29/06, Eric Blossom [EMAIL PROTECTED] wrote:
On Wed, Nov 29, 2006 at 01:46:14PM -0800, Thomas Schmid wrote:
Hi all,
What do the parameters fusb_nblock and fusb_block_size exactly do in
how data is transmitted over the USB to the USRP? I assume that
fusb_nblock indicates how many blocks we have in each USB packet, and
fusb_block_size indicates how big one block is.
fusb_block_size is the size in bytes of the maximum transfer that we
will ask the kernel to make to/from user-space. fusb_nblocks is the
maximum number of transfers (of maximum size fusb_block_size) that we
can have in flight at any given time.
Take a look at fusb_linux.{h,cc} for the details.
My question is, if there is less data available on the USRP (i.e. not
fusb_nblock*fusb_block_size), does it still get sent over the USRP to
the computer?
Yes. The USRP packages data into 512 byte USB packets and sends them
as soon as it can. That's 128 complex samples (16-bit I Q).
How is the smallest amount of data necessary in the USRP defined such
that a packet is sent over the USB to the computer? Is it
fusb_block_size?
It's 512 bytes. It's set in the FX2 firmware.
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large RX Delay
On 11/14/06, Eric Blossom [EMAIL PROTECTED] wrote: On Tue, Nov 14, 2006 at 10:04:46PM -0800, Thomas Schmid wrote: Hi Eric, I did new test today, and you were right. I had a lot of underrun. Therefore, I increase fusb_nbloccks to 8 and fusb_block_size to 2048. Even with this setting, I got some underruns, but they were not often at all. Here are the new numbers (for the code in trunk): Decimation, Nice, Real_Time, mean [s] 8, 10, no, 0.00058 8, -20, no, 0.00057 8, -20, yes, 0.00058 16, 10, no, 0.00108 16, -20, no, 0.00102 16, -20, yes, 0.00106 Interpret this as a CSV file ;). Nice is the nice value with which the process run. Real_time means if real time scheduling was enabled or not. As you can see, these numbers are way better then the ones I had yesterday. Now, here the result for your updated code: Decimation, Nice, Real_Time, mean [s] 8, 10, no, 0.000635 8, -20, no, 0.000629 8, -20, yes, 0.000627 As you can see, the new code performs worse. I didn't do more than these three tests with your code, because I wanted to see a first result, before I spend more time collecting data. Thomas Interesting. Note that real time won't directly impact the the latency, however it should allow you to use smaller values for fusb_nblocks and fusb_block_size without incurring underruns. I'm somewhat surprised that the new code doesn't show less latency. I'll have to think about that some more. I did the tests again (including recompiling of your modifications etc), and this time I took 5000 measurements. The result is the same. The original code is faster. What I noticed is, that I have more Underruns in your modified code than in the original one. This might be why we have a higher delay. When you run out of things to measure, running with real-time, can you try reducing fusb_block_size and fusb_nblocks ;) I will try to do that if I find some spare minutes. It will be interesting to see the result... Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PS3/Cell BE platform
On 11/15/06, Daniel O'Connor [EMAIL PROTECTED] wrote: On Thursday 16 November 2006 16:22, Robert McGwier wrote: The Nividia GPU's have fft and blas running on them. They are doing teraflops and the tools/SDK are available under NDA. They do indeed have multiply , accumulate, etc. ATI/AMD have something similar.. http://ati.amd.com/companyinfo/researcher/resources.html (Not that I have used either) And somebody even did the implementation of the fft on a GPU for gnuradio already: www.ecsl.cs.sunysb.edu/fir/fir.ps Looks kind of old, but very interesting... Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large RX Delay
Hi Eric, I did new test today, and you were right. I had a lot of underrun. Therefore, I increase fusb_nbloccks to 8 and fusb_block_size to 2048. Even with this setting, I got some underruns, but they were not often at all. Here are the new numbers (for the code in trunk): Decimation, Nice, Real_Time, mean [s] 8, 10, no, 0.00058 8, -20, no, 0.00057 8, -20, yes, 0.00058 16, 10, no, 0.00108 16, -20, no, 0.00102 16, -20, yes, 0.00106 Interpret this as a CSV file ;). Nice is the nice value with which the process run. Real_time means if real time scheduling was enabled or not. As you can see, these numbers are way better then the ones I had yesterday. Now, here the result for your updated code: Decimation, Nice, Real_Time, mean [s] 8, 10, no, 0.000635 8, -20, no, 0.000629 8, -20, yes, 0.000627 As you can see, the new code performs worse. I didn't do more than these three tests with your code, because I wanted to see a first result, before I spend more time collecting data. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Large RX Delay
I am currently investigating different USRP delays. Some of them I can explain, others not. For example, I see an average delay of 6.2ms while receiving data from the USRP at a sample rate of 8MHz (short real samples, i.e. I am using the usrp.source_s). Here is my setup: - I have a function generator which generates a 1Hz square wave. This signal is fed into a LFRX on the USRP and into CH1 of an oscilloscope. - On the PC side, I modified the null sink to check for a pos/neg signal (with some thresholding). When the signal is high, I output 1 on the parallel port, when it is low, I output 0. The parallel port is also hooked up to the Oscilloscope. This allows me to measure the delay between the two signals. - I usefusb_block_size=512, fusb_nblocks=1 Here are some numbers I got: - decimation 8: mean delay 6.1ms - decimation 32: mean delay 6.4ms - decimation 64: mean delay 4.3ms - decimation 256: mean delay 14.7ms First of all, I don't understand why we have such a high delay. Shouldn't it be more in the hundreds of /mu s instead of in the ms range? Second, why is the delay shorter for decimation 64, and again larger for a decimation of 256? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large RX Delay
I use the outb command to change the parallel port. From what I read, that command should have a delay of around 1 \mu s, not more. I am not sure about the context switches, but I am almost sure that this is not the problem. I don't run anything else on the machine (i.e., no other heavy load process), and the machine is pretty powerfull (dual CPU, dual core with huyper threading, that makes 8 CPU's under linux). If it helps, I am running the stock Ubuntu 6.10 kernel (2.6.17-10-generic #2 SMP Fri Oct 13 18:45:35 UTC 2006 i686 GNU/Linux). Additionally, I was able to measure the TX delay for burst transmission with a similar technique to be in the order of a couple of hundred \mu s. This is why I am wondering about the large RX delay. Thomas On 11/13/06, Daniel O'Connor [EMAIL PROTECTED] wrote: On Tuesday 14 November 2006 11:33, Thomas Schmid wrote: First of all, I don't understand why we have such a high delay. Shouldn't it be more in the hundreds of /mu s instead of in the ms range? Second, why is the delay shorter for decimation 64, and again larger for a decimation of 256? How many times a second is your OS switching process context? How are you frobbing the parallel port? Does it involve a syscall? -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large RX Delay
Hi Eric, On 11/13/06, Eric Blossom [EMAIL PROTECTED] wrote: On Mon, Nov 13, 2006 at 05:03:17PM -0800, Thomas Schmid wrote: I am currently investigating different USRP delays. Some of them I can explain, others not. For example, I see an average delay of 6.2ms while receiving data from the USRP at a sample rate of 8MHz (short real samples, i.e. I am using the usrp.source_s). With usrp.souce_s, you still get 16-bit I Q, they're just interleaved in the single stream. This may be the cause of some confusion. Thus, if you set decim == 8, you'll be getting 8 MS/s complex across the USB. This is 32MB/sec == 16 M shorts/sec. Ah, yes that makes sense. I will take that into considerations and go through my calculations again. Here is my setup: - I have a function generator which generates a 1Hz square wave. This signal is fed into a LFRX on the USRP and into CH1 of an oscilloscope. - On the PC side, I modified the null sink to check for a pos/neg signal (with some thresholding). When the signal is high, I output 1 on the parallel port, when it is low, I output 0. The parallel port is also hooked up to the Oscilloscope. This allows me to measure the delay between the two signals. - I usefusb_block_size=512, fusb_nblocks=1 I suspect that you are getting overruns with this configuration. You're not saying anything about this, but I doubt it's going to work well with fusb_nblocks = 1. Try running it with fusb_nblocks = 4. At the high data rates, this still isn't a reliable rate on my Core Duo laptop. I have to check that. I put stderr into a different file to see my own debug output. Might very well be that I get a lot of underruns. Here are some numbers I got: - decimation 8: mean delay 6.1ms - decimation 32: mean delay 6.4ms - decimation 64: mean delay 4.3ms - decimation 256: mean delay 14.7ms Have you logged the received data to a file? Remember, you're not getting real samples. You're getting interleaved I Q. No, I do not log the received data into a file. I record the wave forms on the oscilloscope and do a post processing on them in octave. First of all, I don't understand why we have such a high delay. Shouldn't it be more in the hundreds of /mu s instead of in the ms range? Yes, at the high input rates. Second, why is the delay shorter for decimation 64, and again larger for a decimation of 256? Underruns and/or incorrect examination of the incoming data? I think now, after considering your response, that this might be the problem. I will check both things tomorrow and do the measurements again. Hopefully I will find smaller delays. Also, the received data (and transmitted data too) is quad buffered in the FX2, so there's a maximum of 4 512-byte buffers between you and the data on the receive path. This could be reduced without much trouble to double buffered. But I don't think this is really the problem. With the quad buffered case and decim = 8, the most data that could be buffered in the FX2 is 4*512 = 2048 -- 2048/32e6 = 64 us worth. Right now I'm looking at how the received data buffering is done in the usrp and gr-usrp code. Looks like there may be a problem/opportunity in the usrp1_source_base.cc. I'll get back to you with more info in a bit... Thank you very much. I am looking forward to your response. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems installing wxPython
On 11/12/06, Eric Blossom [EMAIL PROTECTED] wrote: On Sun, Nov 12, 2006 at 08:43:15PM +, Newell Jensen wrote: Eric, I am running a SuSE 10.0 distribution. I looked throughout the repsoitories, on the DVD, as well as the suse.org site for package downloads and didn't find anything. OK. I know it was available in the for pay version of 10.0, because I did use that in the past. You might try building starting with the source rpm file: http://prdownloads.sourceforge.net/wxpython/wxPython2.7-2.7.2.0-1.src.rpm Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Hi Newell Try this package: http://www.novell.com/products/linuxpackages/suselinux/python-wxgtk.html Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Delay Measurements
On 11/8/06, Eric Blossom [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2006 at 03:14:01PM -0800, Thomas Schmid wrote: I set the fusb buffering for the square wave test, additional to setting real time scheduling. The result is similar. For different decimation factors I get delays. What I didn't notice before is the following: Now, the delay increases with higher decimation factor and it looks almost linear, i.e., if I double the decimation factor, the delay increases by a factor of two. Does that make sense? Absolutely ;) In your test case the ultimate flow control is the speed of transfer across the USB. This is determined by the decimation factor. The siggen block is going to run as fast as it can and *WILL* fill up all available buffering downstream from it. If your test case is a gr.sig_source followed by the USRP, I would expect that the runtime system would have allocated 32kB of buffering between the sig_source and the usrp sink. gr_complex 32kB * -- = 4096 complex samples 8 bytes That's the buffering between the sig_source output and the usrp input. That amount is constant (and known). Note that if the sig_source wasn't flow controlled by the usrp consumption rate, the buffer would not be full. So, you've got a 4096 sample fixed delay (probably actually 4095) between the output of the sig_source. You know your data rate across the USB, and thus can subtract off the constant delay. Also, the usrp.sink_c sets it's output_multiple to 128 samples, so it's always going to wait until there's at least 128 complex samples available before it runs (that's 1 full USB packet). I am actually using the short sink. But I assume this doesn't change the concept and just changes the amount of samples in the buffers. I don't really understand that behavior, since I assumed that the delay should be constant. It is, in samples. Hope this helps. Note that if you're not flow controlled (the typical case with discontinuous transmission), you'll get a better measure. You could test this with a source that returned 0 for noutput items, except that every N seconds, it toggled the parallel port lines and then produced its burst of output. Ah, this explains the differences in the delays from the packet source tests I did earlier. It does make sense now. You'll want to be sure to calibrate out the time to wiggle to parallel port lines. I'm assuming you're doing it with a direct iob to the parallel port control or data registers. Yes, I am using iob. The parallel port delay is supposedly 1us, i.e., I can toggle the parallel ports at the speed of the bus it is connected to, which is apparently around 1MHz. This delay is so small, compared to the USRP delays, that I didn't factor it in (yet). So, just to make sure that I understood your explanation. The USB bus speed is set by the interpolation factor (sorry, I used decimation before, though this is the case when we receive, not send. My fault...). The buffer before the USB driver is filled all the times by our signal source. And this buffer is emptied at the set USB speed. Thank you very much, Eric. Your explanation was very helpful. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Delay Measurements
Hi Eric, I did some calculations and something doesn't add up. As I mentioned in my last email, I am using usrp.sink_s. Thus, my samples are real shorts (16 bit). I verified the buffer size by printing out the buffer allocation size in gnuradio-core/src/lib/runtime/gr_buffer.cc. The size is 32KB. If I am using an interpolation factor of 400, then my sample rate should be 128M/400=320k and thus the USB speed should be 320k*2B=640kB/s. With this number, the estimated delay for a sample to pass through the buffer should be 32k/640k=0.05s. The problem is, that I measure about 28ms. I think I shouldn't complain, since in reality the system is faster than what I calculated. Though I still would like to understand what's going on ;) Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP Delay Measurements
On 11/8/06, Eric Blossom [EMAIL PROTECTED] wrote: On Wed, Nov 08, 2006 at 02:06:11PM -0800, Thomas Schmid wrote: Hi all, I am currently trying to measure delays on the USRP and found some interesting things. I wanted to see if others have similar results: - First I measured the round trip time of my IEEE 802.15.4 implementation. I have to computers, one runs a ping application, the other one a pong. The average delay in this case is 26.8ms. - Next, I measured the round trip time of my FSK implementation (also based on packets). Here, the mean RTT is 14.9ms. - Next, I tried to find out the one way delay, i.e., how much time does it take between generating one sample at the computer, until that sample gets sent out at the USRP output. For this, I changed the code of the sig_gen class such that it generates a square wave instead of a cosine and I added code that toggles the parallel port pins according to the state of the square wave. Then I used an oscilloscope to measure the delay between the two signals, i.e., the one generated at the parallel port and the one from the USRP (LFTX). The signal is at 2 Hz. The delays in this case depend a lot on what I choose for the decimation (while keeping a constant square wave frequency). If I use decimation=500, then I find an average delay of 65.8ms. When I change the decimation to something else, I get values ranging from 30ms up to 150/200ms (I didn't do exact measurements for these yet). What I am wondering is, why is there such a huge difference? Is it because of the GNU Radio scheduler? Or is there some other problems? Thomas Have you tried explicity setting the fast usb buffering? Take a look at the examples in gnuradio-examples/python/digital/*.py I set the fusb buffering for the square wave test, additional to setting real time scheduling. The result is similar. For different decimation factors I get delays. What I didn't notice before is the following: Now, the delay increases with higher decimation factor and it looks almost linear, i.e., if I double the decimation factor, the delay increases by a factor of two. Does that make sense? I don't really understand that behavior, since I assumed that the delay should be constant. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Up Conversion Weirdness
Hi Tom On 10/25/06, Tom Rondeau [EMAIL PROTECTED] wrote: First, I assume you meant the second to last line to read: self.connect(self.multiplicator, self.amp, self.u) No, this is exactly the problem. Even if I directly hook up the interpolator1 to the USRP, it doesn't work. So, hooking up something to a different path in the flow graph results in the problem. But I also tried it this way with the same effect. What is the sampling rate at this point in the flow graph, and what is the frequency of the sine wave? I'm just trying to make sure you're not upconverting beyond the first Nyquist zone. For this app, you're still looking at the upconverted signal as baseband, so your sampling rate must be at least 2x(f_sin + signal BW). I assume that's what the interpolator is doing, but just making sure. Sorry, I forgot to mention that. The frequency of the sine wave is around 500kHz. The Sampling rate of the sine wave is 4MS/s and the signal bandwidth is around 300kHz. So yes, the interpolator interpolates the signal to the required 4MS/s. What's the file look like when you plot it locally? After doing some more tests, I found out the following. Instead of sending it to the USRP, i sent the data to a second file sink. The data looks fine, but it is way too short. In the case where it works, the filesize is around 80MBi for 100 sent packets. In the second case, the file is only about 4MBi and contains only the first 9 packets instead of 100 (tested by running it through the decoder). Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Up Conversion Weirdness
Hi Everyone, I have some strange behavior of gnuradio while trying to do an upconversion and multi-channel transmitter. I am currently trying to have two packet transmitters send packets simultaniously on two different radio channels. For this, I upconvert one of the transmitters and add the two signals together. Following is the code to connect the different blocks: # interpolate the two transmitters self.connect(self.packet_transmitter1, self.interpolator1) self.connect(self.packet_transmitter2, self.interpolator2) # upconvert the first transmitter) self.connect(self.interpolator1, (self.multiplicator, 0)) self.connect(self.sin, (self.multiplicator, 1)) # add the two signals self.connect(self.multiplicator, (self.adder, 0)) self.connect(self.interpolator2, (self.adder, 1)) # send the signal to the USRP self.connect(self.adder, self.amp, self.u) #self.connect(self.adder, self.filesink) The code compiles, but I don't receive the messages on the other side. Therefore, I did some tests to check the different parts. The following connection works, i.e., the packet transmitter and its interpolation can be received at the other side: self.connect(self.packet_transmitter1, self.interpolator1) self.connect(self.interpolator1, self.amp, self.u) Now, if I add the following, it suddenly doesn't work anymore, even though the added connections should not affect the path to the USRP: self.connect(self.packet_transmitter1, self.interpolator1) self.connect(self.interpolator1, (self.multiplicator, 0)) self.connect(self.sin, (self.multiplicator, 1)) self.connect(self.interpolator1, self.amp, self.u) self.connect(self.multiplicator, self.filesink) Does anyone know why this could happen? Thanks a lot, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] The Mystery Deepens: GNU Radio on Intel-Mac
I tested on my macbook with XCode 2.3. I installed libusb 0.1.12_0 with darwinports and got the latest GNURadio code. Starting the benchmark_usb.py failed as before. So no luck here. Thomas On 10/6/06, Michael Dickens [EMAIL PROTECTED] wrote: As long as you have the XCode 2.3 disk image, you can always downgrade back when you're done. There is an uninstaller provided on the disk image; you'll (for some unknown reason) need to reboot after either the uninstall or the reinstall. Your trying 2.4 would certainly add an interesting data point to the investigation. - MLD On Oct 6, 2006, at 3:46 AM, Jan Schiefer wrote: I am still on XCode 2.3 and will now definitely refrain from upgrading, for now. I can probably be talked into deliberately breaking my working MBP install by upgrading for testing purposes. shiver / ___ 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] The Mystery Deepens: GNU Radio on Intel-Mac
Hi Michael I have XCode 2.2.1 on my macbook and the USRP is not working. I agree, this is very, very strange.. Thomas On 10/5/06, Michael Dickens [EMAIL PROTECTED] wrote: * I can easily show on our brand new 20 Intel-iMac that a recent (Wednesday) SVN checkout of GNU Radio will compile, check, and install, but USB transport doesn't work. On a similarly equipped PPC-Mac, USB transport does function (albeit slowly in comparison, maybe 1/2 the speed, w/ the Intel-iMac maxing out at 32 M-Bytes/s - which is good news for those moving to Intel-Macs). * I can also show on the same computer that a compile on a MacBook Pro (MBP) dated (checked out on) July 13 does allow for USB transport. * GNU Radio uses dynamic libraries, and one of those is LIBUSB (for the USB transport), and the installed version of LIBUSB was just performed this week from version 0.1.12 - the same as what's installed on the MBP. * By changing a link in /usr from local_old (for the MBP compile from July 13) to local_new to the compile I did this week, the USB transport will either work or not (respectively). The facts thus far lead (past tense) me to believe that it was a change in GNU Radio's software. * I then retrieved an archive of the actual source code for the local_old install from the MBP and dropped it onto the Intel-iMac. I then made everything anew from that codebase (from July 13, which worked before) ... and ... drum roll please it DID NOT work! This now leads me to believe it was the change in XCode from 2.3 to 2.4 (released August 11, which would be about the time folk started noticing oddness). Since 2.3 is compatible with the Intel-Mac's, I will revert the install back to 2.3 to check out this theory (likely early next week). Yet even more as testing goes further. - MLD ___ 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] Anyone using an Intel-Mac Mini?
Hi Michael, Yes, I do have a MacMini running the USRP. It works without any problems. I run the latest OSX, 10.4.7 and installed everything with darwin ports. My Macbook does not work under Mac OS X, but when I run linux on it (Ubuntu) gnuradio works. Thomas On 9/29/06, Michael Dickens [EMAIL PROTECTED] wrote: ... for compiling / running GNU Radio w/ a USRP? According to Apple's USB folks, that architecture is quite similar to the MacBook (and MacBook Pro) - the former of which seems to have issues doing USB transfers w/ the USRP due to either LIBUSB or changes to the Darwin USB architecture (there have been a few changes, according to the Apple rep, but those should affect -all- Intel-Macs running 10.4.7 and newer). Further, if you have a successful install of GR on an Intel-Mac, could you email me (off list) with which Mac type, OSX version, and how you installed the background apps and libraries (e.g. by hand, DarwinPorts, Fink, whatever). The rep is also curious about which Intel-Macs -do- work, since that might help track down the bug. Thanks in advance! - MLD ___ 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] Trouble understanding multiple independent signals
You are correct. The signals need to be at the same sampling rate for the interleaver to work. We are currently working on a modification of that such that you can have different rates on both channels. Thomas On 9/18/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi all, I have been playing around with the fm_tx_2_daughterboards.py and others to send multiple signals at once. I just wanted to confirm my suspicions about the USB transmit path because I didn't see anyone explicitly talking about this: When I look in the usrp1.py and usrp.py files that only one interpolation parameter is given per USRP sink. So, I am assuming for now that the signals I transmit must have the same sampling rate (i.e. the same interpolation rate) coming across the USB cable. Is this correct? Because the signals will have to be interleaved to go across the USB, it would make sense that they would have to be the same sampling rate, but maybe I'm missing something. Thanks for any comments, David Scaperoth ___ 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] scheduler and special interleaver block
Hi Everyone, I have a question about the gnuradio scheduler and the interleaver block. Let's assume that we have an interleaver block with two inputs and one output. Now, is it correct that the gnuradio scheduler runs the interleaver block only if there is data on both interleaver-input channels? If this is the case, then it would be complicated if you had two message sources because the two message sources would be independent and not generate messages at the same time and of the same size. Thus, the interleaver block would not work. Would it be possible to write a special interleaver block which checks both inputs. If there is input on one channel, but not on the other, the interleaver interleaves the data from that channel with 0's (or some other defined value). Thank you very much for any comments on this issue, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Theory - GSM traffic detection with a USRP board
On 8/31/06, Carlo E. Prelz [EMAIL PROTECTED] wrote: Subject: Re: [Discuss-gnuradio] Theory - GSM traffic detection with a USRP board Date: mer 30 ago 06 02:41:01 +0200 They have been created as a result of the compilation of a CVS repository source base, updated just before compiling. I am loading to the USRP the two files, std.ihx and std_2rxhb_2tx.rbf. Are you sure that you use CVS? Because GnuRadio now uses a subversion system. Therefore, it might be that you use an old version. Here is the link to the new version, just in case: http://gnuradio.utah.edu/trac Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] two packet transmitters on two daugherboards
Hi everyone, I have a little conceptual problem I don't seem to be able to solve. I want to have two packet transmitters, one for the daughterboard in slot A, the other one for the daughterboard in slot B. The two daughterboards work at different frequencies and use different protocols, i.e., they have a different interpolation rate etc. I saw the example on how to use two TX, though this is not possible in that scenario, because we can not assume that we always have a packet to send on both channels. Therefore, I tried to use a basic approach that before you send a message on one board, you reconfigure the USRP. This doesn't seem to work. My test consisted of first configuring the USRP for the daughterboard in slot A. Then, I send two messages. These are sent successful (I can see them on a second USRP on an other computer). Then, I reconfigure the USRP and send the next two messages over the daughterboard in slot B. This does not work. The messages are sent out, though I don't see them on the other USRP! It is to note that I don't stop the flowgraph before I reconfigure it because the stop() just blocks and never continues. Does anybody have an idea on what is going wrong? Do I have to stop the flowgraph before I reconfigure the USRP? if so, how can i achieve that stop does not block forever? An suggestions on how to solve that problem are appreciated. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP question
I have a question which confuses me all the time. If I connect a RFX400 (or RFX2400) to the USRP and receive the samples from it on the PC, what are those samples exactly? Are they in baseband? Or are they still in the intermediate frequency? Thank you very much, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with USB on OSX?
Nope, no news. My sollution was to install Ubuntu on my macbook. That works just fine. I will try XCode 2.4. Didn't know that it is released. Thomas On 8/10/06, Michael Dickens [EMAIL PROTECTED] wrote: Thomas - Did you make progress on this? I'm wondering if it's an Intel-MacBook issue, since it doesn't seem to pop up for the MacBook Pro, nor Intel-mini, nor Intel-iMac (or, at least I haven't heard of such a thing). I doubt it will help, but you can try XCode 2.4 now that it's released. - MLD On Aug 4, 2006, at 5:54 AM, Thomas Schmid wrote: I downgraded my XCode to 2.2.1 but it didn't help. Still, the USRP does not work. I also tried all the other suggestions, programming in Mac OS X and look if it works under Linux, but doesn't work either. Fresh installing GnuRadio, but still doesn't work. I will now try to reinstall my MacOS on a seperate disc and see if that might change things. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Intel Mac GNU Radio Install Update Soon
Sorry for the confusion, usually I separate the make and make install
and only use sudo on the make install, but sometimes, especially if
you work on multiple machines at the same time, you get a little bit
lazy ;)
So, I checked out a new version and did the make seperate from the
install, and it failed again, though with a different error. btw,
reissuing the same command (with -j3) compiles the code.
cut text above, there is more successfull commands before here
/opt/local/bin/glibtool --tag=CXX --mode=link g++ -g -O2 -Wall
-Woverloaded-virtual -L/opt/local/lib -o libgnuradio-core-qa.la
-rpath /usr/local/lib -version-info 0:0:0 bug_work_around_6.lo
filter/libfilter-qa.la general/libgeneral-qa.la
runtime/libruntime-qa.la missing/libmissing.la libgnuradio-core.la
-L/opt/local/lib -lcppunit -ldl
rm -fr .libs/libgnuradio-core-qa.lax
mkdir .libs/libgnuradio-core-qa.lax
rm -fr .libs/libgnuradio-core-qa.lax/libfilter-qa.a
mkdir .libs/libgnuradio-core-qa.lax/libfilter-qa.a
Extracting
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/filter/.libs/libfilter-qa.a
(cd .libs/libgnuradio-core-qa.lax/libfilter-qa.a ar x
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/filter/.libs/libfilter-qa.a)
rm -fr .libs/libgnuradio-core-qa.lax/libgeneral-qa.a
mkdir .libs/libgnuradio-core-qa.lax/libgeneral-qa.a
Extracting
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/general/.libs/libgeneral-qa.a
(cd .libs/libgnuradio-core-qa.lax/libgeneral-qa.a ar x
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/general/.libs/libgeneral-qa.a)
rm -fr .libs/libgnuradio-core-qa.lax/libruntime-qa.a
mkdir .libs/libgnuradio-core-qa.lax/libruntime-qa.a
Extracting
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/runtime/.libs/libruntime-qa.a
(cd .libs/libgnuradio-core-qa.lax/libruntime-qa.a ar x
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/runtime/.libs/libruntime-qa.a)
rm -fr .libs/libgnuradio-core-qa.lax/libmissing.a
mkdir .libs/libgnuradio-core-qa.lax/libmissing.a
Extracting
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/missing/.libs/libmissing.a
(cd .libs/libgnuradio-core-qa.lax/libmissing.a ar x
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/missing/.libs/libmissing.a)
g++ -dynamiclib -single_module ${wl}-flat_namespace ${wl}-undefined
${wl}suppress -o .libs/libgnuradio-core-qa.0.0.0.dylib
.libs/bug_work_around_6.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_ccomplex_dotprod_x86.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_complex_dotprod_x86.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_dotprod_x86.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_filter.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_float_dotprod_x86.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_gr_fir_ccc.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_gr_fir_ccf.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_gr_fir_fcc.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_gr_fir_fff.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_gr_fir_scc.o
.libs/libgnuradio-core-qa.lax/libfilter-qa.a/qa_gri_mmse_fir_interpolator.o
.libs/libgnuradio-core-qa.lax/libgeneral-qa.a/qa_general.o
.libs/libgnuradio-core-qa.lax/libgeneral-qa.a/qa_gr_circular_file.o
.libs/libgnuradio-core-qa.lax/libgeneral-qa.a/qa_gr_firdes.o
.libs/libgnuradio-core-qa.lax/libgeneral-qa.a/qa_gr_fxpt.o
.libs/libgnuradio-core-qa.lax/libgeneral-qa.a/qa_gr_fxpt_nco.o
.libs/libgnuradio-core-qa.lax/libgeneral-qa.a/qa_gr_fxpt_vco.o
.libs/libgnuradio-core-qa.lax/libruntime-qa.a/qa_gr_block.o
.libs/libgnuradio-core-qa.lax/libruntime-qa.a/qa_gr_buffer.o
.libs/libgnuradio-core-qa.lax/libruntime-qa.a/qa_gr_io_signature.o
.libs/libgnuradio-core-qa.lax/libruntime-qa.a/qa_gr_vmcircbuf.o
.libs/libgnuradio-core-qa.lax/libruntime-qa.a/qa_runtime.o
.libs/libgnuradio-core-qa.lax/libmissing.a/bug_work_around_8.o
-L/opt/local/lib ./.libs/libgnuradio-core.dylib
/opt/local/lib/libcppunit.dylib -ldl -install_name
/usr/local/lib/libgnuradio-core-qa.0.dylib -Wl,-compatibility_version
-Wl,1 -Wl,-current_version -Wl,1.0
(cd .libs rm -f libgnuradio-core-qa.0.dylib ln -s
libgnuradio-core-qa.0.0.0.dylib libgnuradio-core-qa.0.dylib)
(cd .libs rm -f libgnuradio-core-qa.dylib ln -s
libgnuradio-core-qa.0.0.0.dylib libgnuradio-core-qa.dylib)
rm -fr .libs/libgnuradio-core-qa.lax
mkdir .libs/libgnuradio-core-qa.lax
rm -fr .libs/libgnuradio-core-qa.lax/libfilter-qa.a
mkdir .libs/libgnuradio-core-qa.lax/libfilter-qa.a
Extracting
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/filter/.libs/libfilter-qa.a
(cd .libs/libgnuradio-core-qa.lax/libfilter-qa.a ar x
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/filter/.libs/libfilter-qa.a)
rm -fr .libs/libgnuradio-core-qa.lax/libgeneral-qa.a
mkdir .libs/libgnuradio-core-qa.lax/libgeneral-qa.a
Extracting
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/general/.libs/libgeneral-qa.a
(cd .libs/libgnuradio-core-qa.lax/libgeneral-qa.a ar x
/Users/thomasschmid/gr-build/gnuradio-core/src/lib/general/.libs/libgeneral-qa.a)
rm -fr
Re: [Discuss-gnuradio] Problem with USB on OSX?
I forgot to mention that I have the RFX400 and RFX2400 daughterboards. I also tried the same thing with both daughterboards removed with the same result. Unfortunately I don't have the BasicRX/TX with me and can not test it. Do you have one of the RFX400 or 2400 with which you could test? Thomas On 7/30/06, Thomas Schmid [EMAIL PROTECTED] wrote: Hi Jan, I have two USRPs to test with, one a Rev 3 and one a Rev 4.1. Both have the same behavior, except that one shows version 0.04 and the other 0.02 when I first plug them in (in the system profiler). Then, I run test_usrp_standard_tx, the firmware uploads, i.e. the LEDs start to blink slower, but the system profiler still shows the old values, i.e., they stay at Vendor-specific. I will try to see if I can enable some more debug information. Thomas On 7/29/06, Jan Schiefer [EMAIL PROTECTED] wrote: Hi Thomas, I am using gnuradio+USRP on a MacBook Pro under 10.4.7, this setup should be very similar to yours.I have a version 3b USRP, with a BasicRX and a BasicTX board. Have you checked out http://comsec.com/wiki?UsrpInstall ? When I plug the USRP in my system, before it loads any firmware (i.e. before I run any usrp-related program), I see the following in the System profiler (Apple logo/About This Mac, click More Info... , Hardware/USB, USB High-Speed Bus/Vendor-specific Version 0.02, etc etc Product ID 0x0002, Vendor ID 0xfffe. After running test_usrp_standard_tx, this information changes From Vendor-specific to USRP Rev 2, the version changes to 1.02 and there is a serial number string of all zeroes. Does yours show the same information in the System Profiler? Also, what does it say if you go to the usrp directory and run a svn up? Mine says At revision 832. Cheers, Jan Thomas Schmid wrote: I just installed gnuradio on my macbook and I wanted to test the usrp but got the same error as Sam: @ enter_search 802_15_4_pkt: waiting for packet usrp_basic_rx: failed to start end point streaming Next I tried to use the benchmark_usb.py file and I got this error: Testing 2MB/sec... usrp_open_interface:usb_claim_interface: failed interface 1 usb_claim_interface: couldn't claim interface usrp_basic_tx: can't open tx interface Traceback (most recent call last): File ./benchmark_usb.py, line 106, in ? main () File ./benchmark_usb.py, line 96, in main ok = run_test (rate, verbose) File ./benchmark_usb.py, line 63, in run_test usrp_tx = usrp.sink_s (0, tx_interp) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 230, in __init__ fpga_filename, firmware_filename) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp1.py, line 932, in sink_s return _usrp1.sink_s(*args) RuntimeError: can't open usrp1 Interestingly, the firmware is uploaded successfully, i.e., the led first blinks fast, then slower, and then I get the error. Any ideas on what might be wrong? Thomas On 7/27/06, Michael Klass [EMAIL PROTECTED] wrote: Thanks for the reply Jon. I'm quite sure that it has USB 2.0 ports, though. On 7/26/06, Jonathan Jacky [EMAIL PROTECTED] wrote: I'm using OS X. I've never seen this failed to start end point streaming message. I've not used the flex 400 boards, only the Basic RX/TX and LFRX/TX. Are you sure your Mac has USB 2.0 ports? Until fairly recently (late 2003 or early 2004), Macs came with USB 1.1 ports. There is more information about this 1.1 vs 2.0 business, and how to use the Mac System Profiler to check that OS X recognizes the USRP, at http://staff.washington.edu/~jon/gr-osx/gr-osx-usrp.html#using Jon Jacky ___ 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 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: Intel Mac GNU Radio Install Update Soon
Hi Michael,
Thanks a lot for writing that install guide for Mac OS X. It works
great. Here some updates on my experience with it on a Macbook 2GHz
with XCode 2.3:
- The USRP section is outdated. You don't need to download it
seperatly since the checkout script has been changed.
- Since the new Macbooks have dual core, one can add a -j2 to each
make command. That will speed up compilation because it creates two
gcc instances at a time.
- I converted the tcsh scripts to bash. Here is what I have in my
.profile. This assumes that you use darwinports:
export LDFLAGS=-L/opt/local/lib ${LDFLAGS}
export PATH=/opt/local/bin:${PATH}
export MANPATH=/opt/local/share/man:${MANPATH}
export INFOPATH=/opt/local/share/info:${INFOPATH}
export CPATH=/opt/local/include:${CPATH}
export
PKG_CONFIG_PATH=/opt/local/lib/pkgconfig:/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH}
p_v_f=`python -V 21 | sed -e '[EMAIL PROTECTED] @@g' | sed -e '[EMAIL
PROTECTED]@ @2' |
awk '{print $1}'`
export PYTHON_VERSION=$p_v_f
export PYTHON_ROOT=`which python | sed -e 's@/bin/python@@g'`
export PYTHONPATH=${PYTHON_ROOT}/lib/python${PYTHON_VERSION}/site-packages
if [ ${PYTHON_ROOT} != /usr/include ]; then
export
PYTHONPATH=${PYTHONPATH}:/usr/local/lib/python${PYTHON_VERSION}/site-packages
fi
Could that howto install script maybe be moved into the wiki, once the
new wiki system is up and running?
Thomas
On 6/1/06, Michael Dickens [EMAIL PROTECTED] wrote:
Dave - You can do all of the background install using DarwinPorts,
but, as you found out, FFTW has some issues. The problem is not in
optimization, but rather in the way Apple has tweaked GCC's use of
pentium-pro for the architecture. Most files compile just fine but
a few (4-5) need this option removed for correct compilation (with
optimization -03 still on, which is good).
I have submitted patches to Eric to fix the .align issue - some
compilers define that number in log2 while others use linear. I'd be
happy to ship you my diff's if you have time to try them out.
As of 1 week ago, there were no issues with gnuradio-core other than
the .align and a .global issue in the same .S files in gnuradio-core/
src/lib/filter . Everything compiled and installed correctly on a
MacBook Pro. Admittedly, Apple has released XCode 2.3 since then, so
if you're using that version there might be an issue. We haven't
finished testing under XCode 2.3 yet, maybe due to lack of time.
Permissions are generally a local-computer issue, not one of how they
are stored in the CVS or SVN repository.
I'd be willing to bet that the compile issue is some combination of
your shell environment and LIBTOOL not working together. -Unless-
it's XCode 2.3, then it's most likely not a Mac-Intel issue.
I have updated my install guide http://www.nd.edu/~mdickens/
GNURadio/ to include the latest changes for FFTW to compile using
DarwinPorts on an Intel-Mac.
I'm happy to help you debug your compile issue, probably off-list is
best. - MLD
___
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] Problem with USB on OSX?
I just installed gnuradio on my macbook and I wanted to test the usrp but got the same error as Sam: @ enter_search 802_15_4_pkt: waiting for packet usrp_basic_rx: failed to start end point streaming Next I tried to use the benchmark_usb.py file and I got this error: Testing 2MB/sec... usrp_open_interface:usb_claim_interface: failed interface 1 usb_claim_interface: couldn't claim interface usrp_basic_tx: can't open tx interface Traceback (most recent call last): File ./benchmark_usb.py, line 106, in ? main () File ./benchmark_usb.py, line 96, in main ok = run_test (rate, verbose) File ./benchmark_usb.py, line 63, in run_test usrp_tx = usrp.sink_s (0, tx_interp) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 230, in __init__ fpga_filename, firmware_filename) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp1.py, line 932, in sink_s return _usrp1.sink_s(*args) RuntimeError: can't open usrp1 Interestingly, the firmware is uploaded successfully, i.e., the led first blinks fast, then slower, and then I get the error. Any ideas on what might be wrong? Thomas On 7/27/06, Michael Klass [EMAIL PROTECTED] wrote: Thanks for the reply Jon. I'm quite sure that it has USB 2.0 ports, though. On 7/26/06, Jonathan Jacky [EMAIL PROTECTED] wrote: I'm using OS X. I've never seen this failed to start end point streaming message. I've not used the flex 400 boards, only the Basic RX/TX and LFRX/TX. Are you sure your Mac has USB 2.0 ports? Until fairly recently (late 2003 or early 2004), Macs came with USB 1.1 ports. There is more information about this 1.1 vs 2.0 business, and how to use the Mac System Profiler to check that OS X recognizes the USRP, at http://staff.washington.edu/~jon/gr-osx/gr-osx-usrp.html#using Jon Jacky ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with USB on OSX?
Forgot to mention (and might be relevant), I am using libusb 0.1.12 from darwinports. Thomas On 7/29/06, Thomas Schmid [EMAIL PROTECTED] wrote: I just installed gnuradio on my macbook and I wanted to test the usrp but got the same error as Sam: @ enter_search 802_15_4_pkt: waiting for packet usrp_basic_rx: failed to start end point streaming Next I tried to use the benchmark_usb.py file and I got this error: Testing 2MB/sec... usrp_open_interface:usb_claim_interface: failed interface 1 usb_claim_interface: couldn't claim interface usrp_basic_tx: can't open tx interface Traceback (most recent call last): File ./benchmark_usb.py, line 106, in ? main () File ./benchmark_usb.py, line 96, in main ok = run_test (rate, verbose) File ./benchmark_usb.py, line 63, in run_test usrp_tx = usrp.sink_s (0, tx_interp) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 230, in __init__ fpga_filename, firmware_filename) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp1.py, line 932, in sink_s return _usrp1.sink_s(*args) RuntimeError: can't open usrp1 Interestingly, the firmware is uploaded successfully, i.e., the led first blinks fast, then slower, and then I get the error. Any ideas on what might be wrong? Thomas On 7/27/06, Michael Klass [EMAIL PROTECTED] wrote: Thanks for the reply Jon. I'm quite sure that it has USB 2.0 ports, though. On 7/26/06, Jonathan Jacky [EMAIL PROTECTED] wrote: I'm using OS X. I've never seen this failed to start end point streaming message. I've not used the flex 400 boards, only the Basic RX/TX and LFRX/TX. Are you sure your Mac has USB 2.0 ports? Until fairly recently (late 2003 or early 2004), Macs came with USB 1.1 ports. There is more information about this 1.1 vs 2.0 business, and how to use the Mac System Profiler to check that OS X recognizes the USRP, at http://staff.washington.edu/~jon/gr-osx/gr-osx-usrp.html#using Jon Jacky ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OQPSK for IEEE 802.15.4
Hi Luis, I implemented exactly that. Here is the code: http://acert.ir.bbn.com/projects/gr-ucla/ Thomas On 7/21/06, Luis Simoes [EMAIL PROTECTED] wrote: Hi all, I will implement a ZigBee transceiver on Gnuradio using channels in the 2.4GHz ISM band. I studied a bit the IEEE standart and I could observe that ZigBee uses DSSS channel encoding with 32 chips long random noise sequences and an offset QPSK modulation scheme. The offset between In-phase and quadrature streams is a half symbol duration. Does anybody have an idea how to build a phase detector and decision device for this modulation in Gnuradio? What's about the costas loop for QPSK detection? Is this loop able to trigger the offset fast enough or should I build two phase detection loops, one for each stream (I Q). After having the two streams what could be the best way to achieve symbol recovery? And , as last question for the moment, in transmission mode how can I build a delay for the offset needed? DSSS is not a big deal and I think that I will write a block with simple mapping tables. I am still designing the application and some tips would be very precious to start implementation by the right way. I appreciate any advise or tip and I'd like to thank all of you in advance. Luis ___ 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] Tools for FPGA programming
Hi Matt, What tools are you using to do the FPGA programming? And which tools did you use to layout the USRP motherboard? We have the mboard files from www.ettus.com, though we are not really sure with what application we can use them (except the pdf/ps files...) Thank you, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] RFX-2400 Loopback
How does your physical setup look like?, i.e., how did you connect the RX to the TX? There were a couple of messages on this mailing list about that a couple of days ago... Cheers, Thomas On 6/22/06, Lee Patton [EMAIL PROTECTED] wrote: I'm trying to do a simple loopback using the RFX-2400. I have written custom source and sink blocks, and everything works fine when I connect them directly [e.g, fg.connect ( src, dst)]. However, I get weird data in my output file when I put the USRP between them [e.g., fg.connect ( src, u_snk); fg.connect ( u_src, dst)]. There is obviously something I do not understand about the board I'm using. I've attached my (short) script, and would greatly appreciate it if one of you gurus would take a look. Oh, and I'm connecting the Tx/Rx port directly to the Rx port w/ 3ft of coax. Thanks, Lee ___ 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] IEEE 802.15.4 Physical Layer Block
Hi Everyone, Over the last couple of months I developed a IEEE 802.15.4 physical layer block. It is capable of receiving and transmitting to IEEE 802.15.4 compliant hardware. The block implements the physical layer, i.e., it can en- and decode the messages. The block itself does not comply with IEEE 802.15.4 because the timing constraints are just too small to achieve right now. Some caveat: - You need a fast computer. My P IV 2.8 GHz could barely keep up with the data flow. - Right now, we need to send an additional 100 byte at the end of each message or else, the other side can not decode them. Still figuring out why that is. You can find the code here: https://acert.ir.bbn.com/projects/gr-ucla/ Please feel free to send me any comments and bug reports ;) Cheers, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] IEEE 802.15.4 Physical Layer Block
On 6/20/06, Eric Blossom [EMAIL PROTECTED] wrote: On Tue, Jun 20, 2006 at 10:44:05AM -0700, Eric Blossom wrote: On Tue, Jun 20, 2006 at 10:29:33AM -0700, Thomas Schmid wrote: Hi Everyone, - Right now, we need to send an additional 100 byte at the end of each message or else, the other side can not decode them. Still figuring out why that is. Probably not padded out to a USB boundary. See the kludge in packet_utils.py I thought so, but searching in packet_utils.py I figured out that this can not be the case. Here my reasoning: - IEEE 802.15.4 does spreading, i.e., each data byte gets spread to 64 bit - I then upsample by 2 to get nyquist rate - Each sample is 16 bit (i.e. 2 byte), thus we get the 512 byte for the usb packet In short, each data byte will yield one usb packet. I experimented a little bit further and found that when I don't pad at the end of the message, then the bytes received at the receiver are not correctly synchronized and thus, at some point, I get an error in despreading. The 100 bytes I mentioned before are from an earlier experiment where my packets were smaller. I now use a packet with 28 bytes and need to pad it with 50x 0 bytes and the packets get received correctly by a CC2420 radio chip and my GnuRadio code. If I don't zero pad, or if I zero pad with a smaller amount (like 5x 0 bytes) then, the packet gets received by my GNURadio code, though the bytes are wrong (so, there is stuff sent out), but the CC2420 fails since the CRC at the end is wrong. This shows me, that the problem must be on the sending side, not the receiving... Any ideas why that could happen? Are there any other buffers in the FPGA I have to take care of, i.e., needs to be flushed? Cheers, Thomas This will be properly fixed when the mblocks are ready. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USB2, 32 MByte/s or 480MBit/s?
Hi, I was wondering why can the USRP only achieve 32 MByte/s, i.e. 256 Mbit/s whereas the USB 2.0 specifications are 480 MBit/s? The 32 Mbyte/s is mentioned in several earlier posts on the gnuradio mailing list archive and in the BBN report (freebsd section). Thanks, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Basic RX/TX
Hi, I have a question about the basic RX/TX boards. What should I see if I hook the basic TX board to an oscilloscope if I send out a QPSK signal? Here is what I do: - I generate a QPSK signal in GnuRadio - I send the signal to a complex file source and the signal looks right - I send the signal to the complex USRP source and have a BasicTX on it. The outputs TXA and TXB are hooked up to a oscilloscope on channel 1 and 2 respectively. Now, what should I see on the oscilloscope? Is it the baseband signal? How does the I and Q phases get mixed together? Does that depend on the mux values? Unfortunately I couldn't find a good block diagram of the TX path on the wiki, i.e., the link to [A system block diagram of the USRP receiver and transmitter path] on the wiki page http://www.comsec.com/wiki?UniversalSoftwareRadioPeripheral; is dead. Cheers, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP locks?
Hi,
I experience some problems with my USRP and the RFX2400. When I run a
simple program to capture data samples from the USRP it locks after
some time (minutes to hours). There is no crash, it just stops
receiving samples. I attached the code to this email so others can try
it out to see if it is my setup or not.
The program is very simple. It configures the USRP and sends the
samples to /dev/null. I modified the file sink to inclue a counter so
I can see if there are samples coming from the USRP or not. The diff
is here:
Index: gr_file_sink.cc
===
RCS file: /sources/gnuradio/gnuradio-core/src/lib/io/gr_file_sink.cc,v
retrieving revision 1.4
diff -r1.4 gr_file_sink.cc
57a58
d_counter = 0;
123a125,126
141a145,148
d_counter += 1;
if (d_counter % 1 == 0){
fprintf(stdout, count %d\n, d_counter), fflush(stdout);
}
I have the latest CVS/SVN version and use python 2.4.
Any ideas what could be wrong?
Thomas
#!/usr/bin/env python
from gnuradio import gr, eng_notation
from gnuradio import usrp
from gnuradio.eng_option import eng_option
from optparse import OptionParser
import math, struct, time
#from gnuradio.wxgui import stdgui, fftsink, scopesink
#import wx
start = 0
def pick_subdevice(u):
The user didn't specify a subdevice on the command line.
If there's a daughterboard on A, select A.
If there's a daughterboard on B, select B.
Otherwise, select A.
if u.db[0][0].dbid() = 0: # dbid is 0 if there's no d'board or a problem
return (0, 0)
if u.db[1][0].dbid() = 0:
return (1, 0)
return (0, 0)
class stats(object):
def __init__(self):
self.npkts = 0
self.nright = 0
class rx_graph (gr.flow_graph):
st = stats()
def __init__(self):
gr.flow_graph.__init__(self)
parser = OptionParser (option_class=eng_option)
parser.add_option(-R, --rx-subdev-spec, type=subdev, default=None,
help=select USRP Rx side A or B (default=first one with a daughterboard))
parser.add_option (-c, --cordic-freq, type=eng_float, default=247500,
help=set Tx cordic frequency to FREQ, metavar=FREQ)
parser.add_option (-r, --data-rate, type=eng_float, default=200)
parser.add_option (-f, --filename, type=string,
default=rx.dat, help=write data to FILENAME)
parser.add_option (-g, --gain, type=eng_float, default=0,
help=set Rx PGA gain in dB [0,20])
parser.add_option (-N, --no-gui, action=store_true, default=False)
(options, args) = parser.parse_args ()
print cordic_freq = %s % (eng_notation.num_to_str (options.cordic_freq))
#
self.data_rate = options.data_rate
self.samples_per_symbol = 2
self.usrp_decim = int (64e6 / self.samples_per_symbol / self.data_rate)
self.fs = self.data_rate * self.samples_per_symbol
payload_size = 128 # bytes
print data_rate = , eng_notation.num_to_str(self.data_rate)
print samples_per_symbol = , self.samples_per_symbol
print usrp_decim = , self.usrp_decim
print fs = , eng_notation.num_to_str(self.fs)
u = usrp.source_c (0, self.usrp_decim)
if options.rx_subdev_spec is None:
options.rx_subdev_spec = pick_subdevice(u)
u.set_mux(usrp.determine_rx_mux_value(u, options.rx_subdev_spec))
subdev = usrp.selected_subdev(u, options.rx_subdev_spec)
#u.set_rx_freq (0, -options.cordic_freq)
u.tune(0, subdev, options.cordic_freq)
u.set_pga(0, options.gain)
u.set_pga(1, options.gain)
self.u = u
self.file_sink = gr.file_sink(gr.sizeof_gr_complex, /dev/null)
self.connect(self.u, self.file_sink)
def main ():
fg = rx_graph()
fg.start()
fg.wait()
if __name__ == '__main__':
# insert this in your test code...
import os
print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
raw_input ('Press Enter to continue: ')
main ()
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Assertion Error when running gnuradio examples
Hi Michael, On 5/20/06, Michael Ford [EMAIL PROTECTED] wrote: Thomas, Yes, the firmware loaded correctly, as the frequency of the blinking lessened as I ran the oscilloscope example. As a matter of fact, the frequency never went back up again, even afte I closed the oscilloscope application. Is that a bad sign? That is fine since you need to load the firmware only if you unplugged the USRP. As for thr configuration, I'm using a tranceiver daughterboard. One of the antenna inputs is marked TX/RX, the other is simply marked RX. I'm not at the office right now, but if you need more specific information, please let me know what you need and I'll run back up there and find out - it's only a 10 minute walk away. Which daughterboards are you using? Oh, just saw it in the script. You use the RFX2400 which accepts only the frequencies in the 2.4-2.5 GHz (as was mentioned before). Thus, if you specify 101.4, it will not be able to use that daughterboard and thus the assert failes. Finally, as I said before, I'll be implementing CSMA/CA, so I'll be spending alot of my time in the gmsk2 directory. Are these examples essential to the completion of my ultimate goal? Do these assertion errors pose a significant threat to my real plan? No, the assertion errors are no problem if you specify the right frequency ;) Go and have a look in the source files where the assert fails. That might help you understand it better. Cheers, Thomas Thanks for your thoughtful/helpful reply, -Michael Ford- On 5/20/06, Thomas Schmid [EMAIL PROTECTED] wrote: Hi Michael, GNURadio is under active development. Therefore, file names can change and thus tutorials don't reflect the latest changes until they are updated. The two file syou found, std_2rxhb_2tx.rbf and std_4rx_0tx.rbf, are two different versions for the USRP firmware. the first one has two rx and to tx paths, the second one has 4 rx and no tx. When the oscilloscope run, did you see a change in the LED on your USRP, i.e., did it first blink fast, and once the oscilloscope was running it blinked slower? If, then everything is fine. If not, then follow the installation instructions here: http://www.comsec.com/wiki?UsrpInstall except that I think we are at rev4 for the firmware now, instead of rev2. The exception you get is probably because you have the wrong daughterboard in your USRP. What is the configuration you are using? Cheers, Thomas On 5/20/06, Michael Ford [EMAIL PROTECTED] wrote: Hello everyone, I'm a first time poster who's generally new to SDR as well as the gnuradio software. I've recently taken a course in communication networks and wireless networks, and this summer I'm working on using a few USRP boards to implement my own CSMA/CA protocol. However, before I get into the meat of that project, I've got to make sure that all my board setups are correct. Forgive me, this is going to be a mouthful. First things first - after visiting Dawei Shen's tutorials at the GNURadio website, I found that some of the instructions there were inconsistent with the files I got in the package - specifically tutorial number 4. I've installed the gnuradio package, and when reading the usrp tutorial, I'm told to make sure that I have a file called usrp_fpga_rev2.rbf in the /usr/local/share/usrp/rev2/ directory. (Which reminds me, if it helps, I'm running Ubuntu Dapper Drake) However, in the usrp package that I download from the gnuradio download page, I don't find that file, but instead I find two files called std_2rxhb_2tx.rbf and std_4rx_0tx.rbf. My first concern is, why don't I find the files I was told I'd find? My second concern still involves the 4th tutorial. I'm told to run usrp_oscope.py in the gr-build/gnuradio-examples/python/usrp/ directory, which I'm told will bring up an oscilloscope, which it does, so I'm assuming that's okay. Then I'm told to run wfm_rcv_gui.py [some fm frequency], which will let me hear fm signals. This is where my problem starts. First off, that file doesn't exist. So I try a file with a similar name - usrp_wfm_rcv_nogui.py -f 101.5. This gives me an assertion error, which looks like this: Using RX d'board A: Flex 2400 Rx gr_fir_ccf: using SSE gr_fir_fff: using SSE Traceback (most recent call last): File ./usrp_wfm_rcv_nogui.py, line 149, in ? fg = wfm_rx_graph() File ./usrp_wfm_rcv_nogui.py, line 105, in __init__ if not(self.set_freq(options.freq)): File ./usrp_wfm_rcv_nogui.py, line 125, in set_freq r = self.u.tune(0, self.subdev, target_freq) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 184, in tune return tune(self, chan, subdev, target_freq) File /usr/local/lib/python2.4/site-packages/gnuradio/usrp.py, line 122, in tune ok, baseband_freq = subdev.set_freq(target_freq) File /usr/local/lib/python2.4/site-packages/gnuradio/db_flexrf.py, line 174, in set_freq
[Discuss-gnuradio] Profiling GNURadio with gprof
Hi, I am trying to profile my code with gprof. I configured and compiled my modules with the --with-gprof option. Next, I run my test script which uses these modules and the script returns without any errors (I use a filesource to deliver the data to my modules). Now I should have the gmon.out file which I can analyze with gprof, but it isn't there. Any ideas what I am doing wrong? Or can someone give me some hints on how they profile their GNURadio applications? Thank you, Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MSK de-/modulation
Hi, I figured out by now that the problem is not on how I decode MSK within GNURadio, but that the signal I receive from the USRP is very strange. To verify what my test code does, I loaded the received message in octave and plotted the I and Q phases. A sample plot is added to this email. I sampled the signal at a decimation rate of 8 which should give me 8 samples/symbol for the I and Q channel. As one can see from the plot, this is not the case and there are a lot of anomalies: - First two green peaks are exactly 6 samples from each other, same for the two red peaks just after that or the first red transition from low to high. - At around 30, the red signal has a bump in it. It could be decoded as two 0 or only one. - Just before 40, the green signal has a very wide swing, again questionable if it is two or one 0 - Before 60, red swings towards low, though stops and goes back up. Again questionable if we should decode that as a 0 or did the signal just over-swing into the negative area. Could it be a problem with the RFX2400 daughter boards? Any suggestions on how to deal with this problem are appreciated. Thomas On 5/3/06, Thomas Schmid [EMAIL PROTECTED] wrote: Hi Matt, Can you give me some pointers on what I would have to tweak in the GMSK code? I read up on MSK but most demodulators I found use integration of the I and Q phases and then proper slicing. I can see how that works if I have synchronization, but I don't know how to achieve that. Here some more details on what I try to do: I try to decode a message sent out by a chipcon CC2420 in the 2.4GHz ISM band. The over all symbol rate is 2Mchip/s, thus I sample at 4MHz. Thomas On 5/2/06, Matt Ettus [EMAIL PROTECTED] wrote: Thomas Schmid wrote: Hello, Did anyone write blocks for MSK de-/modulation? I couldn't find anything in the gnuradio-core directory and I wanted to ask before I start implementing it in order to avoid duplicated work. The code for GMSK will work with some minor tweaks for plain MSK. Matt CC2420_MSK_signal.png Description: PNG image ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] MSK de-/modulation
Hi Matt, Can you give me some pointers on what I would have to tweak in the GMSK code? I read up on MSK but most demodulators I found use integration of the I and Q phases and then proper slicing. I can see how that works if I have synchronization, but I don't know how to achieve that. Here some more details on what I try to do: I try to decode a message sent out by a chipcon CC2420 in the 2.4GHz ISM band. The over all symbol rate is 2Mchip/s, thus I sample at 4MHz. Thomas On 5/2/06, Matt Ettus [EMAIL PROTECTED] wrote: Thomas Schmid wrote: Hello, Did anyone write blocks for MSK de-/modulation? I couldn't find anything in the gnuradio-core directory and I wanted to ask before I start implementing it in order to avoid duplicated work. The code for GMSK will work with some minor tweaks for plain MSK. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] MSK de-/modulation
Hello, Did anyone write blocks for MSK de-/modulation? I couldn't find anything in the gnuradio-core directory and I wanted to ask before I start implementing it in order to avoid duplicated work. Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Oscope trigger
Hi, I investigated a little bit into the usrb_oscope example and I couldn't find the implementation of the trigger. Hitting the start/stop trigger button just stop's the gui. Is that correct? Or am I missing something? Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Embedded control of USRP
Hi Lee, We are also looking into similar things, though we don't have the power constraints which will be difficult to meet. We are currently looking at a micro-atx solution with an amd geod nx processor since this one is compatible with the amd athlon mobile. this should make it easy to have a running linux system. we were first also thinking about platforms which feature a intel xscale processor, though quickly found out that it doesn't support floating points. GNU Radio makes heavy use of floating point operations. Thus it is key, especially if the platform is not very powerfull, that it supports at least hardware floating points. Also, did you consider the power consumption of the usrp? I don't know if someone measured it, but this might also be a problem for you, i.e., finding a battery which supports the usrp over a longer time. cheers, Thomas On 4/3/06, Lee Patton [EMAIL PROTECTED] wrote: Thanks for the reply, Clark. Basically, the project we're working on involves putting the USRP on a small UAV (A as in aerial not autonomous). So, weight and power consumption are key. The hydraxc looks very cool. However, I think we can go larger. And, for the first cut at a solution, we want to go for the simplest thing that works. It seems like the hydraxc might not be that. However, for a final design choice, it might work very nicely. In fact, it looks like it could be the solution, but it will take more time to get up and running than we have. I hope you will update the list as you make progress with the hydraxc. - Lee On Sun, 2006-04-02 at 09:36 -0400, Clark Pope wrote: Lee, I am very much interested in the same. Specifically, I'd like to get it on embedded Linux running off a virtex-4 FPGA. This module from hydraxc(http://www.hydraxc.com/) has a USB2.0 port and is the size of a stick of gum. Seems like one should be able to connect this to a USRP with a 100 MHz PPC linux to process at least a couple hundred kilohertz bandiwidth. The ehci driver should already exist so I guess it's just a matter of getting python to run on it and setting up a cross compiler environment for the c++ files. I have a USRP and I've ordered a hydraxc. Let me know if you want to pursue further. I don't have much time to throw at it, but I can at least try some things out to gage how much work is involved. Thanks, Clark From: Lee Patton [EMAIL PROTECTED] To: discuss-gnuradio@gnu.org Subject: [Discuss-gnuradio] Embedded control of USRP Date: Sat, 01 Apr 2006 11:33:28 -0500 I would like to control the USRP with a smaller embedded Linux computer instead of a laptop. I've don't have any experience with this sort of thing, and searching embedded in the mailing list archive didn't return much. So, I was hoping some of you pros out there might be able to point me in the direction of some products you like. I'm not sure what our requirements are exactly. However, I can say, the smaller the form factor, and the less power consumed, the better. I don't think we need too much horsepower. Our application just doesn't call for it. Any suggestions would be greatly appreciated. Thanks, - Lee ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ 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] Embedded control of USRP
Hi Eric On 4/3/06, Eric Blossom [EMAIL PROTECTED] wrote: On Mon, Apr 03, 2006 at 10:22:01AM -0700, Thomas Schmid wrote: Hi Lee, We are also looking into similar things, though we don't have the power constraints which will be difficult to meet. We are currently looking at a micro-atx solution with an amd geod nx processor since this one is compatible with the amd athlon mobile. this should make it easy to have a running linux system. Have you tried the geode nx? No, we didn't actually try the geode nx yet, but on paper they look pretty good. They are completely different from the older geode, which are less powerfull. For some more information: http://www.amd.com/us-en/ConnectivitySolutions/ProductInformation/0,,50_2330_9863_10837,00.html At least on earlier geodes the performance was pretty dismal. Perhaps the nx is a different processor than I remember. Caveat emptor. Compatible means has the same instruction set. A 486 DX66 comes pretty close to meeting that requirement ;) we were first also thinking about platforms which feature a intel xscale processor, though quickly found out that it doesn't support floating points. GNU Radio makes heavy use of floating point operations. Thus it is key, especially if the platform is not very powerfull, that it supports at least hardware floating points. Also, did you consider the power consumption of the usrp? I don't know if someone measured it, but this might also be a problem for you, i.e., finding a battery which supports the usrp over a longer time. The USRP on my bench draws about 11W. This depends of course on the daughterboads you're using, and if you've got them all running. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] various USRP GUIs freezing
cat /proc/cpuinfo usually gives you all you want to know about your processor. Thomas On 3/31/06, Matt Ettus [EMAIL PROTECTED] wrote: Erik Tollerud wrote: I suppose that would be helpful... I'm using the CVS gnuradio (as of about a week ago) running under FC5 wxPython version is 2.6 - I wasn't sure if I should pick the unicode or ANSI version, but I think I installed the ANSI (if it matters) and 256 megs of ram. As for the processor, I'm not absolutely sure - it's a Dell GX220, so It's some form of pentium III or 4, but I'm not sure how to look up processor data under linux... Start one of those CPU usage monitors, and look at what it reads when the app is running. Matt ___ 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] various USRP GUIs freezing
How high is the process load when you are running the code? I sometimes experience the same behavior, but it usually goes away after a couple of seconds. It might be an issue with ram if you have a lot of programs concurrently open. 256MB isn't much. Can you see how much memory is in usage? You can use top and free to get this information. Thomas On 3/31/06, Erik Tollerud [EMAIL PROTECTED] wrote: So it does: P4 1.8 GHz On 3/31/06, Thomas Schmid [EMAIL PROTECTED] wrote: cat /proc/cpuinfo usually gives you all you want to know about your processor. Thomas On 3/31/06, Matt Ettus [EMAIL PROTECTED] wrote: Erik Tollerud wrote: I suppose that would be helpful... I'm using the CVS gnuradio (as of about a week ago) running under FC5 wxPython version is 2.6 - I wasn't sure if I should pick the unicode or ANSI version, but I think I installed the ANSI (if it matters) and 256 megs of ram. As for the processor, I'm not absolutely sure - it's a Dell GX220, so It's some form of pentium III or 4, but I'm not sure how to look up processor data under linux... Start one of those CPU usage monitors, and look at what it reads when the app is running. Matt ___ 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] cvs+svn updates / audio / config files
Hi Eric, I tried the new scripts today. Updating of my old distribution with cvs up didn't work. It had some problems with the parallel to serial scripts which were removed and didn't want to compile. Thus, I did a fresh checkout of everything and the build worked flawlessly. This was on my debian box. Next, I will try it on Mac OS X to see if it works there too. Thomas On 3/31/06, Eric Blossom [EMAIL PROTECTED] wrote: Hi Folks, There have been a lot of updates in CVS and a few in svn over the last few days. Yes, I know that that having some of the stuff in CVS and some in subversion is a pain. Consider it an experiment that will converge to a single solution as soon as we think it's safe. Part 1: working with CVS and subversions - First, if you've still got a usrp CVS checkout around, please remove it. It's out of date. FYI, sourceforge is down again... To manually checkout the current usrp code use this command: $ svn co http://usrp.svnrepository.com/svn/usrp/trunk usrp Note the location of the space at the end of the line. You will end up with a subdirectory called usrp that contains the current (trunk) usrp code. This is equivalent to CVS HEAD. The svn repository contains fixes that aren't in the last stuff in CVS on sourceforge, so updating is highly recommended. However, to make life easier for you and me, I've also updated the tools in gr-build to handle most of the problems with having stuff in two different systems. If you've already got a gr-build checkout, just do an update: $ cd .../gr-build $ cvs -q up You'll get new versions of checkout, for-all-dirs, README and two new commands: up and status. If you're starting from scratch (probably a good idea), $ cvs -d :pserver:[EMAIL PROTECTED]:/sources/gnuradio co gr-build Then $ cd gr-build $ ./checkout -x mc4020 -x comedi -x radar [-x portaudio] will get the regular stuff Building is the same as before: $ ./for-all-dirs ../buildit [-n] Once you've got a tree checked out under gr-build, you can see what's been updated in the repositories without changing anything by: $ ./for-all-dirs ../status To update to the latest stuff use: $ ./for-all-dirs ../up These commands issue the proper cvs or svn commands depending on the directory they're run in. The for-all-dirs command now accepts two mutually exclusive options, -c and -s, that restrict the directory traversal to cvs or svn directories respectively. Part 2: configuration files and audio / portaudio - We now have a way to set user preferences using windows ini style files. At this point the preferences all have to do with audio, but that'll probably change over time. The system defaults are stored in files under PREFIX/etc/gnuradio/conf.d. You can override them on a per-user basis by creating a file called ~/.gnuradio/config.conf These are the current options and default values: - # This file contains system wide configuration data for GNU Radio. # You may override any setting here on a per-user basis by editing # ~/.gnuradio/config.conf [audio] # specify which audio module to load, or use auto to have the system # select one. Valid choices depend on your OS and which modules # you've installed, but typically include: auto, audio_alsa, # audio_oss, audio_portaudio, audio_jack, audio_windows audio_module = auto [audio_alsa] default_input_device = hw:0,0 default_output_device = hw:0,0 period_time = 0.010 # in seconds nperiods = 4# total buffering = period_time * nperiods verbose = false [audio_jack] default_input_device = gr_source default_output_device = gr_sink [audio_oss] default_input_device = /dev/dsp default_output_device = /dev/dsp latency = 0.005 # in seconds [audio_portaudio] #default_input_device = hw:0,0 #default_output_device = hw:0,0 verbose = false The items you're most likely to want to mess with are the audio module that's imported when you do from gnuradio import audio and audio module specific default values for the input and output devices. The system default: [audio] audio_module = auto means it works like it used to: we try importing audio modules until we find one that loads. If you want to force a choice, e.g. portaudio, then edit ~/.gnuradio/config.conf so that it reads: [audio] audio_module = audio_portaudio Likewise, there's a separate section for each audio module that allows you to specify the default input and output devices to use. These are used if the device_name argument passed to audio.sink(...) is missing or All audio module source and sink constructors are now
Re: [Discuss-gnuradio] Savannah
./checkout -x gr-gsm-fr-vocoder works for me... Thomas On 3/31/06, Marcus Leech [EMAIL PROTECTED] wrote: So, is Savannah hosed this evening? I'm trying to do a full checkout, and it keeps hanging in various places... ___ 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: Re: [Discuss-gnuradio] FSK with TX-RX in ISM-band 433 Mhz
Hi Luis,
I have the code to decode mica2 motes. It is not perfect yet since I
still use the correlator and I would like to move over to the gmsk way
with proper synchronisation. But it works ;)
In my case, the cc1k sends a synchronisation sequence of 0x99 to
which I synchronize the correlator. Then, I feed the found softsymbols
into the sos_packet_sink. You have to note that I use SOS as an
operating system on the mica2s. SOS adds a sync sequence just before
the message starts (tinyos does the same). The sos_packet_sink then
finds that sequence in the soft symbols which allows us to get byte
synchronisation. Then, we can look at the packet header and read the
whole message. Once parsed, the messages get added to a msg_queue.
From the message queue, they get to the registered callback.
Thomas
On 3/22/06, Luis Simoes [EMAIL PROTECTED] wrote:
On Tuesday 21 March 2006 19:15, you wrote:
On Tue, Mar 21, 2006 at 02:53:05PM +0100, Luis Simoes wrote:
Hi all,
I am a novice in gnuradio and after searching in a lot of forums I put my
USRP working and my Gnuradio running. Some FM and AM reception with and
without GUI are working fine. Now I have some problems in FSK. I try to
receive in ISM 433 MHZ some data packets with a data rate of 38.4 kbaud.
The data is manchester encoded. To do this I followed the way in the
gnuradio examples (fsk_rx.py) with a channel filter and the simple
correlator. To do the correct manchester decoding I changed the
correlator block in according to my needs and build the new block
howto_manchester_correlator. The difference between my
manchester_correlator and the simple correlator is the packit function
and the sync bytes (instead of using GRSF_SYNC I use MAN_SYNC=
0x, these are the preamble and syncronization bits).
Now when I start my application gnuradio starts receiving some data that
is written to a file, but my transmitting module is switched off and the
data is complete nonsense. When I switch on the transmitter the result is
the same. This occurs also when I ran the application with the simple
correlator. The seqno where in random order, but there should be nothing
because I didn't send anything in the simple_framer format. Now I think
the correlators are working well but the problem can be on the radio
part.
My system is working on Linux-kernel 2.6 (Linux 9.3) and the CPU is AMD
Athlon XP 2400+
I have tried to adjust all parameters with no result.
I am very grateful for any kind of help or advice.
Luis
Hi Luis,
The examples in gnuradio-examples/python/gmsk2, and the guts in
gnuradio-core/src/python/gnuradio/blksimpl/{gmsk2,gmsk2_pkt}.py are
much better starting points than the simple correlator code. They
implement proper symbol timing tracking algorithms, instead of just
locking up at the header and then drifting from there.
When trying to get a mod/demod working, we usually start with a
simulation into and out of of files, or other sinks and sources.
That way we can look at the output of the transmitter and confirm that
it looks like what we expect. Then we can sort out the receiver using
known input data.
Hope that helps,
Eric
Hi Eric,
thanks a lot. Now I am looking a bit at the code of gmsk2 and gmsk2_pkt. What
do you think about building the graph this way (without radio part):
gmsk2_demod - keep one in N - packing --- file_sink
^^^ ^^^
manchester decoding pack symbols to bytes
Is oversampling rate (spb) of 2 enough? What is the result of gr.packe_sink?
Where is the data? I have to implement a preamble detection, is this possible
with the packet_utils?
The problem is I try to design a receiver for the data format of a MICA2 mote
module and there is no access_code in the packet nor the payload length is
512 bytes.
Thanks again,
Luis
---
___
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] File plot
This might help you further: http://webpages.charter.net/cswiger/plotting.html Or if you prefere matlab/octave, Dawei Shen's website http://www.nd.edu/~dshen/GNU/ has an FAQ which gives some information. Thomas On 3/22/06, Angilberto Muniz Sb [EMAIL PROTECTED] wrote: Can anybody show how to plot from file? I can capture wbfm to file (modified capture_to_file.py -- kd7lmo) I can play fm from file (modified nfm_rcv_file.py -- kd7lmo) Now -- after a capture to file, how do I plot it ? Thank you, Angilberto. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ 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] Finally, audio_port_sink functional
I just tried it out under Mac OS X 10.4 and it works, kind of. When I try mono_tone.py, I can hear the tone, but there is some breaks in between and the console spits out UpUpUp. A sample output is at the end of the email. multi_tone.py on the other hand didn't work at all. It quit with a invalid number of channels error. I will try to have a look at that tomorrow. Anyway, great work, Robert... Thomas 22:53 [EMAIL PROTECTED]:~/gnuradio/gr-build/gnuradio-examples/python/audio$ ./mono_tone.py Number of devices found = 1 --- device #0 [ Default Input, Default Output ] Name= Built-in Audio Host API= Core Audio Max inputs = 2, Max outputs = 2 Default low input latency =0.010 Default low output latency =0.001 Default high input latency =0.010 Default high output latency =0.001 Built-in Audio is the chosen device using Core Audio as the host pUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUpUp On 3/15/06, Robert McGwier [EMAIL PROTECTED] wrote: pa_mono_tone.py and pa_multi_tone.py finally work, meaning audio_portaudio_sink is working. A real lesson was learned here. The machinery built to handle all of the connected processing routines from sinks and sources are completely capable of handling incompletes. The complicated machinery trying to make things just right on every call to the sink was just not needed and caused myriad problems.If you call a sink and tell it you have 1000 items but there is only space for 500, consume 500 and return that you consumed 500 and all is well with the world. I ran ./pa_mono_tone.py -O hw:0,0 and it chose alsa ./pa_mono_tone.py -O alsa and it chose jack (read the device list, this will need real work) ./pa_mono_tone.py -O /dev/dsp and it chose oss All worked seamlessly. pa_multi_tone.py was more problematic. It would not work with jack in any settings. On oss, it was told my soundmax had 16 channels and started up all the channels and it just seemed to work. I don't know where the other 14 went! I am quite anxious for the Mac folks to tell us if this works. After this struggle, the source will be much easier to get it going for the first time. The devices PA routines from all of these sound cards is about as rational as a screen door in a submarine. This will take some real AI to fix. Maybe I will dust off the common lisp ;-) Bob -- AMSAT VP Engineering. Member: ARRL, AMSAT-DL, TAPR, Packrats, NJQRP/AMQRP, QRP ARCI, QCWA, FRC. ARRL SDR Wrk Grp Chairman Laziness is the number one inspiration for ingenuity. Guilty as charged! ___ 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] initial gr-audio-portaudio
With help of the examples, I was able to get a little bit further. The portaudio_sink now gets initialized, but it shortly after fails with an abort trap. The cause is line 167 in audio_portaudio_sink.cc where d_portaudio_buffer_size is 0. It looks like if Pa_GetStreamInfo(d_stream)-outputLatency is already 0. Any ideas why this happens? Thomas On 3/12/06, Stephane Fillod [EMAIL PROTECTED] wrote: On Sun, Mar 12, 2006 at 07:14:15PM -0800, Thomas Schmid wrote: I tried your code on Mac OS X 10.4 and I get pretty far (everything compiles and isntalls after some hacking), but when I execute an audio example, I get this error: 19:04 [EMAIL PROTECTED]:~/gnuradio/gr-build/gnuradio-examples/python/audio$ ./dial_tone.py Traceback (most recent call last): File ./dial_tone.py, line 55, in ? my_graph().run() File ./dial_tone.py, line 48, in __init__ dst = audio.sink (sample_rate, options.audio_output) File /Users/thomas/gnuradio/gr/lib/python2.4/site-packages/gnuradio/audio_portaudio.py, line 235, in sink return _audio_portaudio.sink(*args) NotImplementedError: No matching function for overloaded 'sink' Now I am stuck. Any idea why this happens or what could be wrong? Most likely the arguments are not what is expected. Looking at gr-audio-portaudio/src/audio_portaudio.i, they should be: audio_portaudio_sink (int sampling_freq, int ok_to_block, const std::string device_name ) device_name defaults to , and ok_to_block defaults to 1. Eric, the argument order may be tweaked. Here is what I did, if anyone wants to repeat it: - install xcode 2.2 - install coreaudio sdk 1.4.3 - downloaded portaudio V19 and applied patch - fixed small -framework error on line 144 of configure.in (remove double -framework) - fixed also -framework error in Makefile.in We should definitely add automake/libtool support to portaudio. - removed the portaudio.pc directives which were added from the patch (no portaudio.pc target in the makefile, will do it manually later on. i think it is missing.) Look at my other mail. This should not be necessary if built from scratch. -- Stephane ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FFTW 3.1/ PortAudio
Just yesterday I was considering writing a gr-audio-mac block. But now I will certainly not do that. So, if you guys need mac os x testers, I am more than happy to help. Thomas On 3/12/06, Stephane Fillod [EMAIL PROTECTED] wrote: On Sun, Mar 12, 2006 at 01:29:55PM -0500, Robert McGwier wrote: [..] I am looking for a bug in my callback under portaudio on DttSP. This will enable us to cross platform DttSP on linux, bsd, mac, and wintel. I have built gr-audio-portaudio but I want to make sure that it supports gr-audio-portaudio ? I am on it. Have you done something more than what is in the current CVS repository? I rewrote something, and it's almost done (it would have been if there was no rugby game this afternoon :). In a way, the API is similar to JACK. The first samples are coming out. -- Stephane ___ 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] initial gr-audio-portaudio
Hi Stephane,
Is it possible that the portaudio patch of yours is missing the
portauido.pc target? I get errors if I want to install it, i.e., it
tells me that there is no portaudio.pc target.
Thomas
On 3/12/06, Stephane Fillod [EMAIL PROTECTED] wrote:
On Sun, Mar 12, 2006 at 02:36:21PM -0500, Robert McGwier wrote:
That is why I put the message out. It will be good to have a working
starting point.
Okay, there it is. Just checked in to gr-audio-portaudio repository.
It's somewhat working, but there's still some static in the audio
output (tested with ALSA playback, mono and stereo). Some more work
is needed.
You will need the attached patchs:
- against gnuradio-core: ot_gri_ringbuffer.patch
* src/lib/omnithread/omnithread.h: add omni_mutex::trylock
* src/lib/general/gri_ringbuffer.{cc,h},
src/lib/general/Makefile.am: new lockless ringbuffer (single
reader/single writer) taken from JACK software (GPL).
- against portaudio-V19(CVS): portaudio-pkg-config.patch
* pkg-config .pc file with proper THREAD_FLAGS
The code should be portable. I was missing the native Win32 call for
mutex_trylock, so someone will have to find it, and define
OMNI_MUTEX_TRYLOCK_IMPLEMENTATION in src/lib/omnithread/ot_nt.h,
with appropriate semantic (return value).
The gri_pa_find_device_by_name() function will have to be made more
smart, like accepting which HostApi (ALSA, JACK, ..) is to be chosen,
and which device from this API. A syntax will have to be agreed upon,
like ALSA:hw:0 or OSS:/dev/dsp1.
Have fun,
--
Stephane
___
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
