Re: [Discuss-gnuradio] Unable to use WX widgets

[Sandhya G]

*well i'm running into new problem using constellation block .*
  File "/home/sandhya/top_block.py", line 16, in 
from gnuradio.wxgui import constsink_gl
  File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/constsink_gl.py",
line 25, in 
import const_window
  File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/const_window.py",
line 25, in 
import plotter
  File
"/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/__init__.py", line
22, in 
from channel_plotter import channel_plotter
  File
"/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/channel_plotter.py",
line 23, in 
from grid_plotter_base import grid_plotter_base
  File
"/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/grid_plotter_base.py",
line 24, in 
from OpenGL import GL
  File "/usr/lib/pymodules/python2.7/OpenGL/GL/__init__.py", line 11, in

from OpenGL.GL.VERSION.GL_1_2 import *
ImportError: No module named VERSION.GL_1_2

Checking out the previous thread I found two solutions

"First, you can probably install python-opengl on your system. Or you can
turn of GL support by editing the file in (probably)
/usr/local/etc/gnuradio/conf.d/gr-wxgui.conf and change the 'style = auto'
option to 'style = nongl"

But either of the two solutions are working and throwing me the same error.

Anyone can help me on this

Thanks
Sandhya


On Fri, Dec 20, 2013 at 1:09 PM, Sandhya G  wrote:

> Thanks marcus .
>  well all these days I was using  live usb where I was getting different
> (eg sine wave ) kind of output when I was using WX-GUI scope sink so I
> thought it would be missing some package so I wasn't able to see that
> output .
>
>
> well thanks ...
>
>
> On Fri, Dec 20, 2013 at 1:01 PM, Marcus Müller  wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi,
>> these are warnings, and you won't be able to use
>> ctrlport.monitor_performance, but this is not a problem as is.
>> The Volk warning is just telling you that it's falling back to a safe
>> implementation, which could be slower in some cases, but will surely work.
>> To explicitely say it: a warning is a warning that things *might* go
>> wrong. It is not an error. In most cases, one should not heed it too
>> much, unless it seems to be related to the problem at hand.
>>
>> I think you're seeing a single line jumping up and down, and that is
>> what your data looks like to the wxgui sink.
>> Try using a larger value for t/s, the < > buttons on the upper button
>> row on the very left.
>> Also make sure you're not clogging your CPU with work. If you don't
>> have a hardware device setting the the sample rate (e.g. a USRP, a
>> sound card) in your flowgraph, consider simulating that using a
>> throttle block.
>>
>> Greetings
>> Marcus
>>
>> On 20.12.2013 08:16, Sandhya G wrote:
>> > Hi everyone , I installed gnuradio by binaries provided by Ettus
>> > Research in ubuntu software centre. Everything installed properly
>> > and I got gnuradio-companion but whenever I run flowgraph I get
>> > these warnings
>> >
>> > Warning: Block key "blocks_ctrlport_monitor_performance" not found
>> > when loading category tree. Warning: Block key
>> > "blocks_ctrlport_monitor_performance" not found when loading
>> > category tree
>> >
>> > and
>> >
>> > Using Volk machine: sse4_2_32 Volk warning: no arch found,
>> > returning generic impl
>> >
>> > I'm using ubuntu 12.04 i3 64bit processor.
>> >
>> > I'm not getting any waveforms in WX-GUI scope sink . When I run
>> > the flowgraph using WX-GUI scope sink all I can see is a simple
>> > lines varying up and down.
>> >
>> > Can somebody help me !!!
>> >
>> > Thanks in advance Sandhya
>> >
>> >
>> >
>> > ___ Discuss-gnuradio
>> > mailing list Discuss-gnuradio@gnu.org
>> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.15 (GNU/Linux)
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJSs/JQAAoJEAFxB7BbsDrLN1gH/i0tpr4vGIW/Cm9oKUmT75UE
>> 3wsVhQNxN/77s417vl9NNGl6XX4rtwi7WQp0wG8dynDzrSLkzm8y8NUm8Byl5CZf
>> hEFGQxCS69oAVXwVtDyBGmvzcqIJUnQ0iWW1zeKSRCC0+JPsVdqmZZ5CWz8wiK64
>> Je+mvuttauOf/4FSLoX4Wf3K0Bu45smx87336Lf0UtEN6s9UzgaXN7UpBy7AM2dv
>> 2ckmB1azxlZkBGgQPHIvEAJYTFgi6lVGmQ9CUdBElixf/fox7GWh9B/dPJ7CDHX0
>> 0CAd8cmzTqe3h98ikvNwMMD47HKXfBlJzRhQDvc/PhWEfCMj5cVoLEsxXGX67pM=
>> =z9El
>> -END PGP SIGNATURE-
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API

[Ralph A. Schmid, dk5ras]

Do you have the possibility to upload the file to my server? It is on a
VDSL50 line (50Mbps in, 10 Mbps out), so upload from the university (DFN)
network should be fast enough. Then I could post a link for direct download
(well, only 10 Mbps) and provide the file via bittorrent...

Ralph.



> -Original Message-
> From: Johannes Demel [mailto:uf...@student.kit.edu]
> Sent: Thursday, December 19, 2013 5:07 PM
> To: Philip Balister; Ralph A. Schmid, dk5ras
> Cc: Demel, Johannes; 'Mike Cornelius'; 'discuss-gnuradio'
> Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
> 
> That would be cool anyway.
> 
> On 19.12.2013 06:47, Philip Balister wrote:
> > On 12/19/2013 03:24 AM, Ralph A. Schmid, dk5ras wrote:
> >> I'd be happy putting it onto my ftp server, if it could be useful to
> >> the public. Only a 10 Mbps uplink, but better than nothing :)
> >
> > Any chance we could setup a torrent tracker for large data sets?
> >
> > Philip
> >
> >>
> >> Ralph.
> >>
> >>> -Original Message-
> >>> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
> >>> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On
> Behalf
> >>> Of Johannes Demel
> >>> Sent: Thursday, December 19, 2013 9:00 AM
> >>> To: Mike Cornelius; Demel, Johannes
> >>> Cc: discuss-gnuradio
> >>> Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
> >>>
> >>> Hi Mike,
> >>>
> >>> the reference I use is a rather big file > 1gb. It is hard to share
> >>> such a
> >> file
> >>> publicly anywhere. I put a signal generator on the list of needed
> >> features.
> >>>
> >>> All tests are supposed to pass. Which tests fail on your system? Can
> >>> you
> >> run
> >>> them with -V and mail the error messages. That could help.
> >>>
> >>> Happy hacking
> >>> Johannes
> >>>
> >>> On 18.12.2013 23:54, Mike Cornelius wrote:
>  Hi Johannes,
> 
>  With regard to my earlier message regarding the crash I'm seeing, I
>  note that a few tests fail when I run make test, is that to be
expected?
>  Also do you think it would be possible to publish the reference
>  waveform that you are using ?
>  That way I could check to see if the crash occurs with your known
'good'
>  waveform too.
> 
>  Mike
> 
> 
>  On 19 December 2013 18:37, Mike Cornelius   > wrote:
> 
>  Hi Ralph,
> 
>  I had the same problem at first myself, there is no need to
>  reconnect anything in the top_level.grc block so long as all the
>  hier blocks have actually been compiled.
>  In my case the biggest problem was the LTE_estimator_hier block
>  would not compile because the 'import lte' failed (see earlier
>  messages in this thread for details).
> 
> 
>  Mike
> 
> 
>  On 19 December 2013 18:27, Johannes Demel
>   > wrote:
> 
>  Hi everybody,
> 
>  I added screenshots for all the hierarchical flowgraphs and
>  the
> >> top
>  flowgraph to the docs directory. I hope this helps to build
the
>  whole
>  LTE flowgraph in GRC.
>  Although, I realized that would be very helpful if the
> >> hierarchical
>  flowgraphs would be compiled with grcc during make and then
>  installed.
>  Preferably added to a CMakeLists file. I will look into this.
> 
>  Happy hacking
>  Johannes
> 
>  On 18.12.2013 09:47, Johannes Demel wrote:
>  > Hi Ralph,
>  >
>  > unfortunately there are no screenshots yet. I guess it is a
>  good idea to
>  > add some. After the estimator, there should be 2 blocks:
>  Decode PBCH and
>  > Decode PCFICH. They take the same stream. and work in
>  parallel. Then
>  > after Decode PBCH there is supposed to be a 'Decode BCH'
>  block. These
>  > blocks may need some time to generate because they
>  consist of
> >> hier
>  > blocks. That's kind of the tribute that has to be paid
>  for a
> >> clean
>  > flowgraph.
>  > If you opened a flowgraph with missing blocks, as far as I
>  know, to make
>  > the missing blocks appear you have to close and reopen at
>  least this
>  > particular flowgraph.
>  >
>  > Happy hacking
>  > Johannes
>  >
>  >
>  > On Wed, Dec 18, 2013 at 3:49 AM, Ralph A. Schmid, dk5ras
>  > mailto:ra...@schmid.xxx
>  >> wrote:
>  >
>  > Hi,
>  >
>  > after opening and generating the hier blocks still the
>  top_level.grc
>  > has mis

[Discuss-gnuradio] Unable to use constellation block

[Sandhya G]

*Hi everyone,*

*I installed gnuradio using binary packages  provided by ETTUS RESEARCH .*



* I installed gnuradio 3.7.2.1 and processor I’m using is intel i3
64bit.*
*Everything installed with no issues but when  using constellation block,
I’m facing the some problem and below is the error *

 File "/home/sandhya/top_block.py", line 16, in 
from gnuradio.wxgui import constsink_gl
  File "/usr/lib/python2.7/dist-
packages/gnuradio/wxgui/constsink_gl.py", line 25, in 
import const_window
  File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/const_window.py",
line 25, in 
import plotter
  File
"/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/__init__.py", line
22, in 
from channel_plotter import channel_plotter
  File
"/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/channel_plotter.py",
line 23, in 
from grid_plotter_base import grid_plotter_base
  File
"/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/grid_plotter_base.py",
line 24, in 
from OpenGL import GL
  File "/usr/lib/pymodules/python2.7/OpenGL/GL/__init__.py", line 11, in

from OpenGL.GL.VERSION.GL_1_2 import *
ImportError: No module named VERSION.GL_1_2

*Checking out the previous thread I found two solutions*

"First, you can probably install python-opengl on your system. Or you can
turn of GL support by editing the file in (probably)
/usr/local/etc/gnuradio/conf.
d/gr-wxgui.conf and change the 'style = auto' option to 'style = nongl"



*But either of the two solutions are working and throwing me the same
error.*

*Anyone can help me on this *



*Thanks*
*sandhya*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API

[Baier]

Hi Johannes,

thank you very much for updating your gr-lte package. I could compiled 
all .grc files succesfully. Now I would like to test your receiver with 
a LTE signal saved to a file with the following settings.( 5 MHz, RB 25, 
fft 512, occupied carriers 300, no tx diversity). So I have started to 
change the parameters in your grc files.

RB 25 instead 50
fftlen 512 instead 2048(is it right?)
occupied carriers 300 instead 600.
So I have realized the files decode_pcfich_37.grc and decode_pbch_37 
.grc are designed for tx_diversity with two antennas. How can I change 
it? Removing the blocks for the second antenna perhaps?

Thank you very much.
A. Baier



   
   
 



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

Re: [Discuss-gnuradio] OFDM: troubles regarding FFT size and decimation factor

[Sebastian Schmid]

Hi everybody.

(I had some problems with In-Reply-To header, so I hope this gets posted 
in the right thread. Otherwise I'm sorry, this message refers to 
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-12/msg00392.html)


Thank you for your answer, Martin.

Martin Braun wrote:
> I'm not sure what your decimation factor does.
By "decimation factor" I mean the ratio the USRPs 100 MS/s gets divided 
with. So a decimation factor of 16 would result in a sampling rate of 
(100 MS/s / 16) = 6.25 MS/s. In the source code I uploaded it's defined 
in send_receive.py and called "samp_rate_div", using 
set_samp_rate(100e6/samp_rate_

div) to set the USRPs sampling rate.

Martin Braun wrote:
> You're using your own OFDM codes, not the GNU Radio ones, right? Can 
you share these?


I uploaded the relevant code, to give some more details:
https://www.dropbox.com/sh/xdo456tvcqiwdwx/Y-6pcz_rR4 



I already tried to shorten it, but unfortunately it's still a bit 
confusing, as the person who wrote it did somehow bypass GNU Radio a bit 
and implemented a lot himself. Therefore, I give my best to describe how 
the code works:


To give a short abstract of the system: 
https://www.dropbox.com/s/iphz1ix4b1as4pd/network_overview.png 

PC1 commands PC2 and PC3 to alternatingly send some data, at first PC2 
is the transmitter and PC3 the receiver, then the other way round.
The network controller (generating and evaluating all the data, using 
NumPy (I)FFT) commands the network daemons to send data and collects 
received data from them via Ethernet.
The network daemons start the send_receive top_block and read from / 
push to send_receive.py queues by add_complex_list_to_queue() and 
fetch_complex_list_from_queue() functions.
send_receive.py is the top_block, connecting message queues to 
jwdiplom.modulator (adding cyclic prefix) / jwdiplom.demodulator 
(Schmidl & Cox synchronisation) blocks, which are connected to UHD 
source/sink.
The PCs running network daemons each are equipped with two network 
cards, one for communication with network controller and one for 
communication between send_receive and the USRP2 devices by UHD.


More in detail:
PC 1 is the network controller, running nc_kanalmessung_AB_BA.py. This 
Python script at first initializes the network daemons running on PC 2 
and 3, it loads the settings dictionary from ofdmsettings.py and chooses 
the right preamble. It does an IFFT on the preamble (so it's in time 
domain, line 99) and sends this parameters by Ethernet to the daemons 
using send_ethernet_packet() (line 135).
On line 107 it creates random data using modulation.py. Again using 
modulation.py, it PSK modulates the random data, adds the pilot and 
empty carriers (as defined in ofdmsettings.py) and does the IFFT 
(modulation.py, line 46). This ready-to-send time domain data is send 
frame by frame to the network daemons (nc_kanalmessung_AB_BA.py, line 
114), once more using send_ethernet_packet() function.


Now it's time to look at network_daemon.py, running on PCs 2 and 3. As 
one can see there are several threads running, at first InitThread gets 
started, waiting for nc_kanalmessung_AB_BA.py sending the parameters and 
preamble. After this happened the GNU Radio action begins: It starts the 
top_block of send_receive.py (handing over the parameters).


send_receive.py features two message queues connected to 
jwdiplom.modulator and jwdiplom.demodulator.
These message queues are read out / feed with data by 
fetch_complex_list_from_queue() (send_receive.py, line 84) and 
add_complex_list_to_queue() (send_receive.py, line 91) functions, which 
get accessed by InputThread and OutputThread in network_daemon.py.


jwdiplom.modulator just adds a cyclic prefix and is connected to 
uhd_usrp_sink_0.
jwdiplom.demodulator implements a Schmidl & Cox synchronization, it is 
connected to uhd_usrp_source_0.
The source files are located in /gr-jwdiplom/python but for easier 
comprehension I made some .grc files and exported them:
https://www.dropbox.com/s/2s7ssy5ypp0ekjy/ofdm_modulator.grc.png 

https://www.dropbox.com/s/34lo5yytx9accgq/ofdm_demodulator.grc.png 



The demodulator block uses two custom blocks:
 - jwdiplom.schmidl_cox_correlator, implementing formula (6) from 
Schmidl & Cox "Robust Frequency and Timing Synchronization for OFDM" 
paper (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=650240 
)
 - jwdiplom.stream_to_vector_syncd, selecting the right (payload) 
samples according to the sync signal provided by the plateau detector



I know that's a lot of text (and source code) and not relying on GNU 
Radios standard OFDM implementation makes it hard for others to review 
but it wou

Re: [Discuss-gnuradio] Integrate block outputting inconsistent results.

[Miguel Duarte]

It worked.

I don't think it's about file opening permissions, it must be something
else, but it did the trick. The reason I don't think it's about permissions
is that the files are different, therefore the handle shouldn't even be the
same, or am I wrong in thinking so?

Don't know why I need to take this care now, I've used this script a LOT of
times before and this was the first time this happened (fresh GR install on
a new computer).

Thanks a lot Marcus,

Best Regards,

Miguel





2013/12/20 Marcus Müller 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Miguel,
> don't shame yourself too much. We all make mistakes.
>
> It could be that B can't open the file it wants to write, because the
> file_sink of A still has it open. After the A.stop() have an A.wait()
> and an A = None. The wait call should let your program wait until all
> blocks are finished and no samples are left stuck in the flowgraph
> somewhere.
> The None-assignment should cause Python to deconstruct A, causing Swig
> to call the destructor of the C++ blocks and thus in turn should close
> the file_sink's file. Sadly, Python is a modern language/runtime and
> has lazy garbage collection. So in some cases, it might happen that
> python decides that it should clean up later instead of instantly at
> the A=None; then we still have a problem.
> To solve that, you might overload your top_block's stop() method,
> making sure that it calls miguels_file_sink.close() after stopping the
> flowgraph:
>
> class detector(grc_wxgui.top_block):
> ...
> def stop(self):
> grc_wxgui.top_block.stop(self)
> self.miguels_file_sink.close()
>
> Hopefully, that helps.
>
> Greetings,
> Marcus
>
> On 20.12.2013 00:10, Miguel Duarte wrote:
> > I hope this doesn't start a new thread. I wanted to answer on my
> > thread but I didn't get my own message on my inbox so.. I hope it
> > works.
> >
> >
> > I ended up getting what was wrong, and I feel ashamed on so many
> > levels, I'm sorry. I was using complex data. Damn.
> >
> > Anyway, after changing everything, it all works as expected. So I
> > delved a little into what was causing my troubles initially.
> >
> > It seems that my top block class "refuses" to be instanced twice,
> > with two different identifiers.
> >
> > So let's say I have a
> >
> >
> > class detector(grc_wxgui.top_block_gui) def __init__(self,
> > options):
> >
> > Where I start an instance A with a certain set of options and an
> > instance B with other options.
> >
> > I do: A = detector(options) A.start() time.sleep(x) A.stop()
> >
> > change options
> >
> > B = detector(options) B.start() time.sleep(x) B.stop()
> >
> > I have a file sink in the flow graph. With instance A it writes
> > everything, with instance B it doesn't. Nothing is changing the top
> > block, and even with the options parameter switched only A works.
> >
> > Is there something in this new release which prevents this from
> > working?
> >
> > Thanks in advance,
> >
> > Miguel.
> >
> >
> >
> > ___ Discuss-gnuradio
> > mailing list Discuss-gnuradio@gnu.org
> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.15 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQEcBAEBAgAGBQJSs+4KAAoJEAFxB7BbsDrLfgcH/1QG+/txz1x2/pUPxSB3IPOX
> CMnpeRcX1k+wKkRzRjeSuuptwfGOjyaODmbzEHhKsmjLAFkgTcr1IMFogiRN6JqV
> r1II7UKZQR4+49lHQ2luwLRM7S3hffsssWUQfJ29GsymXPwHN9s6cOtYVn/DxUZo
> WQeI1KT06Vhf9stIDW8Cm30J9QAqtR4Jnuop+/0yR+FhO6rbcTTQLApNf0RcOpLQ
> Mb22D3nxCZa3I6GOCWEDISbSfEFXYmBqpMp/zF7rskct2bdpsw0g7E5YKAiNJSrX
> NJL3mEMxCghNLYxvKlZF0kZf4JREFVqbcUqZKtJQHoX2aQOjwggjdDBGl9fXMAs=
> =ea9W
> -END PGP SIGNATURE-
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Integrate block outputting inconsistent results.

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Actually, if it worked reliably before, then there might actually be a
regression or something that should be better documented. Can you
share the top_block's source?
Greetings,
Marcus

