Re: [Discuss-gnuradio] Problem with sinc pulse transmission using RFX2400
S. Faisal A. Shah wrote: > Hi, > > I am using a USRP with RFX2400 to transmit a sinc pulse using > usrp_siggen.py routine and my own sinc pulse generator that is a > modified version of gr_sig_source_c.cc. I am using a separate USRP > with RFX2400 to receive the pulse using usrp_rx_cfile.py. The > transmitter and receiver are one meter apart. > > First, I tried to put the sinc pulse on the "I" branch (real) and > zeros on the "Q" branch. But the amplitude of the received pulse train > is time varying. In fact, the received pulse train seems to be > amplitude modulated by a low frequency signal (in KHz). If you put a signal on I and nothing on Q, then you SHOULD see a time-varying amplitude in the output. Do the math in octave and you'll see. > Second I tried > to put the same sinc pulse on both I and Q and had the same problem. > Again, do the math. The same signal sent to both I and Q will always result in what you are seeing. > For curiosity, I repeated the experiment by putting few cycles of sine > wave on both I and Q and encountered the same problem of amplitude > variation. Finally, I tried using a truncated sine wave on I and > cosine on Q and it works perfectly fine. Exactly. Sine on I and cosine on Q (or vice versa) will give you a single frequency tone at the output, because it is what is known as a complex sinusoid. > I am having difficulty in > understanding the problem. Does this mean that I can only put sine and > cosine on I and Q, respectively? Is it possible to transmit only > single component not quadrature using RFX 2400? I am thinking to set > MUX to disable the Q branch at the transmitter and receiver. Any help > will be highly appreciated. > You need to generate analytic signals, which means they have both I and Q components. This has nothing to do with the RFX2400 and everything to do with the fact that the USRP uses IQ signals. This in no way a limitation on the capabilities, you just need to understand analytic signals. There are many DSP books which cover the concepts, and if you look back through the list archives you will find a couple of long expositions by me on what IQ signals are. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] callbacks for the channel model
The blks.channel_model block would be more useful to GRC if it had some callbacks (functions to set the input parameters at runtime). So, for example, one could vary the noise voltage while the flow graph is running. I attached a diff with 3 callbacks added. Hopefully, it will make its way into blks2. -Josh diff -Naur gnuradio_old/trunk/gnuradio-core/src/python/gnuradio/blksimpl/channel_model.py gnuradio_new/trunk/gnuradio-core/src/python/gnuradio/blksimpl/channel_model.py --- gnuradio_old/trunk/gnuradio-core/src/python/gnuradio/blksimpl/channel_model.py 2007-08-30 01:17:33.0 -0400 +++ gnuradio_new/trunk/gnuradio-core/src/python/gnuradio/blksimpl/channel_model.py 2007-08-30 01:23:34.0 -0400 @@ -48,3 +48,12 @@ fg.connect(self.noise, (self.noise_adder,0)) gr.hier_block.__init__(self, fg, self.timing_offset, self.noise_adder) + +def set_noise_voltage(noise_voltage): +self.noise.set_amplitude(noise_voltage) + +def set_frequency_offset(frequency_offset): +self.freq_offset.set_frequency(frequency_offset) + +def set_taps(taps): +self.multipath.set_taps(taps) ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG/C++ Template Expansion Info
Another point: Each template type must be individually instantiated
in the code. This is not automated in any way except for the SWIG
MAGIC stuff, but some parts of it probably could be automated via
#define's or something like that. All of this means that instead of
defining some code ("XXX") and having the Makefile expand it,
everything is in the code instead .. all of the instantiations,
whether SWIG or C++. This makes it simple to change the code for new/
other template types (copy, paste, replace-string), but it's not as
automated as that which the Makefile provides (via a list of
expansion types). It's a trade-off; somewhere a list has to be put
together to handle what the expand or instantiate.
On Aug 29, 2007, at 11:23 PM, Eric Blossom wrote:
Can you point us to the code
I'll post the code for demo_sig_source instead once it compiles and
works, most likely later today (for me, now, since I'm up way too late).
, and show for example, how you'd handle
gr_sig_source*?
Since the X instantiations are 's', 'i', 'f', and 'c', and the only
method that's non-standard is "::work", and there is only one
"complex" type that I've ever seen used in GNU Radio ("gr_complex"),
then I'll write the 'default' code for non-complex types since there
are many more of them, and overload it for "gr_complex"
specifically. The rest will be about the same as my current code for
template expansion since all the other methods are common to all
output types. This is the same method used for modifying the base
name of the block (overloading a "make_name" method, one for each
desired template type). - MLD
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG/C++ Template Expansion Info
On Wed, Aug 29, 2007 at 08:23:12PM -0700, Eric Blossom wrote: > On Wed, Aug 29, 2007 at 10:48:07PM -0400, Michael Dickens wrote: > > I've always wondered why GNU Radio didn't use C++ templates for gr- > > blocks (see e.g. the 'gengen' subdirectory in gnuradio-core), since > > they generally result in much less written code. Might partly be > > that SWIG only "recently" (as of 1.3.12 or so) added C++ templates to > > its bag of tricks? Also might be that the SWIG interface is > > challenging at its best, let alone with something as complex as C++ > > template expansion / instantiation? > > > > Last week I hacked through both the C++ and SWIG necessities to get > > template C++ gr-blocks to expand (instantiate) correctly into shared > > libraries that work correctly with both Python and C++. After much > > fussing, I wrote a SWIG macro (%define), similar to > > "GR_SWIG_BLOCK_MAGIC", but for template C++ class expansion into > > uniquely named GR blocks. While the macro might not work for > > everyone (or it might, testers would be appreciated), and maybe it's > > a bit ugly to read, the steps in it make sense according to the SWIG > > documentation. > > > > If anyone is interested I can provide more information. - MLD > > Great! > > Can you point us to the code, and show for example, how you'd handle > gr_sig_source*? Also, if you've got time, can you see if you can figure out how to handle the accumulator type inference in filter/generate_gr_fir_XXX.py? There's probably a way (template metaprogramming from hell?), but beats me. Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG/C++ Template Expansion Info
On Wed, Aug 29, 2007 at 10:48:07PM -0400, Michael Dickens wrote: > I've always wondered why GNU Radio didn't use C++ templates for gr- > blocks (see e.g. the 'gengen' subdirectory in gnuradio-core), since > they generally result in much less written code. Might partly be > that SWIG only "recently" (as of 1.3.12 or so) added C++ templates to > its bag of tricks? Also might be that the SWIG interface is > challenging at its best, let alone with something as complex as C++ > template expansion / instantiation? > > Last week I hacked through both the C++ and SWIG necessities to get > template C++ gr-blocks to expand (instantiate) correctly into shared > libraries that work correctly with both Python and C++. After much > fussing, I wrote a SWIG macro (%define), similar to > "GR_SWIG_BLOCK_MAGIC", but for template C++ class expansion into > uniquely named GR blocks. While the macro might not work for > everyone (or it might, testers would be appreciated), and maybe it's > a bit ugly to read, the steps in it make sense according to the SWIG > documentation. > > If anyone is interested I can provide more information. - MLD Great! Can you point us to the code, and show for example, how you'd handle gr_sig_source*? Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 4x4 MIMO with USRP
On Wed, Aug 29, 2007 at 09:40:58PM -0500, Ketan Mandke wrote: > Martin, > > Thanks for your response. It is disappointing to hear that the MIMO > support for 4 antennas will not be available for some time. Addressing your disappointment: This is a free software project. Code gets written because some actual human being writes it ;) If you're waiting for somebody else to write it, you may be waiting for a long long time... > Could you provide some more details into why this problem of aligning > the transmit samples will be easier in the new m-block framework? Will > these new packet oriented m-blocks utilize a different interface to > the USRP which will make this alignment-task easier? There will be a new interface. More on that when it becomes available. Each frame to be transmitted will have a timestamp that specifies the time that it is to be transmitted. You still have to sync the sample clocks and LO's on the separate USRPs, but there will be a way to communicate, in-band, when you want the frame to be transmitted. Low-level design ideas are described here: http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb They are subject to change... See also: http://gnuradio.org/trac/wiki/MessageBlocks Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] SWIG/C++ Template Expansion Info
I've always wondered why GNU Radio didn't use C++ templates for gr- blocks (see e.g. the 'gengen' subdirectory in gnuradio-core), since they generally result in much less written code. Might partly be that SWIG only "recently" (as of 1.3.12 or so) added C++ templates to its bag of tricks? Also might be that the SWIG interface is challenging at its best, let alone with something as complex as C++ template expansion / instantiation? Last week I hacked through both the C++ and SWIG necessities to get template C++ gr-blocks to expand (instantiate) correctly into shared libraries that work correctly with both Python and C++. After much fussing, I wrote a SWIG macro (%define), similar to "GR_SWIG_BLOCK_MAGIC", but for template C++ class expansion into uniquely named GR blocks. While the macro might not work for everyone (or it might, testers would be appreciated), and maybe it's a bit ugly to read, the steps in it make sense according to the SWIG documentation. If anyone is interested I can provide more information. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 4x4 MIMO with USRP
Martin, Thanks for your response. It is disappointing to hear that the MIMO support for 4 antennas will not be available for some time. Could you provide some more details into why this problem of aligning the transmit samples will be easier in the new m-block framework? Will these new packet oriented m-blocks utilize a different interface to the USRP which will make this alignment-task easier? On 8/29/07, Martin Dvh <[EMAIL PROTECTED]> wrote: > Ketan Mandke wrote: > > Martin, > > > > I've been searching through the mailing list for more information > > about synchronizing two USRP boards to create the transmitter for a > > 4x4 MIMO node. From what I've found, it seems that this is not > > currently implemented (see links below for relevant threads). What is > > the current status of this effort, > > Yes you do need special measures to make sure the samples are aligned. > I am the author of the usrp_multi code (and the modified usrp firmware) > I was working on the transmit site but with the current framework this got > quite complicated. > > The m-blocks framework which is currently in development will make it much > easier to synchronize multiple receive or multiple transmit streams > on seperate USRPs. > So this work has been on hold waiting for the m-blocks become available and > usuable in the main tree. > > and when (if at all) do you think > > that this functionality might be implemented? > Since the m-blocks are maturing now, in theory the work on this could be > started soon. > The problem is that I am very busy doing contract work on another part of > GnuRadio. > So at the moment I don't have time for this. > After this project it also depends on the amount of work I have, how much > time will be left for implementing 4x4MIMO. > So at the soonest in the next few months. > At the latest, in a year or two. > > It also depends on how many others will be working on this code. Until now I > have been the only one implementing the low-level MIMO stuff. > > If you have a budget for it. Matt, Eric and I could probably team up and > implement it more quickly. > If you don't have a budget you could try to help out by doing the dirty work > yourself. > We can help you on your way in this. > > > > > links: > > http://www.nabble.com/Question-about-4-x-4-MIMO-transmitting-and-receiving-tf3605863.html#a10074272 > > http://www.nabble.com/Re%3A-USRP-Tx-Question-tf1452214.html#a3924517 > > > > > One other thing is the phase relationship between the different USRPs. > At the moment we use the upconverters (DUCs) of the ADC/DAC chips. > Unfortunately the starting phase of these can not be set. > Only after power-up these are in a known state. > After you have used the usrp these are in an unknown state. > This means that every time you start a gnuradio script the phase relationship > between the multiple USRPs will have a fixed unknown phase difference. > > Depending on your application this can be a problem. > > The only solution is not to use the DUCs in the DAC but do the upconversion > in the FPGA. > This can be developed but you would probably also have to disable some other > functionality because the FPGA is already very full. > (disable the RX halfbandfilters, or reduce the number of RX channels) > > I hope this clears it up for you. > > Greetings, > Martin DvH > > > > > Olifantasia > Software Defined Radio, GnuRadio, USRP development > -- Ketan Mandke ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with sinc pulse transmission using RFX2400
S. Faisal A. Shah wrote: > ...In fact, the received pulse train seems to be amplitude modulated > by a low frequency signal (in KHz). It sounds like you are encountering frequency offset between your transmitter and receiver. This is caused by differences in the crystals between the two USRPs--up to 20 ppm each in new hardware. At 2.4 GHz, that could be up to 96 KHz in difference between what one is transmitting and the other is tuned to. Frequency offset will cause the received signal to "rotate in phase", so what started out purely in the I channel will be seen in both I and Q, with the magnitude in either one varying as a sine wave at the difference in frequency. Normally, this effect is dealt with using a PLL on the receive side, to adjust the frequency and phase offset to compensate. What type of PLL is dependent on your modulation. -- 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] Problem with sinc pulse transmission using RFX2400
Hi, I am using a USRP with RFX2400 to transmit a sinc pulse using usrp_siggen.py routine and my own sinc pulse generator that is a modified version of gr_sig_source_c.cc. I am using a separate USRP with RFX2400 to receive the pulse using usrp_rx_cfile.py. The transmitter and receiver are one meter apart. First, I tried to put the sinc pulse on the "I" branch (real) and zeros on the "Q" branch. But the amplitude of the received pulse train is time varying. In fact, the received pulse train seems to be amplitude modulated by a low frequency signal (in KHz). Second I tried to put the same sinc pulse on both I and Q and had the same problem. For curiosity, I repeated the experiment by putting few cycles of sine wave on both I and Q and encountered the same problem of amplitude variation. Finally, I tried using a truncated sine wave on I and cosine on Q and it works perfectly fine. I am having difficulty in understanding the problem. Does this mean that I can only put sine and cosine on I and Q, respectively? Is it possible to transmit only single component not quadrature using RFX 2400? I am thinking to set MUX to disable the Q branch at the transmitter and receiver. Any help will be highly appreciated. Thanks in advance, Faisal ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] transmitting with 4 antennas
Ketan Mandke wrote: > I am part of the Hydra group at UT Austin > (http://hydra.ece.utexas.edu). We have developed a MIMO prototype > utilizing GNU Radio & the USRP board. The physical layer for our > design is based on the draft standard for IEEE 802.11n. Our current > system is designed to support 2 antennas (i.e. utilizing one USRP > board per node), however, we would like to extend this to 4 antennas. > > We are currently following the directions on the 'USRPClockingNotes' > page for synchronizing the local oscillators of two USRP boards. The > only problem that remains is aligning the samples. I have been looking > through the GNU Radio codebase for some insight on how to do this. I > found 'usrp_multi.py' which describes how to do this for the receive > chain. However, I also have to be able to align samples for the > transmit chain. > > Does anyone have any experience with transmitting waveforms using > multiple USRP boards? Specifically, do you have to go through any > special process to ensure that transmitted samples are properly > aligned? > Yes you do need special measures to make sure the samples are aligned. I am the author of the usrp_multi code (and the modified usrp firmware) I was working on the transmit site but with the current framework this got quite complicated. The m-blocks framework which is currently in development will make it much easier to synchronize multiple receive or multiple transmit streams on seperate USRPs. So this work has been on hold waiting for the m-blocks become available and usuable in the main tree. One other thing is the phase relationship between the different USRPs. At the moment we use the upconverters (DUCs) of the ADC/DAC chips. Unfortunately the starting phase of these can not be set. Only after power-up these are in a known state. After you have used the usrp these are in an unknown state. This means that every time you start a gnuradio script the phase relationship between the multiple USRPs will have a fixed unknown phase difference. Depending on your application this can be a problem. The only solution is not to use the DUCs in the DAC but do the upconversion in the FPGA. This can be developed but you would probably also have to disable some other functionality because the FPGA is already very full. (disable the RX halfbandfilters, or reduce the number of RX channels) I hope this clears it up for you. Greetings, Martin DvH Olifantasia Software Defined Radio, GnuRadio, USRP development ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trunk check-in dependency file breakage
Josh Blum wrote: > I have committed my recent changes. GRC should work again with the > gnuradio trunk, but many of the hier blocks will be missing for now. > Hopefully, things will stabilize within the week. > > Let me know if there are problems (other than missing blocks). The missing blocks will all get written as part of the run up to release 3.1. Hopefully I'll have them checked into the trunk in the next 4-5 days. -- 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] Trunk check-in dependency file breakage
I have committed my recent changes. GRC should work again with the gnuradio trunk, but many of the hier blocks will be missing for now. Hopefully, things will stabilize within the week. Let me know if there are problems (other than missing blocks). Thanks, -Josh Steven Clark wrote: It seems that this change has broken GRC (complains about non-existent gr.runtime). Josh, is there an ETA on a fix for this? Any short-term work-arounds in the meantime? -Steven On 8/27/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote: I have recently checked in the updates to the hierarchical flowgraph code as outlined in a previous email. One of the changes is that there are no longer any gr_runtime.* files as this class has been removed from the code as part of an API change. However, due to the somewhat broken way we handle SWIG dependencies, a reference to gr_runtime.i remains in the machine generated dependency files (gnuradio-core/src/lib/swig/*.d). This will cause an *already compiled* local copy of the trunk to fail compilation once it is updated with the latest repository revision. It will *not* affect any freshly checked out copies. If you run into this issue, you can either: 1) Edit gnuradio-core/src/lib/swig/*.d and manually remove the line that references gr_runtime.i in each one, -OR- 2) Delete gnuradio-core/src/lib/swig/*.d and then run ./config.status from the top-level directory, -OR- 3) Check out a fresh copy of the trunk and rebuild (simple but overkill.) Patches welcome from anyone who has a better way of automating tracking of SWIG dependencies that doesn't create the above issue when a dependent file is removed. -- 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 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] Trunk check-in dependency file breakage
It seems that this change has broken GRC (complains about non-existent gr.runtime). Josh, is there an ETA on a fix for this? Any short-term work-arounds in the meantime? -Steven On 8/27/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote: > > I have recently checked in the updates to the hierarchical flowgraph > code as outlined in a previous email. > > One of the changes is that there are no longer any gr_runtime.* files as > this class has been removed from the code as part of an API change. > > However, due to the somewhat broken way we handle SWIG dependencies, a > reference to gr_runtime.i remains in the machine generated dependency > files (gnuradio-core/src/lib/swig/*.d). > > This will cause an *already compiled* local copy of the trunk to fail > compilation once it is updated with the latest repository revision. It > will *not* affect any freshly checked out copies. > > If you run into this issue, you can either: > > 1) Edit gnuradio-core/src/lib/swig/*.d and manually remove the line that > references gr_runtime.i in each one, -OR- > > 2) Delete gnuradio-core/src/lib/swig/*.d and then run ./config.status > from the top-level directory, -OR- > > 3) Check out a fresh copy of the trunk and rebuild (simple but overkill.) > > Patches welcome from anyone who has a better way of automating tracking > of SWIG dependencies that doesn't create the above issue when a > dependent file is removed. > > -- > 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] I/Q output on basic tx
Hi everybody, where can I find on the basic tx the I and Q channel outputs ? thanks vincenzo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 4x4 MIMO with USRP
Martin, I've been searching through the mailing list for more information about synchronizing two USRP boards to create the transmitter for a 4x4 MIMO node. From what I've found, it seems that this is not currently implemented (see links below for relevant threads). What is the current status of this effort, and when (if at all) do you think that this functionality might be implemented? links: http://www.nabble.com/Question-about-4-x-4-MIMO-transmitting-and-receiving-tf3605863.html#a10074272 http://www.nabble.com/Re%3A-USRP-Tx-Question-tf1452214.html#a3924517 -- Ketan Mandke http://hydra.ece.utexas.edu ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
