Re: [Discuss-gnuradio] Contribution: ofdm system
Hello all, Our team also implemented a MIMO-OFDM platform in the past few months. The system parameters are like LTE. But it is not fully in GNU Radio framework, so it's not suitable to be imported. One paper introducing this platform will be published in SDR07 Tech Conference. Unfortunately I cannot go to attend this conference. :( Otherwise maybe I could meet Eric or Ettus to thank you for such good USRP and GNU RADIO. Best wishes HUANG Lin 2007/10/19, Dominik Auras <[EMAIL PROTECTED]>: > > Hello, > > In the last months, we have developed an ofdm system using your gnuradio > architecture as part of a research on dynamic resource allocation. Now we > like to contribute parts of our code to the gnuradio project. We think > that > it will be useful to you since it partially employs more advanced > techniques > than in your example. If you like it, I suggest to add it as an > alternative > ofdm system. > > We are using this system on USRPs at revision 4 with daughterboards > RFX2400. > It is tested, stable and has a good performance in BER and SNR. All > hierarchical blocks are using the new style blocks. > > Here are some facts about the receiver and transmitter: > > - preamble based timing synchronization > The modified Schmidl & Cox algorithm is used to position the sampling > window > at the first preamble. Only coarse timing synchronization is done. > > - preamble based frequency offset synchronization > Before FFT, the frequency offset, divided into a fractional part and an > integer part, will be estimated based on the S&C preamble (also used for > timing sync) and a second preamble. Therefore both fine and coarse > frequency > offset estimation is performed. > > - preamble based channel estimation > The second preamble, used for frequency offset estimation, will be > exploited > to give an estimate of the current channel state. The fine timing > synchronization is absorbed into the channel transfer function (as phase > rotation), i.e. compensated for at this place. > > - pilot tone based sampling frequency offset estimation > We insert 8 pilot tones (or subcarriers) to ofdm data blocks. The sampling > frequency offset (as phase rotation) and the residual carrier frequency > offset is estimated and compensated for. Without SFO compensation, we > observed a severe drop of SNIR using the USRPs, especially between two > different charges we bought. The current algorithm acquires and tracks the > SFO and RCFO within an ofdm frame. > > - flexible channel estimator > The estimator block can easily use several ofdm blocks to estimate the > channel transfer function. It will output both the inverse ctf to be fed > to > the equalizer and the ctf. It uses a simple zero-forcing criteria. The > known > blocks' positions within the ofdm frame can be freely chosen. For example, > we used a midamble in our experiments to mitigate some special problems. > > - flexible mapper/demapper > We created a new ofdm mapper/demapper that allows to assign different > signal > constellations on different subcarriers. This can be either static or > dynamically changed. > > Please let me know if you want to have more details. > > If you accept our contribution, I will port the system to use your packet > utils and to have it behave like your systems. Please note that the system > has a modular design and uses simple gnuradio blocks if possible and > useful. > > Additionally, I personally want to thank you for your great work at the > gnuradio project. It is definitely one of the best SDR environments. > > Greetings, > Dominik Auras > > Chair of Theoretical Information Technology > RWTH Aachen University > http://www.ti.rwth-aachen.de > > > ___ > 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] enabling RX-A & RX-B on single daughterboard
Hey all, On the basic daughterboards, if I connect two coax cables to TX-A and TX-B on a single daughterboard and transmit, I can view the transmission using an oscope on both connectors. In other words, it doesn't matter which of the two ports I connect to. However, if I fire up the GNU Radio oscope with a BasicRX, I must connect either TX-A or TX-B to RX-A. Is RX-B disabled by default? Is it possible to enable RX-A and RX-B? Thanks! George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] using usrp_fft.py result
Is there a way to save the output data of usrp_fft.py? For example If I want to feed the output of the usrp_fft.py (i. e. the data it plots) into a variable every unit time. How can I do that? -- View this message in context: http://www.nabble.com/using-usrp_fft.py-result-tf4674883.html#a13356566 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] GNU Radio 3.1.0 Release Tarballs Available
GNU Radio stable release 3.1.0 is now available for download: http://gnuradio.org/releases/gnuradio/gnuradio-3.1.0.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.1.0.tar.gz Binary installation packages for Ubuntu 32-bit and 64-bit systems are documented at: http://gnuradio.org/trac/wiki/DebianPackages Release 3.1.0 is based on a snapshot of the current development trunk, with a few incomplete or buggy portions removed. Changes on this stable branch are documented at: http://gnuradio.org/trac/wiki/Release3.1Branch If you want to check out a Subversion branch that only includes updates along this series, use: $ svn co http://gnuradio.org/svn/gnuradio/branches/releases/3.1 While 3.1.0 is based on the current development trunk that many are familiar with, it has been a full year since the last stable branch was cleaved from the trunk. The changes between then and now are many and varied; here are some highlights: * New hierarchical flow graph code, allowing arbitrarily nested flow graphs and runtime flow graph reconfiguration (gr.top_block, gr.hier_block2). All the gnuradio-examples programs have been ported to this new way of doing things, to illustrate the differences in syntax. (The stable branch, however, also maintains the existing gr.flow_graph() based API.) * New top-level components - gr-atsc (ATSC TV receiver, not real-time) - gr-comedi (drivers for Linux Control and Measurement Interfaces) - gr-pager (Wideband multi-channel FLEX pager receiver/decoder) - gr-radar-mono (Monostatic Active Radar with up to 32 MHz LFM chirps) - gr-sounder (Channel sounder for up to 32 MHz wide passband channels) - gr-utils (Commonly used USRP and other scripts moved from examples) * Streamlined build and installation - Binary packaging for Debian/Ubuntu and similar systems - Reduced memory footprint for compilation * Many, many bug fixes and updates all over the tree (documentation volunteers welcomed...) This new stable branch will be maintained such that existing Python and C++ code based upon it will not break due to updates in the series. New releases in this series will have backported bug fixes and new features added. However, no changes will be made that (intentionally!) result in existing user code not functioning. If it sounds like this means we *will* be making such changes on the trunk, you are absolutely right. Several features targeted for the 3.2 stable branch will require deep surgery and will break user code that doesn't keep up: * Removal of gr.flow_graph(), leaving only gr.top_block() added in 3.1 * Removal of gr.hier_block(), leaving only gr.hier_block2() added in 3.1 * In-band signaling for USRP communications * M-blocks, a new message/packet-oriented hierarchical flow model * Pure C++ GNU Radio applications, with no Python involved * Scheduler changes to better scale to multi-core CPUs Install and develop for the 3.1 stable branch if you want to avoid any issues, or work off the trunk and enjoy the ride. -- Johnathan Corgan Corgan Enterprises LLC http://corganenterprises.com ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] BBN module
Hi everyone, I am going to use BBN code on IEEE802.11b. But these codes need to import a module named bbn from gnuradio package. My gnuradio has not this module. Where can I find it and how I can add it to my gnuradio package. Thanks hamed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mux settings...
On Mon, Oct 22, 2007 at 05:59:58PM -0700, Hans Glitsch wrote: > Hello, > > I may be having similar problems. I'm using 2 basic RX boards and I want > to receive four complex signals. I seem to be losing the complex part of > the first signal. I was using a mux of 0xf3f2f1f0, and after seeing your > message, I tried 0x32103210. Both of them show the same problem with the > first signal. > > I have tried swapping the usrp parts to see if it was a hardware problem, > but the problem persists. > > Thanks for your help, > Hans For the Basic Rx, 0xf3f2f1f0 is the correct setting to feed 4 separate signals into the I inputs of 4 DDCs, with zeros fed to the Q inputs. To use 4 channels, you must use the std_4rx_0tx.rbf fpga image. If you use the std_4rx_0tx.rbf image, the decimation rate must be <= 128. If you need more decimation, you must do it in software. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mux settings...
Hello, I may be having similar problems. I'm using 2 basic RX boards and I want to receive four complex signals. I seem to be losing the complex part of the first signal. I was using a mux of 0xf3f2f1f0, and after seeing your message, I tried 0x32103210. Both of them show the same problem with the first signal. I have tried swapping the usrp parts to see if it was a hardware problem, but the problem persists. Thanks for your help, Hans - Original Message - From: "Eric Blossom" <[EMAIL PROTECTED]> To: "Jared Jensen" <[EMAIL PROTECTED]> Cc: Sent: Monday, October 22, 2007 5:15 PM Subject: Re: [Discuss-gnuradio] Mux settings... On Mon, Oct 22, 2007 at 05:13:33PM -0400, Jared Jensen wrote: What are the proper mux settings for one DBSRX in RXA and one DBSRX in RXB? When I used a single DBSRX in RXA 0x0010 worked well. But now I want Channel 0 to be RXA, and Channel 1 to be RXB both of which are I and Q, and not swapped. So far anything other than 0x32103210 or 0x0010 produces dirty output with random-looking noise in the data. Jared If you're using a single channel, usrp.determine_rx_mux_value will get you the right answer, regardless of the type of daughterboard. On the DBSRX, 0x3210 (or for that matter 0x32103210) will set you up with side A routed to channel 0 and side B routed to channel 1. See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams and http://gnuradio.org/doc/doxygen/classusrp__standard__rx.html Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.15.3/1081 - Release Date: 10/19/2007 5:41 PM ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] the in-band timestamp
On Mon, Oct 22, 2007 at 07:40:40PM -0400, George Nychis wrote: > Okay, Brian brought this up to me in an off-list discussion that we > think needs to be discussed about the current timestamp generation. > > Referring to: > http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/inband_lib/rx_buffer_inband.v#L37 > > The current timestamp runs at the decimated rate, when we're tossing it > up for discussion if it should be driven from the free running 64MHz clock. > > Leo and I are in the middle of implementing/debugging some other > functionality that I want to finish before touching this, but it's worth > discussion ahead of time. > The Rx timestamp should be based on the 64MHz clock, and should be logically inserted at the tail end of the Rx DSP pipeline (the end nearest the host). With regard to the Tx path, Matt & I came to the conclusion that the time clock should be the 64MHz clock, and that the time check should be at the head of the DSP pipeline. That is, after the FIFO, but before the signal processing. This does imply that the host needs to know the pipeline delay, group delay, and needs to provide padding for the head and tail of a burst. After quite a bit of face-to-face discussion, this seemed to be the only strategy that made sense. Matt, if I got any of this wrong, please chime in. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Mux settings...
Thanks. That means I have issues. :) I am trying to use 2 channels, with a mux setting of 0x32103210. I have a DBSRX on RXA and another one on RXB. I have no TX. When I do a... nRead = myDev->read(arr, USB_BUF_SIZE, &bOverrun); I get perfect data from one channel. (i.e. I_a = arr[0], Q_a = arr[1], I_a = arr[4], Q_a = arr[5] and so on.) But I get complete junk on the second channel. (I_a = arr[2], Q_a = arr[3], I_a = arr[6], Q_a = arr[7]). I've swapped the boards (slot A to slot B and vice versa), and they both seem to work fine. I've run usrp_fft.py -R B and -R A and it works in both cases, but I can't find anything to test both at once. But regardless, I don't think it's the USRP's fault. It think it's mine unfortunately. I'm just out of ideas where to look. I've been debugging this for a couple of days now. Ugh. :) Any thoughts? Jared > Date: Mon, 22 Oct 2007 17:15:08 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] Mux settings... > > On Mon, Oct 22, 2007 at 05:13:33PM -0400, Jared Jensen wrote: > > > > > What are the proper mux settings for one DBSRX in RXA and one DBSRX > > in RXB? When I used a single DBSRX in RXA 0x0010 worked well. > > But now I want Channel 0 to be RXA, and Channel 1 to be RXB both of > > which are I and Q, and not swapped. > > > > So far anything other than 0x32103210 or 0x0010 produces dirty > > output with random-looking noise in the data. > > > > Jared > > If you're using a single channel, usrp.determine_rx_mux_value will get you > the right answer, regardless of the type of daughterboard. > > On the DBSRX, 0x3210 (or for that matter 0x32103210) will set you > up with side A routed to channel 0 and side B routed to channel 1. > > See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams > and http://gnuradio.org/doc/doxygen/classusrp__standard__rx.html > > Eric > _ Help yourself to FREE treats served up daily at the Messenger Café. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Mux settings...
On Mon, Oct 22, 2007 at 05:13:33PM -0400, Jared Jensen wrote: > > What are the proper mux settings for one DBSRX in RXA and one DBSRX > in RXB? When I used a single DBSRX in RXA 0x0010 worked well. > But now I want Channel 0 to be RXA, and Channel 1 to be RXB both of > which are I and Q, and not swapped. > > So far anything other than 0x32103210 or 0x0010 produces dirty > output with random-looking noise in the data. > > Jared If you're using a single channel, usrp.determine_rx_mux_value will get you the right answer, regardless of the type of daughterboard. On the DBSRX, 0x3210 (or for that matter 0x32103210) will set you up with side A routed to channel 0 and side B routed to channel 1. See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams and http://gnuradio.org/doc/doxygen/classusrp__standard__rx.html Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Release 3.1.0rc0 now available; New Debian package repository
On Sun, Oct 21, 2007 at 01:16:00PM -0700, Jan Schiefer wrote: > Oh, and one more question: I noticed a new dependency on numpy. I have > lost track of this issue, is Numeric now no longer required? > > Thanks, > Jan Correct. The Numeric dependency has been replace by a numpy dependency. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] running a gmsk test
On Sun, Oct 21, 2007 at 08:47:59AM -0400, George Nychis wrote: > I'm not sure where the gmsk test went in GNU Radio, I tried following > the log and commits. So, I grabbed a gmsk test from here: > http://noether.uoregon.edu/~jl/gmsk/ > > Just trying to run something simple, I run it from the blksimpl > directory like this: > [EMAIL > PROTECTED]:~/school/gr/gmsk/gnuradio-core/src/python/gnuradio/blksimpl$ > ./gmsk-test.py -f payload.dat > sps:8 > symbol_rate:270833.33 > sample_rate:216.7 > p_size: 1024 > >>> gr_fir_fff: using SSE > bits per symbol = 1 > Gaussian filter bt = 270833.33 > Modulation logging turned on. > python: gri_mmse_fir_interpolator.cc:67: float > gri_mmse_fir_interpolator::interpolate(const float*, float) const: > Assertion `imu <= NSTEPS' failed. > > Given that the test program is two years old now, I'm sure something has > changed. But does an up to date gmsk test program still exist that does > not need the USRP? I found the DECT example, but that's USRP based. > > Thanks! > George George, See gnuradio-examples/python/digital/benchmark_loopback.py Try the --help option. To select gmsk, use -m gmsk Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] the in-band timestamp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 My 2c: I imagine that futuristic uses of the USRP (such as the ones for which you're explicitly redo-ing the stack) involve dynamically changing the decimation on the fly. Drive it off the absolute clock to keep some sense of meaning. - -Dan George Nychis wrote: > Okay, Brian brought this up to me in an off-list discussion that we > think needs to be discussed about the current timestamp generation. > > Referring to: > http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/inband_lib/rx_buffer_inband.v#L37 > > > The current timestamp runs at the decimated rate, when we're tossing it > up for discussion if it should be driven from the free running 64MHz clock. > > Leo and I are in the middle of implementing/debugging some other > functionality that I want to finish before touching this, but it's worth > discussion ahead of time. > > - George > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHHTX1y9GYuuMoUJ4RAs9UAJ0Vfz9vvGy5AdaiL0XphP721hodIgCeINaV 480gAWFq0nHaDTp5v8gRcEw= =ioAZ -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] the in-band timestamp
Okay, Brian brought this up to me in an off-list discussion that we think needs to be discussed about the current timestamp generation. Referring to: http://gnuradio.org/trac/browser/gnuradio/branches/features/inband-usb/usrp/fpga/inband_lib/rx_buffer_inband.v#L37 The current timestamp runs at the decimated rate, when we're tossing it up for discussion if it should be driven from the free running 64MHz clock. Leo and I are in the middle of implementing/debugging some other functionality that I want to finish before touching this, but it's worth discussion ahead of time. - George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multi-channel I/Q buffer format...
On Mon, Oct 22, 2007 at 02:23:44PM -0400, Jared Jensen wrote: > > I'm getting some strange behavior when I use two DBSRX boards with my USRP. > I just wanted to vet some of my assumptions as I'm debugging. I'm assuming > that the data comes across the USB bus as follows > > I_A/Q_A/I_B/Q_B/I_A/Q_A/ > > Is that correct? i.e. do we get I/Q of one board followed by I/Q of the > other board? And they come across as 2-byte samples for each I and 2-byte > samples for each Q? > > So... > > I_A_16bits/Q_A_16bits/I_B_16bits/Q_B_16bits/... and so on? > > Again, I'm just trying to make sure I don't waste time debugging elsewhere. > Thanks > > Jared > Yes, you've got it right. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] ask for help about installing gnu-radio
Give a 'sudo ldconfig' a try. - George [EMAIL PROTECTED] wrote: Hello, After installing the development package of gnu-radio, I got the following ImportError when running qa_cvsd_vocoder.py in gr-cvsd-vocoder. Actually, I met similar problems of running python code in other folders. But the libgromnithread.so actually exists the /usr/local/lib. I had added this path to the PATH environment variable. I am not sure if my installing is correct. thanks a lot. nannan Traceback (most recent call last): File "./qa_cvsd_vocoder.py", line 23, in from gnuradio import gr, gr_unittest, blks2 File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 27, in from gnuradio_swig_python import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 23, in from gnuradio_swig_py_runtime import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 6, in import _gnuradio_swig_py_runtime ImportError: libgromnithread.so.0: cannot open shared object file: No such file or directory ___ 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] Has Anyone Used Purify with GNU Radio?
On Fri, Oct 19, 2007 at 09:39:10PM +0800, Jeremy Chew wrote: > > Does anyone have experience getting Purify working with GNU Radio, or is > anyone able to shed some light? > This is a free software list. We don't provide customer support for proprietary software. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] ask for help about installing gnu-radio
Hello, After installing the development package of gnu-radio, I got the following ImportError when running qa_cvsd_vocoder.py in gr-cvsd-vocoder. Actually, I met similar problems of running python code in other folders. But the libgromnithread.so actually exists the /usr/local/lib. I had added this path to the PATH environment variable. I am not sure if my installing is correct. thanks a lot. nannan Traceback (most recent call last): File "./qa_cvsd_vocoder.py", line 23, in from gnuradio import gr, gr_unittest, blks2 File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/__init__.py", line 27, in from gnuradio_swig_python import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_python.py", line 23, in from gnuradio_swig_py_runtime import * File "/usr/local/lib/python2.5/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 6, in import _gnuradio_swig_py_runtime ImportError: libgromnithread.so.0: cannot open shared object file: No such file or directory ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Mux settings...
What are the proper mux settings for one DBSRX in RXA and one DBSRX in RXB? When I used a single DBSRX in RXA 0x0010 worked well. But now I want Channel 0 to be RXA, and Channel 1 to be RXB both of which are I and Q, and not swapped. So far anything other than 0x32103210 or 0x0010 produces dirty output with random-looking noise in the data. Jared _ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Decimate by 2 possible?
Brian, Thanks for your response. > What is your target symbol rate? My target symbol rate is 10.76 MHZ (8-vsb ATSC symbol rate). I need only 2x of this symbol rate, i.e 21.52 Mhz to do down stream processing. >Is there a reason you want to play directly with 32Msps? Only for troubleshooting interpolation-algorithm problems on the downstream board. If I send a lower rate e.g 8Msps then there is a need for interpolation first and it appears that there is a bug in the algorithm for cubic interpolation method on the downstream board that causes sampling offsets. So it would be nice if there was only downsampling involved in getting to 21.52 Mhz. > Maybe it would be better if you decimated to 1x or 2x the symbol rate > and then processed that data on your other board? Yes, you are right. Ultimately I should only send the decimated data. If I use both the CIC and HBF then the lowest combined decimation rate is 8, which gives me 8 Msps output. I might avoid the HBF for now and get a decimation of 4 in the CIC. I found from an earlier post that the file 4rx_0tx.rbf has only CIC and no HBF. Do you know how this file can be generated? I need to start at the toplevel in order to make connections to the debug IO pins. > What do you think? Is this more plausible of a scenario for you? This definitely makes good sense. Thanks for the suggestions! Nirali Patel ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: benchmark_ofdm_rx not working
On 10/22/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote: > > Send Discuss-gnuradio mailing list submissions to > discuss-gnuradio@gnu.org > > -- > > Message: 6 > Date: Mon, 22 Oct 2007 10:43:50 +0100 > From: Tom Rondeau <[EMAIL PROTECTED]> > Subject: Re: [Discuss-gnuradio] benchmark_ofdm_rx not working > To: GNU Radio Discuss > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Archana Ragothaman wrote: > > Hello, > > > > I am using two USRPs rev 4 and two RFX2400. I am basically trying to > > make the USRPs communicate with each other using the > > benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. The commands I > > am executing are > > > > ./benchmark_ofdm_tx.py -f2.4e9 -T A (at one USRP connected to laptop) > > > > ./benchmark_ofdm_rx.py -f2.4e9 -R A (at the other USRP connected to > > another laptop) > > > > The benchmark_ofdm_tx.py script is working as I can see the packet > > number displayed(I wrote a print pktno in the script) > > > > However the benchmark_ofdm_rx.py script does not give any output. I > > don't think the rx_callback function is being executed(as the packets > > are printed in that function). > > > > Can anyone please help me out and give suggestions as to what the > > problem could be? > > > > Thank you. > > First, try running the benchmark_ofdm_tx on one side and tht usrp_fft to > display the received power at the receiver. What does this look like? > > The problem is likely that you are not transmitting enough power. There > is a --tx-amplitude flag to adjust this. Set it to 2000 - 4000. > > Tom Hello, I increased the amplitude to around 3000 on the tx usrp. I also ran the usrp_fft.py on the rx side. I could observe the spectrum of the rx signal which was around 30 dB. So I know that the rx side usrp is able to receive the packets trasnmitted. However, now when I run the benchmark_ofdm_rx.py script on the rx side, I do not see any output. The output that I get is After rx_callback( ) definition >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE INIT Completed Successfully fg=usrp_graph() called (comment added for debugging) gr_buffer::allocate_buffer: warning: tried to allocate 20 items of size 1600. Due to alignment requirements 64 were allocated. If this isn't OK, consider padding your structure to a power-of-two bytes. On this platform, our allocation granularity is 4096 bytes. fg.start() (comment added for debugging) Inside RX _Callback pktno (comment added for debugging) ok: Falsepktno: 58626n_rcvd: 1 n_right: 0 Only one packet is received after a long time. Could you suggest as to why the output is not displayed? - - Archana Ragothaman Master's in Telecommunications Graduate Research Assistant MIND Lab,UMIACS University of Maryland, College Park Email: [EMAIL PROTECTED] Phone: 240-422-7887 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Decimate by 2 possible?
On 10/22/07, Nirali Patel <[EMAIL PROTECTED]> wrote: > Hi, > I am using the TV_RX and USRP to capture the 64 Msps data from the A/D > converter and send that to another downstream board for processing. I am > connecting the signal from the ADC to the debug IO pins of the FPGA to get > to the 16 io_rx[] pins of Basic RX. However, my board-to-board > interconnection turned out to have a bandwidth limitation of 50 MHz so I can > no longer hope to send 64 Msps raw data from the ADC over the interconnect > bus. The next best thing would be to decimate by a factor of 2 and then > route the 32 Msps data to the debug pins. I understand the the CIC has a > decimation range of [4,5,6,…128] and the HBF decimates by a factor of 2. Is > there a way to get an overall decimation of just 2 by possibly bypassing the > CIC and using only the HBF? If this sounds like a dumb question then, what > would be the best way to get 32 Msps over to the Basic RX card using what's > already in the FPGA? > > Thanks in advance for any suggestions. Is there a reason you want to play directly with 32Msps? What is your target symbol rate? Do you need all that bandwidth, or do you just need a portion of it? Usually when there is a bandwidth limitation of 50MHz, and since a square wave is composed of all odd harmonics of the fundamental, then 32MHz would really need a couple odd harmonics to get through pretty reliably, shouldn't it? Maybe it would be better if you decimated to 1x or 2x the symbol rate and then processed that data on your other board? You can change the halfband coefficients to make it a symbol matched filter instead of a generic halfband filter if you'd like. What do you think? Is this more plausible of a scenario for you? Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Multi-channel I/Q buffer format...
I'm getting some strange behavior when I use two DBSRX boards with my USRP. I just wanted to vet some of my assumptions as I'm debugging. I'm assuming that the data comes across the USB bus as follows I_A/Q_A/I_B/Q_B/I_A/Q_A/ Is that correct? i.e. do we get I/Q of one board followed by I/Q of the other board? And they come across as 2-byte samples for each I and 2-byte samples for each Q? So... I_A_16bits/Q_A_16bits/I_B_16bits/Q_B_16bits/... and so on? Again, I'm just trying to make sure I don't waste time debugging elsewhere. Thanks Jared _ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Decimate by 2 possible?
Hi, I am using the TV_RX and USRP to capture the 64 Msps data from the A/D converter and send that to another downstream board for processing. I am connecting the signal from the ADC to the debug IO pins of the FPGA to get to the 16 io_rx[] pins of Basic RX. However, my board-to-board interconnection turned out to have a bandwidth limitation of 50 MHz so I can no longer hope to send 64 Msps raw data from the ADC over the interconnect bus. The next best thing would be to decimate by a factor of 2 and then route the 32 Msps data to the debug pins. I understand the the CIC has a decimation range of [4,5,6,.128] and the HBF decimates by a factor of 2. Is there a way to get an overall decimation of just 2 by possibly bypassing the CIC and using only the HBF? If this sounds like a dumb question then, what would be the best way to get 32 Msps over to the Basic RX card using what's already in the FPGA? Thanks in advance for any suggestions. Nirali ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WiFi b/g
Hi Hamed, Yes, BBN coded an 802.11 receiver. I have personally not gotten around to running it yet, but just from reading the list others have been able to decode most 1 or 2Mbps packets, and nothing above that. This is all all the physical layer, no MAC functionality. Here's a good first read: http://mail-index.netbsd.org/tech-net/2006/08/07/.html There are plenty of people who have run it on the list, and definitely people at BBN who are active on the list... so someone else will likely pop in with more info for you. :) - George Mohammad Hamed Firooz wrote: Hi Has any Wifi (802.11) b or g receiver model been implemented in GNU Radio? thanks hamed ___ 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] WiFi b/g
Hi Has any Wifi (802.11) b or g receiver model been implemented in GNU Radio? thanks hamed ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] benchmark_ofdm_rx not working
Archana Ragothaman wrote: Hello, I am using two USRPs rev 4 and two RFX2400. I am basically trying to make the USRPs communicate with each other using the benchmark_ofdm_tx.py and benchmark_ofdm_rx.py scripts. The commands I am executing are ./benchmark_ofdm_tx.py -f2.4e9 -T A (at one USRP connected to laptop) ./benchmark_ofdm_rx.py -f2.4e9 -R A (at the other USRP connected to another laptop) The benchmark_ofdm_tx.py script is working as I can see the packet number displayed(I wrote a print pktno in the script) However the benchmark_ofdm_rx.py script does not give any output. I don't think the rx_callback function is being executed(as the packets are printed in that function). Can anyone please help me out and give suggestions as to what the problem could be? Thank you. First, try running the benchmark_ofdm_tx on one side and tht usrp_fft to display the received power at the receiver. What does this look like? The problem is likely that you are not transmitting enough power. There is a --tx-amplitude flag to adjust this. Set it to 2000 - 4000. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] file transmitter
I think this has been answered in the past, but I couldn't find the answer- is there a pre-done script to transmit a raw data file directly as samples? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