On 20.12.2013 13:36, Miguel Duarte wrote:
> It worked.
> 
> I don't think it's about file opening permissions, it must be
> something else, but it did the trick. The reason I don't think it's
> about permissions is that the files are different, therefore the
> handle shouldn't even be the same, or am I wrong in thinking so?
> 
> Don't know why I need to take this care now, I've used this script
> a LOT of times before and this was the first time this happened
> (fresh GR install on a new computer).
> 
> Thanks a lot Marcus,
> 
> Best Regards,
> 
> Miguel
> 
> 
> 
> 
> 
> 2013/12/20 Marcus Müller 
> 
> Hi Miguel, don't shame yourself too much. We all make mistakes.
> 
> It could be that B can't open the file it wants to write, because
> the file_sink of A still has it open. After the A.stop() have an
> A.wait() and an A = None. The wait call should let your program
> wait until all blocks are finished and no samples are left stuck in
> the flowgraph somewhere. The None-assignment should cause Python to
> deconstruct A, causing Swig to call the destructor of the C++
> blocks and thus in turn should close the file_sink's file. Sadly,
> Python is a modern language/runtime and has lazy garbage
> collection. So in some cases, it might happen that python decides
> that it should clean up later instead of instantly at the A=None;
> then we still have a problem. To solve that, you might overload
> your top_block's stop() method, making sure that it calls
> miguels_file_sink.close() after stopping the flowgraph:
> 
> class detector(grc_wxgui.top_block): ... def stop(self): 
> grc_wxgui.top_block.stop(self) self.miguels_file_sink.close()
> 
> Hopefully, that helps.
> 
> Greetings, Marcus
> 
> On 20.12.2013 00:10, Miguel Duarte wrote:
 I hope this doesn't start a new thread. I wanted to answer on
 my thread but I didn't get my own message on my inbox so.. I
 hope it works.
 
 
 I ended up getting what was wrong, and I feel ashamed on so
 many levels, I'm sorry. I was using complex data. Damn.
 
 Anyway, after changing everything, it all works as expected.
 So I delved a little into what was causing my troubles
 initially.
 
 It seems that my top block class "refuses" to be instanced
 twice, with two different identifiers.
 
 So let's say I have a
 
 
 class detector(grc_wxgui.top_block_gui) def __init__(self, 
 options):
 
 Where I start an instance A with a certain set of options and
 an instance B with other options.
 
 I do: A = detector(options) A.start() time.sleep(x) A.stop()
 
 change options
 
 B = detector(options) B.start() time.sleep(x) B.stop()
 
 I have a file sink in the flow graph. With instance A it
 writes everything, with instance B it doesn't. Nothing is
 changing the top block, and even with the options parameter
 switched only A works.
 
 Is there something in this new release which prevents this
 from working?
 
 Thanks in advance,
 
 Miguel.
 
 
 
 ___
 Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org 
 https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
 
>> 
>> ___ Discuss-gnuradio
>> mailing list Discuss-gnuradio@gnu.org 
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJStDtYAAoJEAFxB7BbsDrL5HkIAJ5A1uOcoB1A9Zi7t0R6Fwz1
HMBrq3cTgq+j+RLA1FsxAN4vuihOudpuI1TWldsK9AI2H7O5Is9GzlT53V/XCBi6
ugx5qH4WewgxrZjdqJ/EftJ/VIHLEb4hOFARA7Aq4v1N7fosxeOqBMX4wu7nLD0P
UuKIS2hWi97/yUVfBM8s+WKN+3SiNY0zziQs+oc8WfhgiRVK3SRLMPYjWJYoRAAY
PQsdr8GNRYQah7bqAqrRxX2wneZyAje7mHvfR/5fqk+DxrFlAaPnAyycaz0MAOtM
qJTWI89LdFmdoPIAf7+GAj7RBKDtcgeOOKU4JZv2/dhAcrGy1bVuC5+9BuWpwR0=
=4qYc
-END PGP SIGNATURE-

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

Re: [Discuss-gnuradio] Integrate block outputting inconsistent results.

[Miguel Duarte]

Sure. I don't know if you need an explanation about it (since the code is
really ugly), but if you do, I'll gladly explain what I'm doing.

class detector(grc_wxgui.top_block_gui):
def __init__(self, options):
grc_wxgui.top_block_gui.__init__(self, title="Detector22")
_icon_path = "/usr/share/icons/hicolor/32x32/apps/gnuradio-grc.png"
self.SetIcon(wx.Icon(_icon_path, wx.BITMAP_TYPE_ANY))
##
# Variables
##
self.type = options['type']
if self.type=="CAL":
print
"##CALIBRATING##"
elif self.type=="THR":
print "#GOING THROUGH THRESHOLD"
self.threshold=options['threshold']

self.sensingSamples = options['sensingSamples']
self.fftSize = options['fftSize']
self.sampleRate = options['sampleRate']
self.packetSize = options['packetSize']
self.averageSize = self.sensingSamples
#options['averageSize']=self.sensingSamples # SEMPRE IGUAL ATM
self.emitterGain = options['emitterGain']
self.receiverGain = options['receiverGain']
self.frequency = options['frequency']
self.signalType = options['signalType']
self.fileName = options['fileName']
self.signalAmplitude = options['signalAmplitude']
self.primarySignalType = options['primarySignal']


##
# Blocks
##
self.USRP_SOURCE = uhd.usrp_source(
device_addr="serial=EBR11Y4B1",
stream_args=uhd.stream_args(
cpu_format="fc32",
channels=range(1),
),
)
self.USRP_SOURCE.set_samp_rate(self.sampleRate)
self.USRP_SOURCE.set_center_freq(self.frequency, 0)
self.USRP_SOURCE.set_gain(self.receiverGain, 0)
self.USRP_SOURCE.set_antenna("RX2", 0)








