[Discuss-gnuradio] TX and RX on same board

[crjqq]

I am using a RFX900 daughter board. I have tested the TX and RX functionality 
separately and it works. I now want to do both transmission and reception 
simultaneously from a single daughterboard on a single usrp(both TX and RX are 
quadrature;I-Q).

what changes are required?(is this even possible?) I use only c++ and the 
usrp_standard_tx and usrp_standard_rx classes only. Both TX and RX need the 
same same frequency.

thanks in advance
-Rush



  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Question in make check of qa_howto*.py

[Milo Wong]

Dear all,

I am reading over the manual of how-to-write-a-block. For the given example:
howto_square_ff. I followed the instructions to run the test driven program,
but after I input "$ make check" under directory
~/gr-howto-write-a-block/src/python, it said:
 "make: *** No rule to make target `check'.  Stop."
which is not the same as the expected messages in tutorial, i.e -

[...@bufo python]$ make check
  make  check-TESTS
  make[1]: Entering directory
`/home/eb/gr-build/gr-howto-write-a-block/src/python'
  Traceback (most recent call last):
File "./qa_howto.py", line 24, in ?
  import howto
  ImportError: No module named howto

I know I have to import "howto" module to make the thing works. But I was
wondering why I can not even use "make check"? I searched my question
online, but there's only one similar question which was left unanswered.
What's the problem might be?


FYI:
Ubuntu9.04 + gnuradio3.2+ gr-howto-write-a-block-3.2.2

Milo
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator

[Nick Foster]

Shizheng,

For an alternative noncoherent GMSK demodulator that does a lot better than the 
stock one, see the GMSK receiver I put together for my AIS project:

https://www.cgran.org/wiki/AIS

It uses a modified decision-feedback equalizer to estimate the channel and 
remove ISI. It seems to do pretty well for my application. If you have a 
continuous signal (i.e., not in short bursts) you can even use the stock LMS 
DFE block. My application uses short packets, so I run them through the DFE 
multiple times to train it. The DFE avoids the colored-noise problem you get 
when you invert the channel with a matched filter. It's pretty simple, but it 
works.

--n

> Date: Thu, 30 Jul 2009 20:31:44 -0400
> From: anas...@umich.edu
> To: shizhen...@gmail.com
> Subject: Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator
> CC: Discuss-gnuradio@gnu.org
> 
> 
> 
> Shizheng Li wrote:
> > Thank you for your reply!
> > 
> > I think the generic receiver for CPM you mentioned is the optimal 
> > receiver for CPM and the projection onto basis functions (correlation 
> > with basis functions) is equivalent to the matched filters, am I right?
> 
> yes; however see the comment i made about the colored noise and the 
> detection vs detection/estimation in my earlier post
> 
> > Go back to the GMSK transceiver I mentioned in the file
> > 
> > http://gnuradio.org/trac/browser/gnuradio/branches/releases/3.2/gnuradio-core/src/python/gnuradio/blks2impl/gmsk.py
> > 
> > The modulator structure is NRZ mapping --> Gaussian filter --> FM modulator
> > And the demodulator structure is  FM demodulator --> Timing recovery --> 
> > detector
> > 
> > I think after the FM demodulator the signal can be viewed as a PAM 
> > modulated signal and what if I add a matched filter before the timing 
> > recovery? Can I improve the BER performance? I think the matched filter 
> > can maximize the output SNR. Will it make the detector work better?
> 
> you are already suboptimal when you do FM demodulation...
> 
> > Best regards,
> > Shizheng Li
> > 
> > 
> > 
> > On Thu, Jul 30, 2009 at 2:07 PM, Achilleas Anastasopoulos 
> > mailto:anas...@umich.edu>> wrote:
> > 
> > 
> > There is no reason why you should not use a matched filter.
> > However make sure you understand that a symbol-spaced MF
> > generates sufficient statistics only for detection,
> > ie, not for (epoch) synchronization.
> > Also note that in the case of GMSK (CPM in general) a bank of MFs
> > will generate colored noise.
> > Another appropriate implementation of a front end projects the
> > entire oversampled signal to a set of orthonormal basis functions
> > which has the advantage of generating white noise samples for
> > (simpler) further processing.
> > 
> > Take a look at how a generic receiver for an arbitrary CPM
> > is developed in
> > 
> > 
> > http://gnuradio.org/svn/gnuradio/trunk/gr-trellis/src/examples/test_cpm.py
> > 
> > There, the signal is first projected to its basis functions (which
> > is calculated by a helper python application in "fsm_utils.py")
> > to generate a sufficient statistic which is then used in conjunction
> > with trellis decoding to do soft-decision sequence detection.
> > What is missing though is epoch and phase syncronization (to do at
> > some point...)
> > 
> > Achilleas
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > 
> > 
> > -- 
> > Best Regards,
> > Shizheng Li
> > Ph.D. Student and Research Assistant
> > Department of Electrical and Computer Engineering
> > Iowa State University
> > 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_
Bing™ brings you maps, menus, and reviews organized in one place. Try it now.
http://www.bing.com/search?q=restaurants&form=MLOGEN&publ=WLHMTAG&crea=TXT_MLOGEN_Local_Local_Restaurants_1x1___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

RE: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator

[Nick Foster]

Achilleas,



I'm rooting through your test_cpm.py code, and I have a few questions on what's 
going on in there. Specifically:



What is the purpose of the two filters with coeffs MF[0,1]?



Why do you frequency-shift the modulated signal by -f0T to bring the "low" 
frequency to zero before feeding it to the filters?



What is the purpose of the streams_to_stream conversion?



Sorry in advance if these are trivial questions.



--n

> Date: Thu, 30 Jul 2009 20:31:44 -0400
> From: anas...@umich.edu
> To: shizhen...@gmail.com
> Subject: Re: [Discuss-gnuradio] Why not use matched filter in GMSK demodulator
> CC: Discuss-gnuradio@gnu.org
> 
> 
> 
> Shizheng Li wrote:
> > Thank you for your reply!
> > 
> > I think the generic receiver for CPM you mentioned is the optimal 
> > receiver for CPM and the projection onto basis functions (correlation 
> > with basis functions) is equivalent to the matched filters, am I right?
> 
> yes; however see the comment i made about the colored noise and the 
> detection vs detection/estimation in my earlier post
> 
> > Go back to the GMSK transceiver I mentioned in the file
> > 
> > http://gnuradio.org/trac/browser/gnuradio/branches/releases/3.2/gnuradio-core/src/python/gnuradio/blks2impl/gmsk.py
> > 
> > The modulator structure is NRZ mapping --> Gaussian filter --> FM modulator
> > And the demodulator structure is  FM demodulator --> Timing recovery --> 
> > detector
> > 
> > I think after the FM demodulator the signal can be viewed as a PAM 
> > modulated signal and what if I add a matched filter before the timing 
> > recovery? Can I improve the BER performance? I think the matched filter 
> > can maximize the output SNR. Will it make the detector work better?
> 
> you are already suboptimal when you do FM demodulation...
> 
> > Best regards,
> > Shizheng Li
> > 
> > 
> > 
> > On Thu, Jul 30, 2009 at 2:07 PM, Achilleas Anastasopoulos 
> > mailto:anas...@umich.edu>> wrote:
> > 
> > 
> > There is no reason why you should not use a matched filter.
> > However make sure you understand that a symbol-spaced MF
> > generates sufficient statistics only for detection,
> > ie, not for (epoch) synchronization.
> > Also note that in the case of GMSK (CPM in general) a bank of MFs
> > will generate colored noise.
> > Another appropriate implementation of a front end projects the
> > entire oversampled signal to a set of orthonormal basis functions
> > which has the advantage of generating white noise samples for
> > (simpler) further processing.
> > 
> > Take a look at how a generic receiver for an arbitrary CPM
> > is developed in
> > 
> > 
> > http://gnuradio.org/svn/gnuradio/trunk/gr-trellis/src/examples/test_cpm.py
> > 
> > There, the signal is first projected to its basis functions (which
> > is calculated by a helper python application in "fsm_utils.py")
> > to generate a sufficient statistic which is then used in conjunction
> > with trellis decoding to do soft-decision sequence detection.
> > What is missing though is epoch and phase syncronization (to do at
> > some point...)
> > 
> > Achilleas
> > 
> > 
> > ___
> > Discuss-gnuradio mailing list
> > Discuss-gnuradio@gnu.org 
> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> > 
> > 
> > 
> > 
> > -- 
> > Best Regards,
> > Shizheng Li
> > Ph.D. Student and Research Assistant
> > Department of Electrical and Computer Engineering
> > Iowa State University
> > 
> 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

_
NEW mobile Hotmail. Optimized for YOUR phone.  Click here.
http://windowslive.com/Mobile?ocid=TXT_TAGLM_WL_CS_MB_new_hotmail_072009___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] FFT Plot and Benchmark

[Tom Rondeau]

adib_sairi wrote:

Ali Siddiqi wrote:
  

Hi all,
I looked at fftsink_gl.py. It couldnt be executed because of import error
of
fft_window. Also, if in case I manage
to run it, still I am finding it difficult to incoporate it in
benchmark_tx.py. Can someone elaborate a bit more on how to add FFT sink
in
benchmark_tx?

Regards,
Ali




i try to work on this also but i still cannot put fftsink_nongl.py and
benchmark_tx or benchmark_rx together.. the problem i face is benchmark_*
have its own flowgraph which use .start and .wait for it to run.. i.e
tb.start and tb.wait while fftsink_nongl use stdgui2.stdapp and Mainloop to
run.. i.e 


app = stdgui2.stdapp(app_top_block, "USRP FFT", nstatus=1)
app.MainLoop()

when i run tb.start or tb.run and tb.wait, it seem that my fftsink_nongl
that i had connect with usrp_source in the first place is stopping.. 


so can any body help me on combining this two system together? how to run
this two flowgraph together? what i want to do is i want to sense the
spectrum using fftsink_nongl.py and looking for spectrum hole and access the
hole by using benchmark_tx and benchmark_rx.. 

thank you in advance 


Adib
  


The coupling of the flow graph and the Wx architecture was one of my 
motivations for writing the gr-qtgui. You should be able to "from 
gnuradio.qtgui import qtgui" then drop a sink (qtgui.sink_c(args)) and 
connect the signal block you want to observe to this sink. Remember that 
when you start the flow graph use "tb.start()" and not "tb.run()" and 
then execute the Qt application with a "qapp.exec_()", which blocks 
until closed.


Note that you'll have to install a few Qt-related things (Qt > 4.3, 
PyQt, QWT, and QWT Plot 3D). If you running Ubuntu or Fedora, these are 
available from your package manager.


You can find examples of how to use this in gr-qtgui/src/python with 
more complicated examples that allow you to build a full QT application 
with the sink display embedded in it. If you just use a sink and start 
the QApp, you just get a modal dialog box. You can have multiple QT 
sinks going at once, too.


Tom




___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] newbie's question. performance-critical or non-performance-critical??

[Mattias Kjellsson]

Hi,

While it is still possible (and from my understanding, most people use 
python) to use python to interface the underlying c++ blocks, there is 
also the possibility to just use c++ for connecting the flowgraph, see 
gnuradio-examples/c++/dial_tome for an example.


Hope this helps.
//Mattias


Milo Wong wrote:

Hi all,

I am new to GNU radio. I know that GNU Radio applications are 
primarily written in Python, while performance-critical signal 
processing path is implemented in C++. Here I am a little bit 
confused. If I am going to create a sinewave generating and processing 
block, Which language should I use? Is my sinewave generating block 
performance-critical? I know it's kind of a stupid question...but I am 
confused by the words from gnuradio FAQ:



  """Why bother with Python? I just want to code in C++!
  

It is currently being worked on (#128 
). There are a few different 
things that have to happen to support such a feat (#118 
), but if you want to see it done 
quicker feel free to help out.


Python is only used to setup the flow graph. Once setup, most of the 
work is done in C++. """



My understand is if I am going to create a new block, I need to use 
C++ first to descript the signal processing. And then generate the 
flow graph of already defined blocks in python. Is that correct?



Please help. I was messed up by these consepts.


Thanks,


Yuan









___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio