[Discuss-gnuradio] BBN 802.11 bbn_80211b_rx.py
I'm having the same problem as here http://www.ruby-forum.com/topic/87459 I got the code: cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel Then build it using bootstrap/configure/make/make install to the same prefix as gnuradio(/usr/local) I ran the python script in /adroitgrdevel/gr-bbn/src/examples/bbn_80211b_rx.py just like this: ./bbn_80211b_rx.py -f 2.437G -v -b Bits Per Encoded Sample = 8 adc frequency = 6400 decimation frequency = 16 input_rate = 400 gain = 45.0 desired freq = 243700.0 baseband frequency 243200.0 dxc frequency -500.0 Samples per data bit = 8 >>> gr_fir_ccf: using SSE 2.432G is used instead of 2.437G. Also the dxc frequency is negative. And no packets get printed out. BTW, what does that guy mean "Not sure when you updated, but we have changed the checked in code to default to 2437, and run it like this (as a NetBSD rc.d start script)", following the above link? Thanks, waiting for help -- View this message in context: http://www.nabble.com/BBN-802.11-bbn_80211b_rx.py-tp18642793p18642793.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] How to see what kind of mac/phy schemes?
http://gnuradio.org/trac/wiki/OtherCode This is what I found: BBN has written 802.11 code under funding from DARPA. To get the code: cvs -d [EMAIL PROTECTED]:/cvs/adroitgrdevel co adroitgrdevel. After GNU Radio is installed, build it using bootstrap/configure/make install to the same prefix. This has been tested on NetBSD, and reported to work on Linux. The following has been reported working * ? Mb/s transmit and receive without Barker code * 1 Mb/s receive with the Barker code Those experimenting with the code should be familiar with both GNU Radio and 802.11; this is not a good area for beginners. George Nychis wrote: > > > > yyzhuang wrote: >> Really thanks for the efforts. Surely more stuff will be added in the >> future. >> Maybe some day we can build up the entire protocol stack. >> > > I think that GR has been great for PHY development and testing. If you > follow academic research at all in the CS network realm, you'll find > that a trend has been PHY techniques to increase capacity of wireless > networks due to MAC inefficiencies. Like, Partial Packet Recovery (hi > Kyle), and in this years SIGCOMM conference "ZigZag." All of these > works have used GR because of its PHY flexibility to evaluate these > kinds of approaches, which no other open source platform has been able > to provide as well as GR. > > The MAC stuff is in the process, which I think we will then hopefully > see more research in MAC protocols done on GNU Radio. This puts it > further up the protocol stack... and then from there, we only work > further up :) > > - George > > > ___ > 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/How-to-see-what-kind-of-mac-phy-schemes--tp18580307p18640543.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
[Discuss-gnuradio] how to figure out rx flow graph for benchmark_rx_ofdm.py
Hi all, I was tracing down the gnuradio code for benchmark_rx_ofdm.py tb.start(), seems to start the scheduler in the c code and I don't know where to look next. http://gnuradio.org/trac/attachment/wiki/Wireless/gr_ofdm.ppt?format=raw has the flow graph for receiver. Do you know how I can really find out in the code where each block is located? Thank you! Mikie ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Channel measurements?
On Thu, Jul 24, 2008 at 12:30 PM, Nikhil <[EMAIL PROTECTED]> wrote: > Are you trying to measure the impulse response of the channel? If so, then > one technique would be to transmit a known pseudo-random bit sequence (an > m-sequence) using BPSK modulation at the carrier frequency of interest. The > chip rate of the sequence determines the measurement system bandwidth, while > the sequence length determines the 'dynamic range' of the measurement. > > At the receiver set the LO to the same carrier frequency as that at the > transmitter. Here you need to cross-correlate the equivalent low-pass > received signal with the known m-sequence to give the (complex) impulse > response of the channel. Any 'peaks' that exceed your definition of a > threshold noise level would be your channel coefficients in the time domain. This is actually implemented in gr-sounder. Unfortunately, the cross-correlation done on the very limited space FPGA has no frequency offset compensation, so the resulting impulse response vectors "roll" in the time domain. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Channel measurements?
On Wed, Jul 23, 2008 at 10:43 PM, Jason Uher <[EMAIL PROTECTED]> wrote: > Hey all, > > What is the best way to measure the channel for use in space-time > coding schemes using an RFX2400 board? > > As far as I know you can only get the I and Q streams out of the USRP, > and I'm not sure how you would get a set of channel coefficients. Are you trying to measure the impulse response of the channel? If so, then one technique would be to transmit a known pseudo-random bit sequence (an m-sequence) using BPSK modulation at the carrier frequency of interest. The chip rate of the sequence determines the measurement system bandwidth, while the sequence length determines the 'dynamic range' of the measurement. At the receiver set the LO to the same carrier frequency as that at the transmitter. Here you need to cross-correlate the equivalent low-pass received signal with the known m-sequence to give the (complex) impulse response of the channel. Any 'peaks' that exceed your definition of a threshold noise level would be your channel coefficients in the time domain. Nikhil > > > I am planning on using the conjugate of the measured channel to > 'reverse' the damage done by transmission. > > Sorry if I am missing something fundamental here, I've only done > channel coding in theory and am trying to get a practical > implementation going on. > > > 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
Re: [Discuss-gnuradio] FSK with RFX2400
Hi, 1) See : http://gnuradio.org/trac/wiki/UsrpFAQ http://gnuradio.org/trac/wiki/UsrpFAQ/Clocking http://gnuradio.org/trac/wiki/UsrpFAQ/Gen 2) To make nearly 0 Hz frequency shift between your TX and RX you have to use a third device Spectrum analyzer or third USRP (no need to warry about its calibration since the error will be the same for both) as follows: a) Start transmitting single tone from TX USRP (using usrp_siggen.py) b) Observe and record spectrum analyzer received tone frequency. c) Stop TX USRP. d) Start transmitting single tone from your RX USRP (using usrp_siggen.py). e) Observe spectrum analyzer received tone frequency. Adjust your transmitting frequency from your RX USRP until you get exactly the same value found in step-b 3) I appolagize about my previous post so many spelling errors!. Regards to all, Firas --- On Thu, 7/24/08, kaleem ahmad <[EMAIL PROTECTED]> wrote: From: kaleem ahmad <[EMAIL PROTECTED]> Subject: Re: [Discuss-gnuradio] FSK with RFX2400 To: Discuss-gnuradio@gnu.org Date: Thursday, July 24, 2008, 5:07 PM Hi, Can some one explain in a little bit detail about where is the clock or oscillator (on daughter board or on mother board) and how much is its resulution for RFX2400 daughter board. I tried to solve the problem of frequency mismatching by calculating the frequency shift at receiver end by using usrp_fft.py and then by adding/subtracting that frequency from RX USRP frequency as explained by Firas and Patrick. But it dont solve the problem although it improves the quality of data but because of this effort at least I understand that the problem is really some where because of frequency mismatching. So it will be helpful for me if some one either give some good document of USRP explaining clock/oscillator or just explaing the fuctionality of it by him/her self. Thanks Firas A. wrote: > > Hi Kaleem, > > Each USRP has its on reference crystal oscillator. This oscillator may > have maximum +/- 50 PPM ( Matt said the new USRPs has maximum 20 PPM) > frequency error. Lets assume the error is 10 PPM in each USRP. This means, > that at 2500 MHz (2.5 GHz) the error = 2500 * 10 = 25000 Hz = 25KHz. > > Now imagine that the first USRP has +25 KHz frequency deviation error and > the second one has - 25KHz frequency error. This means + 50 KHz frequency > mismtch between your TX and Rx Frequencies. This is probably what is > causing this high error rate that you see. > > To solve this problem you simply do : > > 1) Use usrp_siggen.py to send single tone at F1 frequency (For example, > use F1 = 2475 MHz) from your TX USRP. The best thing is F1 be the > frequency used in your FSK experiments. > > 2) With your RX USRP, start usrp_fft.py with frequency F1 and decimation= > 128 (or 256). You should see your transmitted tone but may be it's > frequency is shifted. Calculate this frequency shift. > > 3) Add/subtract this frequency shift to your RX USRP frequency tunning > function. > > 4) Now your two USRPs frequency mismatch should not be the problem. If the > errors is still there, then you have to search for another reason. > > Regards, > > Firas > > > > --- On Wed, 7/23/08, kaleem ahmad <[EMAIL PROTECTED]> wrote: > From: kaleem ahmad <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] FSK with RFX2400 > To: Discuss-gnuradio@gnu.org > Date: Wednesday, July 23, 2008, 5:23 PM > > I have just provided the information which can be helpful for you, and the > code is also attached with it and a sample received file is also there > along > with actual sent file. > > Please just scroll up and you will find my message with all this > information. Additionally OS is 'openSUSI' a favour of Linux. But if > you > still need some more info then please let me know. > > Thaks > > > > Patrick Strasser wrote: >> >> kaleem ahmad wrote am 2008-07-23 11:38: >>> Dear All, >>> >>> Can anyone also address the first part of my question aslo, I mean how > to >>> improve the quality of received data. I mean is it normal with GNU >>> Radio/USRP that we receive so currupt data or I am doing something > wrong. >>> Any suggestion please >> >> Before you wrote >> >>> after using tune >>> to set the proper ferquency I was able to run transmitter and receiver >> > sussfully. I didnt change anything else in the example. >> > The problem is data >>> which I receive is too much corrupt (lot of data errors).. >> >> Your description is not very exact. You could help us to help you with >> more information: >> >> What is your setup? OS, distribution, used version of packages, GNU >> Radio, hardware setup, used parts (cable, antennas), environment. >> What do you do? Which code do you use? >> What did you change? >> What did you get? Error messages? (add _exact_ transcripts of errors) >> What did you expect? >> Please provide exact information, code should be attached. If you >> changed something, mark the changes so helpers will find it easier. >> >> If you have rec
Re: [Discuss-gnuradio] 64MHz USRP Oscillator
By the way, could someone tell me what is the part number of the VCTCXO shipped with USRP Rev 4.5? In the bill of materials of the trunk I see "CTX286LVCT-ND", which seems to correspond to CB3LV-3C-64M in the manufacturer's nomenclature. The datasheet (http://www.ctscorp.com/components/Datasheets/008-0256-0_E.pdf) specifies +/- 50 ppm, but I have read somewhere that actually it is +/- 20 ppm. Which is the right one? Thanks, Carles. > >>> <[EMAIL PROTECTED]> wrote: > >>> > Hi All, > >>> > > >>> > I am having lots of issues with the USRP 64MHz (20ppm) on board > >>> > oscillator > >>> > which does not allow me to get exact and constant RF frequencies out > of > >>> > the > >>> > RFX900 board. I can not really fix that in SW so I was thinking about > >>> > replacing the 64MHz crystal with a more precise one. Has anybody a > >>> > suggestion of which part to use? > >>> > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] FSK with RFX2400
Hi, Can some one explain in a little bit detail about where is the clock or oscillator (on daughter board or on mother board) and how much is its resulution for RFX2400 daughter board. I tried to solve the problem of frequency mismatching by calculating the frequency shift at receiver end by using usrp_fft.py and then by adding/subtracting that frequency from RX USRP frequency as explained by Firas and Patrick. But it dont solve the problem although it improves the quality of data but because of this effort at least I understand that the problem is really some where because of frequency mismatching. So it will be helpful for me if some one either give some good document of USRP explaining clock/oscillator or just explaing the fuctionality of it by him/her self. Thanks Firas A. wrote: > > Hi Kaleem, > > Each USRP has its on reference crystal oscillator. This oscillator may > have maximum +/- 50 PPM ( Matt said the new USRPs has maximum 20 PPM) > frequency error. Lets assume the error is 10 PPM in each USRP. This means, > that at 2500 MHz (2.5 GHz) the error = 2500 * 10 = 25000 Hz = 25KHz. > > Now imagine that the first USRP has +25 KHz frequency deviation error and > the second one has - 25KHz frequency error. This means + 50 KHz frequency > mismtch between your TX and Rx Frequencies. This is probably what is > causing this high error rate that you see. > > To solve this problem you simply do : > > 1) Use usrp_siggen.py to send single tone at F1 frequency (For example, > use F1 = 2475 MHz) from your TX USRP. The best thing is F1 be the > frequency used in your FSK experiments. > > 2) With your RX USRP, start usrp_fft.py with frequency F1 and decimation= > 128 (or 256). You should see your transmitted tone but may be it's > frequency is shifted. Calculate this frequency shift. > > 3) Add/subtract this frequency shift to your RX USRP frequency tunning > function. > > 4) Now your two USRPs frequency mismatch should not be the problem. If the > errors is still there, then you have to search for another reason. > > Regards, > > Firas > > > > --- On Wed, 7/23/08, kaleem ahmad <[EMAIL PROTECTED]> wrote: > From: kaleem ahmad <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] FSK with RFX2400 > To: Discuss-gnuradio@gnu.org > Date: Wednesday, July 23, 2008, 5:23 PM > > I have just provided the information which can be helpful for you, and the > code is also attached with it and a sample received file is also there > along > with actual sent file. > > Please just scroll up and you will find my message with all this > information. Additionally OS is 'openSUSI' a favour of Linux. But if > you > still need some more info then please let me know. > > Thaks > > > > Patrick Strasser wrote: >> >> kaleem ahmad wrote am 2008-07-23 11:38: >>> Dear All, >>> >>> Can anyone also address the first part of my question aslo, I mean how > to >>> improve the quality of received data. I mean is it normal with GNU >>> Radio/USRP that we receive so currupt data or I am doing something > wrong. >>> Any suggestion please >> >> Before you wrote >> >>> after using tune >>> to set the proper ferquency I was able to run transmitter and receiver >> > sussfully. I didnt change anything else in the example. >> > The problem is data >>> which I receive is too much corrupt (lot of data errors).. >> >> Your description is not very exact. You could help us to help you with >> more information: >> >> What is your setup? OS, distribution, used version of packages, GNU >> Radio, hardware setup, used parts (cable, antennas), environment. >> What do you do? Which code do you use? >> What did you change? >> What did you get? Error messages? (add _exact_ transcripts of errors) >> What did you expect? >> Please provide exact information, code should be attached. If you >> changed something, mark the changes so helpers will find it easier. >> >> If you have recorded samples of a good and bad transmissions, send us a >> representative part of it. If you need to show more than a hand full of >> kilobytes, put them on a web server or ftp server and provide a link. >> >> Are you sure to have read the FAQ and introducing documentation? >> >> Patrick >> -- >> Engineers motto: cheap, good, fast: choose any two >> Patrick Strasser >> Student of Telematik, Techn. University Graz, Austria >> >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > > -- > View this message in context: > http://www.nabble.com/FSK-with-RFX2400-tp18587205p18611871.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 > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.or
Re: [Discuss-gnuradio] PS3 installation
On Thu, Jul 24, 2008 at 06:41:29AM -0700, Walter Snel wrote: > > Radio afficionados, > > I'm trying to compile the normal gnu-radio trunk on the PS3. Unfortunately I > run into an issue. > > I'd appreciate a pointer in the right direction. > > I used FC9, installed the cell SDK (3.0.0.1.0) and compiled the examples, so > far, so good. > > However, when compiling gnuradio I run into a compilation error in the gcell > section. It indicates "ppu_intrinsics.h" is not found. On developerworks a > similar question led to a reply indicating ppu-gcc instead of gcc should be > used. Is this a known build issue ? > > Any help is appreciated, > Walter To build on the PS3 and use gcell, you're going to need what we're calling the "cross compilation environment", even though you're not cross compiling :-) Yes, you'll need to use ppu-g++ (or grab a copy of ppu_intrinsics.h from somewhere and install it where we'll find it). Please take a look at the configure-cell-cross shell script in the top directory. To avoid waiting forever for your compilations, I suggest you cross compile from a typical x86 box. See http://gnuradio.org/trac/wiki/CrossCompilingForCell Also, at least on x86 and x86_64 we've found that Fedora 9 is undesirable because of the buggy version of g++ that they ship. Our QA code fails, and so does that of other projects. Eric > - compile error > - > /bin/sh ../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H > -I. -I../../../.. -DOMNITHREAD_POSIX=1 -I/home/wsnel/trunk/omnithread > -I/home/wsnel/trunk/mblock/src/lib -I/home/wsnel/trunk/gcell/src/include > > -I/home/wsnel/trunk/gcell/src/lib/runtime > -I/home/wsnel/trunk/gcell/src/lib/general > -I/home/wsnel/trunk/gcell/src/lib/wrapper > -I../../../../gcell/src/ibm/sync/ppu_source -g -O2 -Wall > -Woverloaded-virtual -pthread -MT gc_job_manager_impl.lo -MD -MP -MF > .deps/gc_job_manager_impl.Tpo -c -o gc_job_manager_impl.lo > gc_job_manager_impl.cc > g++ -DHAVE_CONFIG_H -I. -I../../../.. -DOMNITHREAD_POSIX=1 > -I/home/wsnel/trunk/omnithread -I/home/wsnel/trunk/mblock/src/lib > -I/home/wsnel/trunk/gcell/src/include > -I/home/wsnel/trunk/gcell/src/lib/runtime > -I/home/wsnel/trunk/gcell/src/lib/general > -I/home/wsnel/trunk/gcell/src/lib/wrapper > -I../../../../gcell/src/ibm/sync/ppu_source -g -O2 -Wall > -Woverloaded-virtual -pthread -MT gc_job_manager_impl.lo -MD -MP -MF > .deps/gc_job_manager_impl.Tpo -c gc_job_manager_impl.cc -fPIC -DPIC -o > .libs/gc_job_manager_impl.o > In file included from gc_job_manager_impl.cc:32: > ../../../../gcell/src/ibm/sync/ppu_source/atomic_dec_if_positive.h:44:28: > error: ppu_intrinsics.h: No such file or directory > In file included from > ../../../../gcell/src/ibm/sync/ppu_source/atomic_dec_if_positive.h:46, > from gc_job_manager_impl.cc:32: > - compile error > - > -- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 64MHz USRP Oscillator
Thanks everyone for your answer! I understand that some frequency offset will always be there on the Rx but I would like to minimize it. However, the main problem on my system is on the Tx path as the receiver (which I can not modify) is not having any frequency correction algorithm, so I must Tx as close as possible to the "expected" frequency. Rgds, On Wed, Jul 23, 2008 at 7:34 PM, Konstantin Tarasov <[EMAIL PROTECTED]> wrote: > You still have to remove frequency offset later on in your processing > however. > > Konstantin > > On Wed, Jul 23, 2008 at 4:26 PM, Konstantin Tarasov > <[EMAIL PROTECTED]> wrote: >> >> May be you can try FOX924, you can find this oscillator on >> www.digikey.com. It has 2.5ppm freq. stability, has a 3.3V CMOS output and >> the pinout is almost the same except one pin which is NC on this chip (# 1). >> The package is a little smaller but I am sure you can work it in there. You >> would also have to change settings on the PLL chip since highest frequencey >> of the FOX924 is 27MHz. It is only 9 bucks (if you get one of) and Digikey >> is a very fast supplier. >> >> Konstantin >> >> On Wed, Jul 23, 2008 at 4:06 PM, Brian Padalino <[EMAIL PROTECTED]> >> wrote: >>> >>> On Wed, Jul 23, 2008 at 5:30 PM, Wireless Monster >>> <[EMAIL PROTECTED]> wrote: >>> > Hi All, >>> > >>> > I am having lots of issues with the USRP 64MHz (20ppm) on board >>> > oscillator >>> > which does not allow me to get exact and constant RF frequencies out of >>> > the >>> > RFX900 board. I can not really fix that in SW so I was thinking about >>> > replacing the 64MHz crystal with a more precise one. Has anybody a >>> > suggestion of which part to use? >>> >>> These guys seem to make a whole slew of TCXO's: >>> >>>http://www.rakon.com/ >>> >>> Maybe they'll be interested in supplying you with some more precise >>> crystals? >>> >>> Brian >>> >>> >>> ___ >>> 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] 64MHz USRP Oscillator
Hi, Can some one explain in a little bit detail how this software PLL can be implemented and how this synchronization can be acheived. I am using RFX2400 and facing same problem. First I tried to solve the problem by calculating the frequency shift at receiver end by using usrp_fft.py and then by adding/subtracting that frequency from RX USRP frequency. But it dont solve the problem. and secondally I am confused why we dont discuss TX clock which is 128MHz (true...?), I mean what is the role of that. Thanks Johnathan Corgan-2 wrote: > > On Wed, Jul 23, 2008 at 3:57 PM, Chris Stankevitz <[EMAIL PROTECTED]> > wrote: > >>> I am having lots of issues with the USRP 64MHz (20ppm) on board >>> oscillator which does not allow me to get exact and constant RF >>> frequencies >>> out of the RFX900 board. I can not really fix that in SW so I was >>> thinking >>> about replacing the 64MHz crystal with a more precise one. Has anybody a >>> suggestion of which part to use? >> >> I have replaced the crystal with the 20ppm crystal, but I was unable to >> get >> an "exact and constant" frequency. I ultimately added a software PLL to >> track the clock errors. Before I upgraded my software PLL, I used a >> signal >> generator as an external clock source which worked very well. > > Just to reiterate, it's not physically possible to get "exact and > constant" frequencies in a receiver. This is not a bug. All > realistic radio receivers will have to deal with frequency and phase > offsets. Sometimes you can reduce them to the point where you can > ignore them. Other times, such as in mobile wireless or satellite > communications, Doppler effects will make any existing frequency > stability issues worse. > > Decades of research have gone into algorithms one can use on a > receiver to recover the exact carrier phase and frequency of a > received modulated waveform, resulting in many tried and true > engineering solutions. Some these, such as software PLLs as Chris > mentions, are available in GNU Radio for your use. > > I believe (ISTR) that there are 5 PPM versions of the crystal on the > USRP that fit the same solder pattern. But that still leaves you with > many KHz of potential offset and drift at 900 MHz, so unless your > chosen modulation can withstand that, you'll still need to solve the > receiver synchronization problem. > > -- > Johnathan Corgan > Corgan Enterprises LLC > http://corganenterprises.com/ > > > ___ > 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/64MHz-USRP-Oscillator-tp18621090p18632191.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
[Discuss-gnuradio] PS3 installation
Radio afficionados, I'm trying to compile the normal gnu-radio trunk on the PS3. Unfortunately I run into an issue. I'd appreciate a pointer in the right direction. I used FC9, installed the cell SDK (3.0.0.1.0) and compiled the examples, so far, so good. However, when compiling gnuradio I run into a compilation error in the gcell section. It indicates "ppu_intrinsics.h" is not found. On developerworks a similar question led to a reply indicating ppu-gcc instead of gcc should be used. Is this a known build issue ? Any help is appreciated, Walter - compile error - /bin/sh ../../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../.. -DOMNITHREAD_POSIX=1 -I/home/wsnel/trunk/omnithread -I/home/wsnel/trunk/mblock/src/lib -I/home/wsnel/trunk/gcell/src/include -I/home/wsnel/trunk/gcell/src/lib/runtime -I/home/wsnel/trunk/gcell/src/lib/general -I/home/wsnel/trunk/gcell/src/lib/wrapper -I../../../../gcell/src/ibm/sync/ppu_source -g -O2 -Wall -Woverloaded-virtual -pthread -MT gc_job_manager_impl.lo -MD -MP -MF .deps/gc_job_manager_impl.Tpo -c -o gc_job_manager_impl.lo gc_job_manager_impl.cc g++ -DHAVE_CONFIG_H -I. -I../../../.. -DOMNITHREAD_POSIX=1 -I/home/wsnel/trunk/omnithread -I/home/wsnel/trunk/mblock/src/lib -I/home/wsnel/trunk/gcell/src/include -I/home/wsnel/trunk/gcell/src/lib/runtime -I/home/wsnel/trunk/gcell/src/lib/general -I/home/wsnel/trunk/gcell/src/lib/wrapper -I../../../../gcell/src/ibm/sync/ppu_source -g -O2 -Wall -Woverloaded-virtual -pthread -MT gc_job_manager_impl.lo -MD -MP -MF .deps/gc_job_manager_impl.Tpo -c gc_job_manager_impl.cc -fPIC -DPIC -o .libs/gc_job_manager_impl.o In file included from gc_job_manager_impl.cc:32: ../../../../gcell/src/ibm/sync/ppu_source/atomic_dec_if_positive.h:44:28: error: ppu_intrinsics.h: No such file or directory In file included from ../../../../gcell/src/ibm/sync/ppu_source/atomic_dec_if_positive.h:46, from gc_job_manager_impl.cc:32: - compile error - -- View this message in context: http://www.nabble.com/Re%3A-gcell-status--tp18038915p18578479.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
[Discuss-gnuradio] FPGA processing
Hi Gnu Radio People, I played a little with the Fedora8/64 gnuradio without currently having money to get the Hardware Unit, so I'd hope I could use my existing spartan 3(e) boards for the main connection with a PC, but that currently seems not to be the case. Of course the AD (DA) electronics are also required. I'm into sound synthesis and fpga use, like www.theover.org/Synth www.theover.org/Fpgasynth and I was wondering about the available possiblities to use fpga blocks, instead of the PC based software blocks for instance to do basic reception or data processing. Preferably with block-like (I made http://wiki.tcl.tk/bwise) programming tools, like the Gr companion? Kind greetings, Theo Verelst www.theover.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