if self.signalType=="SIGNAL":
self.throttle = blocks.throttle(gr.sizeof_gr_complex*1,
self.sampleRate)
self.USRP_SINK =
uhd.usrp_sink(device_addr="serial=EBR11Y3B1",stream_args=uhd.stream_args(cpu_format="fc32",channels=range(1),),)
self.USRP_SINK.set_samp_rate(self.sampleRate)
self.USRP_SINK.set_center_freq(self.frequency, 0)
self.USRP_SINK.set_gain(self.emitterGain, 0)
self.USRP_SINK.set_antenna("TX/RX", 0)
if self.primarySignalType == 0:
self.primarySignal =
analog.fastnoise_source_c(analog.GR_GAUSSIAN, self.signalAmplitude, 0, 8192)
elif self.primarySignalType == 1:
self.primarySignal = analog.sig_source_c(self.sampleRate,
analog.GR_SIN_WAVE, 1000, self.signalAmplitude,0)
##elif self.primarySignalType == 2:
##self.primarySignal =
analog.fastnoise_source_c(analog.GR_GAUSSIAN, self.signalAmplitude, 0, 8192)
##self.options[' = (self.signalAmplitude, self.sampleRate/2)
##self.OFDMMod =
digital.ofdm_mod(self.options,msgq_limit=4,pad_for_usrp=True)


self.DCBlocker = filter.dc_blocker_cc(16, True)
self.keepMinN = blocks.keep_m_in_n(gr.sizeof_gr_complex,
self.sensingSamples, self.packetSize, 0)
self.stream2Vector =
blocks.stream_to_vector(gr.sizeof_gr_complex*1, self.fftSize)
self.FFTBlock = fft.fft_vcc(self.fftSize, True,
(window.blackmanharris(self.fftSize)), True, 1)
self.complex2MagSquared =
blocks.complex_to_mag_squared(self.fftSize)
self.integrateBlock = blocks.integrate_ff(self.sensingSamples)
self.constantForDivision = analog.sig_source_f(0,
analog.GR_CONST_WAVE, 0, 0, self.sensingSamples)
self.divideBlock = blocks.divide_ff(1)
self.vector2Stream = blocks.vector_to_stream(gr.sizeof_float*1,
self.fftSize)

if self.type=="THR":
self.thresholdFloat = blocks.threshold_ff(self.threshold,
self.threshold, 0)

self.fileSink = blocks.file_sink(gr.sizeof_float*1,
str(self.fileName))
self.fileSink.set_unbuffered(False)





##
# Connections
##


self.connect((self.FFTBlock, 0), (self.complex2MagSquared, 0))
self.connect((self.USRP_SOURCE, 0), (self.DCBlocker, 0))
self.connect((self.complex2MagSquared, 0), (self.vector2Stream, 0))
self.connect((self.vector2Stream, 0), (self.integrateBlock, 0))
self.connect((self.integrateBlock, 0), (self.divideBlock, 0))
self.connect((self.constantForDivision, 0), (self.divideBlock, 1))
self.connect((self.DCBlocker, 0), (self.keepMinN, 0))
self.connect((self.keepMinN, 0), (self.stream2Vector, 0))
self.connect((s

Re: [Discuss-gnuradio] about gr-modtool

[alex]

Hi Martin,

I found the problem. I should only comment out the 
#find_package(GnuradioRuntime) but not delete it. The source code in 
modtool_base.py is trying to search this line to check if have a 
makefile. Maybe it is good to update.


Best regards

Zan
On 12/19/2013 08:55 PM, Martin Braun wrote:
On Thu, Dec 19, 2013 at 11:12 AM, alex > wrote:


Hi Martin,

Thanks for your information.

If I run the gr_modtool info in another OOT-module dir, I got the
following information:
Module name: gmsktr
API version: post-3.7

but if I run the gr_modtool info in the OOT-module which I have
trouble, I got :

No module found.

I am working on GNU radio 3.7.0


OK, I know I commited something recently related to this problem. In 
your case, it *should* still work though.


following is the CMakeFile.txt:

[...]

find_package(Gnuradio)


Can you change this line to
find_package(Gnuradio "3.7.0")

and see if it does anything?

If that doesn't help, do a line-by-line diff between the functioning 
CMakeLists.txt and the other one.


MB



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

Re: [Discuss-gnuradio] Message port connections in gr-blocks/examples/msg_passing

[Bastian Bloessl]

Hi,

On 19 Dec 2013, at 17:45, Koslowski, Sebastian (CEL) 
 wrote:
> I am a little surprised to hear that gr-ieee802-11 files are not working
> either because it was Bastian who came up with the need to change this...
> 

I’m currently travelling and can’t test it, but I updated my stuff and tested 
it on several different PCs. So it should work.

The conversation with Sean about the broken connections was before the changes 
to mainline. At that time I had a non-standard installation and therefore my 
flow graphs did not work for out of the box. But that should be fixed now.

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

[Discuss-gnuradio] isdb-t implementation in gnuradio

[Federico Larroca]

Hi everyone,

Here in the lab we have been working for several months with USRPs and
GNURadio, both for teaching and research, but specially the former.
Students are very very motivated by the sense of reality that they bring.
All in all, congratulations for all the developers involved.

In any case, here in Uruguay they are starting to deploy digital TV, the
ISDB standard in particular. So we figured that a good "long-term" project
would be to implement an ISDB receiver. The first thing we had done is to
verify if anyone has developed (or at least started to develop) such
receiver with GNURadio and USRP (or any other SDR platform, such as
BladeRF).

After conducting a realtively thorough search on the internet, we have
concluded that some work has been carried out, but no code has been made
public. In particular, we found the following related works:

 - The work of the group of Vincenzo Pellegrini in DVB, which is not
available (https://www.ruby-forum.com/topic/1440970).
 - Receiving only the 1seg by a group in the Nara Institute of Science and
Technology, which I believe is not available either (a demo in youtube:
http://www.youtube.com/watch?v=svzMwFrcNC0).
 - A paper by a group in the University of Campinas (Brazil), where they
report of an ongoing work to implement a ISDB-T transmitter (see
http://groups.winnforum.org/europe_papers_wednesday#2.3), but of which I
could not find anything except the paper.

Anyone knows of a project to implement such receiver in GNURadio? Or maybe
someone has tried and concluded that the required computation is too much
for the host PC?

Thanks in advance.
Best regards,
Federico
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API

[Johannes Demel]

Hi,

regarding the different parameters. 'tx_diversity' should always be left as
it is. In case of a 1x1 MIMO configuration it will just have no effect.
This parameter reflects the LTE standard with its two options
'tx_diversity' and 'spatial_multiplexing'. The latter isn't used for
control channels.
In order to specify a certain bandwidth, use the parameter 'N_rb_dl', which
specifies the number of resource blocks used. This will also set the
bandwidth as this is the unit given by the system to determine the
bandwidth. e.g. have a look at the paper which is included in the project
there is a table which shows the dependencies.
25 RBs --> 25*12 = 300 subcarrier --> 15kHz * 300 + spacing = 5MHz.
The FFT length can be chosen freely as long as it provides sufficient bins
to match the current number of subcarriers. It will be used to determine
the input sample rate. I suggest you stick with power of 2 values. Those
are the only ones I tested and the numbers the system is designed for. One
more thing, a FFT length shorter than 256 results in fractional CP lengths,
which should be avoided. LTE's CP use is already quite tricky and the
introduction of fractional CP lengths will not ease the situation.
PBCH decoding is handled for one and two antenna configurations, so you
don't have to worry about configuring the flowgraph there.
PCFICH decoding will receive a message on runtime which sets the decoded
antenna configuration.

Happy hacking
Johannes


On Fri, Dec 20, 2013 at 2:39 AM, Baier  wrote:

> Hi Johannes,
>
> thank you very much for updating your gr-lte package. I could compiled all
> .grc files succesfully. Now I would like to test your receiver with a LTE
> signal saved to a file with the following settings.( 5 MHz, RB 25, fft 512,
> occupied carriers 300, no tx diversity). So I have started to change the
> parameters in your grc files.
> RB 25 instead 50
> fftlen 512 instead 2048(is it right?)
> occupied carriers 300 instead 600.
> So I have realized the files decode_pcfich_37.grc and decode_pbch_37 .grc
> are designed for tx_diversity with two antennas. How can I change it?
> Removing the blocks for the second antenna perhaps?
> Thank you very much.
> A. Baier
>
>
>
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Unable to use constellation block

[Tom Rondeau]

On Fri, Dec 20, 2013 at 4:33 AM, Sandhya G  wrote:

> *Hi everyone,*
>
> *I installed gnuradio using binary packages  provided by ETTUS RESEARCH . *
>
>
>
> * I installed gnuradio 3.7.2.1 and processor I’m using is intel i3
> 64bit. *
> *Everything installed with no issues but when  using constellation block,
> I’m facing the some problem and below is the error *
>
>  File "/home/sandhya/top_block.py", line 16, in 
> from gnuradio.wxgui import constsink_gl
>   File "/usr/lib/python2.7/dist-
> packages/gnuradio/wxgui/constsink_gl.py", line 25, in 
> import const_window
>   File "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/const_window.py",
> line 25, in 
> import plotter
>   File
> "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/__init__.py", line
> 22, in 
> from channel_plotter import channel_plotter
>   File
> "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/channel_plotter.py",
> line 23, in 
> from grid_plotter_base import grid_plotter_base
>   File
> "/usr/lib/python2.7/dist-packages/gnuradio/wxgui/plotter/grid_plotter_base.py",
> line 24, in 
> from OpenGL import GL
>   File "/usr/lib/pymodules/python2.7/OpenGL/GL/__init__.py", line 11, in
> 
> from OpenGL.GL.VERSION.GL_1_2 import *
> ImportError: No module named VERSION.GL_1_2
>
> *Checking out the previous thread I found two solutions*
>
> "First, you can probably install python-opengl on your system. Or you can
> turn of GL support by editing the file in (probably)
> /usr/local/etc/gnuradio/conf.
> d/gr-wxgui.conf and change the 'style = auto' option to 'style = nongl"
>
>
>
> *But either of the two solutions are working and throwing me the same
> error.*
>
> *Anyone can help me on this *
>
>
>
> *Thanks*
> *sandhya*
>
>
The constellation sink does not have a non-OpenGL version, so you have to
have OpenGL support (software and hardware). I'm guessing there is
something more you need to do to get opengl on your system.

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

Re: [Discuss-gnuradio] Message port connections in gr-blocks/examples/msg_passing

[Nowlan, Sean]

-Original Message-
From: Bastian Bloessl [mailto:bastian.bloe...@uibk.ac.at] 
Sent: Friday, December 20, 2013 9:06 AM
To: Koslowski, Sebastian (CEL)
Cc: Tom Rondeau; Nowlan, Sean; GNURadio Discussion List
Subject: Re: [Discuss-gnuradio] Message port connections in 
gr-blocks/examples/msg_passing

Hi,

On 19 Dec 2013, at 17:45, Koslowski, Sebastian (CEL) 
 wrote:
> I am a little surprised to hear that gr-ieee802-11 files are not 
> working either because it was Bastian who came up with the need to change 
> this...
> 

I'm currently travelling and can't test it, but I updated my stuff and tested 
it on several different PCs. So it should work.

The conversation with Sean about the broken connections was before the changes 
to mainline. At that time I had a non-standard installation and therefore my 
flow graphs did not work for out of the box. But that should be fixed now.

Bastian

-
Sorry I didn't provide that context, i.e., that my experience with 
gr-ieee802-11 was several weeks ago before those changes.

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

Re: [Discuss-gnuradio] Message port connections in gr-blocks/examples/msg_passing

[Koslowski, Sebastian (CEL)]

I created a patch to fix the issue of missing message connections. If
you want to help testing, see

https://github.com/gnuradio/gnuradio-wg-grc/tree/grc_fg_load_fix

Let me know, if this works for you. Also, the hier/ example in gr-blocks
had a minor bug. See:

https://github.com/gnuradio/gnuradio-wg-grc/tree/blocks_msg_example_fix

Sebastian

-- 
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Sebastian Koslowski
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe, Germany

Phone: +49 721 608-46275
Fax:   +49 721 608-46071
Email: sebastian.koslow...@kit.edu
Web:   http://www.cel.kit.edu/

KIT – University of the State of Baden-Wuerttemberg and National
Research Center of the Helmholtz Association



signature.asc
Description: OpenPGP digital signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Website edits temporarily suspended

[Tom Rondeau]

Hi everyone,

I just wanted to let you all know that we have temporarily suspended
edits to gnuradio.org pending a full website update. We've already
moved the current wiki system over to the new server, so the
suspension is to make sure that we don't lose any edits or issues
between now and when we bring the other server online. We expect this
to happen some time early tomorrow. Failing that, I will turn editing
back on and migrate again if necessary.

Johnathan and I will announce when the new website is available. We
expect that this won't change how anything works from your side of the
table, but it's an important performance and security update from our
side.

Thanks!
Tom

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

Re: [Discuss-gnuradio] How to best use new GR features for TDMA systems ?

[Wayne Roberts]

I suppose airprobe handled that sort of thing for GSM reception, back in
the 3.6 days.

But disturbing is your mention of frequency hopping, since that would
require some real-time performance between the software and hardware, if it
requires changing the center frequency (PLL synth) of SDR source/sink
hardware.   I'm would assume such latency is not guaranteed even slightly.


On Thu, Dec 19, 2013 at 11:05 AM, Sylvain Munaut <246...@gmail.com> wrote:

> Hi,
>
> So I've wanted for a while to use GR more for TDMA systems I'm working
> with like GSM and GMR and I'm having a bit of trouble figuring out
> what the best way to do that.
>
> Back when I started osmo-gmr, GR didn't have many features to deal
> with packets and so I rolled my own hack to go from channelized IQ
> stream from Gnuradio to my demodulator function that takes sliced
> 'windows' of IQ samples of known length and ideally I'd like to
> replace most of it with GR. I'll try to explain below exactly what the
> current code does and what it must deal with and hopefully someone
> familiar with all the new packet feature of GR can guide me how to
> implement it in GR.
>
> The input comes from GR currently. It's basically a group of
> channelized IQ streams that correspond to the various channels. They
> don't necessarely have the same sample-rate, some can be N times
> larger (N being an integer). All those streams are synchronized and
> must be kept in sync (for example it's needed for hopping, or channel
> assignements, ...).
>
> Once the process is started, a "sync detection" task is started on
> each channel that will try to acquire initial alignement. This
> essentially captures a chunk of each channel long enough and give it
> as a big sample array to a function that will find sync pattern for
> whatever protocol it's configured for. Once it finds that pattern, it
> will initialize a TDMA context that basically knows how to slice the
> input into frames. Once those initial frames boundaries are known, the
> main TDMA scheduler can be started for each context that was created.
> This scheduler basically keeps a list of active / running "tasks". An
> example of such a task would be a BCCH task that will slice the BCCH
> IQ samples (purely based on the samples number and acquired alignement
> and the known/specified TDMA scheduling) and hand them off to the BCCH
> demodulator function. Each of those task can spawn new tasks, possibly
> on other (or dynamic) channels. So if we see an "IMMEDIATE
> ASSIGNEMENT" command in the BCCH/CCCH for example, it will create a
> new 'SDCCH task' for example that will go and follow this channel with
> it's own state ...
>
> Now of course when starting a new task (after having demodulated /
> processed the IQ data), it's sometime important to know where in the
> IQ stream that command originated and it's important that the TDMA
> slicer didn't take too much advance because if it did, we might miss
> some of the TCH frames of the newly assigned channel. In the current
> code, everything is done in a single thread so I'm sure that the
> slicer didn't avance at all while I was processing the current packet.
>
> So, how would you implement this (architecture wise I mean) with PDUs
> / tagged stream / ...
>
> Cheers,
>
> Sylvain
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio