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

[Mike Cornelius]

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 missing blocks, at least LTE estimator outputs and unpack MIB
>> > inputs are unconnected, leaving a large white area in between. How
>> > should this flowgraph look like, is there a screenshot available
>> > somewhere?
>> >
>> > Just wanted to put this all together in my lunch break, but seems
>> > too big for such a short break anyway :)
>> >
>> > 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: Sunday, 15 December, 2013 00:34
>> > > To: discuss-gnuradio
>> > > Subject: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
>> > >
>> > > Hello GNU Radio enthusiasts,
>> > >
>> > > some time after the GNU Radio 3.7 release I started to move the
>> > code for 'gr-lte' to the new API. Besides moving it to the new API,
>> I
>> > > wanted to clean up code and rework a lot of tests. Thus, the whole
>> > transition took a lot of time and work.
>> > > Now, all current blocks are moved to the GNU Radio 3.7 API with
>> > lots of enhancements. e.g. I tried to remove all hierarchical python
>> > blocks
>> > > and created them as GRC hier blocks instead. Or runtime status
>> > events, like cell_id extraction, are all propagated through message
>> > ports
>> > > now.
>> > > Also, there is a PyBOMBS recipe now to ease the installation
>> process.
>> > >
>> > > I hope 'gr-lte' can be useful for others.
>> > >
>> > > Source code is available at https://github.com/kit-cel/gr-lte
>> > >
>> > > Happy hacking
>> > > Johannes
>> > >
>> > > ___
>> > > 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
>> >
>> >
>>
>> ___
>> 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

[Mike Cornelius]

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 missing blocks, at least LTE estimator outputs and unpack MIB
> > inputs are unconnected, leaving a large white area in between. How
> > should this flowgraph look like, is there a screenshot available
> > somewhere?
> >
> > Just wanted to put this all together in my lunch break, but seems
> > too big for such a short break anyway :)
> >
> > 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: Sunday, 15 December, 2013 00:34
> > > To: discuss-gnuradio
> > > Subject: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
> > >
> > > Hello GNU Radio enthusiasts,
> > >
> > > some time after the GNU Radio 3.7 release I started to move the
> > code for 'gr-lte' to the new API. Besides moving it to the new API, I
> > > wanted to clean up code and rework a lot of tests. Thus, the whole
> > transition took a lot of time and work.
> > > Now, all current blocks are moved to the GNU Radio 3.7 API with
> > lots of enhancements. e.g. I tried to remove all hierarchical python
> > blocks
> > > and created them as GRC hier blocks instead. Or runtime status
> > events, like cell_id extraction, are all propagated through message
> > ports
> > > now.
> > > Also, there is a PyBOMBS recipe now to ease the installation
> process.
> > >
> > > I hope 'gr-lte' can be useful for others.
> > >
> > > Source code is available at https://github.com/kit-cel/gr-lte
> > >
> > > Happy hacking
> > > Johannes
> > >
> > > ___
> > > 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
> >
> >
>
> ___
> 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

[Johannes Demel]

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 missing blocks, at least LTE estimator outputs and unpack MIB
> inputs are unconnected, leaving a large white area in between. How
> should this flowgraph look like, is there a screenshot available
> somewhere?
> 
> Just wanted to put this all together in my lunch break, but seems
> too big for such a short break anyway :)
> 
> 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: Sunday, 15 December, 2013 00:34
> > To: discuss-gnuradio
> > Subject: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
> >
> > Hello GNU Radio enthusiasts,
> >
> > some time after the GNU Radio 3.7 release I started to move the
> code for 'gr-lte' to the new API. Besides moving it to the new API, I
> > wanted to clean up code and rework a lot of tests. Thus, the whole
> transition took a lot of time and work.
> > Now, all current blocks are moved to the GNU Radio 3.7 API with
> lots of enhancements. e.g. I tried to remove all hierarchical python
> blocks
> > and created them as GRC hier blocks instead. Or runtime status
> events, like cell_id extraction, are all propagated through message
> ports
> > now.
> > Also, there is a PyBOMBS recipe now to ease the installation process.
> >
> > I hope 'gr-lte' can be useful for others.
> >
> > Source code is available at https://github.com/kit-cel/gr-lte
> >
> > Happy hacking
> > Johannes
> >
> > ___
> > 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
> 
> 

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

Re: [Discuss-gnuradio] i got such a message when run qt-gui

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Maheshkumar,


> Got bus address:
> 
"unix:abstract=/tmp/dbus-ZqX6rpDyRY,guid=b3eabb1d7a1550be2db27652002b"
> Connected to accessibility bus at:
> 
"unix:abstract=/tmp/dbus-ZqX6rpDyRY,guid=b3eabb1d7a1550be2db27652002b"
this is not even a warning, I'd say it has something to do with an
accessibility system (screen reader, input helper etc) on your system.
Since it doesn't say anything dangerous or useful, ignore it. It's not
part of GNU Radio. And it seems that it tells us everything is fine.

> Using Volk machine: avx_32_mmx
That's good. Volk seems to work well.

Greetings,
Marcus


On 19.12.2013 07:06, Maheshkumar Pandit wrote:
> hello every buddy
> 
> 
> in my gnu radio, when i run in QT GUI  and use qt-gui instrument i
> gor such a message
> 
> Registered DEC:  true Registered event listener change listener:
> true

> 
> 
> what dies this mean, please guide me ,,, clear it why this
> comes...and how can be avoided
> 
> 
> 
> ___ 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/

iQEcBAEBAgAGBQJSspHtAAoJEAFxB7BbsDrLNg4H/3ZOyFodKKZSii2AsiOUN8Wy
qp7GGbBv11MQLEYZYrVjeeY/4HxwybcVjr/ApAZUCGsZq2BoWT2532uuMM/XmsJG
xZVBLMaKGF0Mf4UTTfdbYumNch9kMHpniVlLBi5HK0+30aUyNhi+VGmEE/rh7trW
RNp7KuVpAqRmTgt5M8K6SwtdDGeoQXFGCIi3n+wr5/D3k7fBJBbuQ5EpulZydW9U
IDlTUknRDV7BWGi8colkMXx+KRhywJKNTQlcJQ8Jq3CMmJdZ4XJhpEPwS/Ghb3PP
gWzhnWA3iLBGBHgFKBnlxGYqxjJV4/R6+34sefBl0NAqcpyRTOXpv4PXLtG/7SI=
=t8KM
-END PGP SIGNATURE-

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

[Discuss-gnuradio] Error with Clang block

[MChti]

Hi everybody,

I try tu use the Clang block from the GRAS package but when I lauch my flow
graph, I can read this error.
Would you have any idea about what is wrong ?

Thank You
MChti



Executing: "/home/winston/Documents/gnuradio/test/top_block.py"

GRAS: The debug asserts are enabled. <<<
Created default thread pool with 2 threads.
GRAS compiler: compile source into bitcode...
   -emit-llvm -c -x c++ /tmp/filebDt8bS -o /tmp/fileFF1fbT -O3
-I/usr/local/include 
sh: 1: -emit-llvm: not found
Traceback (most recent call last):
  File "/home/winston/Documents/gnuradio/test/top_block.py", line 61, in

tb = top_block()
  File "/home/winston/Documents/gnuradio/test/top_block.py", line 35, in
__init__
   
gras.jit_factory(open("/home/winston/Documents/gnuradio/test/test2.cpp").read(),
["-O3"])
  File "/usr/local/lib/python2.7/dist-packages/gras/GRAS_Factory.py", line
190, in py_jit_factory
jit_factory(*args)
RuntimeError: GRAS compiler: error system exec clang
Done





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

[Discuss-gnuradio] i got such a message when run qt-gui

[Maheshkumar Pandit]

hello every buddy


  in my gnu radio, when i run in QT GUI  and use qt-gui
instrument i gor such a message

Got bus address:
"unix:abstract=/tmp/dbus-ZqX6rpDyRY,guid=b3eabb1d7a1550be2db27652002b"
Connected to accessibility bus at:
"unix:abstract=/tmp/dbus-ZqX6rpDyRY,guid=b3eabb1d7a1550be2db27652002b"
Registered DEC:  true
Registered event listener change listener:  true
Using Volk machine: avx_32_mmx


what dies this mean, please guide me ,,,
clear it why this comes...and how can be avoided

-- 
*Thanks and regard:*


*MR.Maheshkumar Pandit*

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

[Discuss-gnuradio] is the USRP-hw still available now?

[??????]

hi,everyone:  as i am new to RF pcb layout , i want the USRP daughter board PCB 
file to reference,i found a floder at 
"/root/usrp-hw"(http://gnuradio.org/redmine/projects/gnuradio/repository/revisions/8c8eeca9e2ae26c30f186bef23411d345acbc3f6/show/usrp-hw)


but i found some of those pcb files are created by gEDA(like tvrf.pcb).but 
others like rfx900.pcb,i wonder they are created by which tool?
as i tried,they are not created by those tools: altium 
designer/protel/gEDA/powerPCB.


plz help me if you know how to open them,thank you.


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

Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1

[George]

Tom, 

Is there going to be a fix soon or should I go with the 3.6.5 version of 
gnuradio?

Thanks,
-George

On Dec 18, 2013, at 7:01 PM, George  wrote:

> Hi Tom, 
> 
> You are right increasing the number of taps by 100 is not the case, after I 
> debugged the results a bit more.
> The problem seems to be in the number of samples consumed as you mentioned 
> above.
> 
> The full definition for the filter I am using is 
> firdes.root_raised_cosine(nfilts, 1.0, 1.0/nfilts, rolloff, 
> int(11*spb*nfilts))
> where nfilts=32, rolloff=0.35 and spb =4
> 
> Thanks,
> -George
> 
> On Dec 18, 2013, at 5:54 PM, Tom Rondeau  wrote:
> 
>> On Tue, Dec 17, 2013 at 9:06 PM, George  wrote:
>>> Hello all,
>>> 
>>> Considering a simple gnuradio flowgraph as the following
>>> 
>>> Random source -> chunks2symbols -> complex2float -> float2complex -> 
>>> pfb_arb_resampler-> USRP sink
>>> 
>>> which used to work without any problem in the older gnuradio distributions, 
>>> in the newer 3.7.2.1 seems that the conversion above (from complex to float 
>>> and float to complex) introduces a problem, that has to do with USRP 
>>> transmissions.
>>> 
>>> However, when I increased the number of taps used for the root raised 
>>> cosine filter in pfb_arb_resampler by a factor of 100, everything seems to 
>>> work properly.
>>> 
>>> Note that if the conversions float2complex and complex2float miss 
>>> everything works.
>>> 
>>> Any ideas why?
>>> 
>>> Thanks,
>>> -George
>> 
>> Bug it the pfb_arb_resampler. I was trying to be too conscientious
>> about calls to work but made an assumption in the forecast function
>> that's not always correct. I'm testing a few things out, still, but I
>> should push this fix soon.
>> 
>> Still, your behavior of the filter length (increasing it by 100, that
>> is) doesn't fit with what I'm seeing. What's the full filter
>> definition you're using for the block?
>> 
>> Tom
> 


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

Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1

[George]

Hi Tom, 

You are right increasing the number of taps by 100 is not the case, after I 
debugged the results a bit more.
The problem seems to be in the number of samples consumed as you mentioned 
above.

The full definition for the filter I am using is 
firdes.root_raised_cosine(nfilts, 1.0, 1.0/nfilts, rolloff, int(11*spb*nfilts))
where nfilts=32, rolloff=0.35 and spb =4

Thanks,
-George

On Dec 18, 2013, at 5:54 PM, Tom Rondeau  wrote:

> On Tue, Dec 17, 2013 at 9:06 PM, George  wrote:
>> Hello all,
>> 
>> Considering a simple gnuradio flowgraph as the following
>> 
>> Random source -> chunks2symbols -> complex2float -> float2complex -> 
>> pfb_arb_resampler-> USRP sink
>> 
>> which used to work without any problem in the older gnuradio distributions, 
>> in the newer 3.7.2.1 seems that the conversion above (from complex to float 
>> and float to complex) introduces a problem, that has to do with USRP 
>> transmissions.
>> 
>> However, when I increased the number of taps used for the root raised cosine 
>> filter in pfb_arb_resampler by a factor of 100, everything seems to work 
>> properly.
>> 
>> Note that if the conversions float2complex and complex2float miss everything 
>> works.
>> 
>> Any ideas why?
>> 
>> Thanks,
>> -George
> 
> Bug it the pfb_arb_resampler. I was trying to be too conscientious
> about calls to work but made an assumption in the forecast function
> that's not always correct. I'm testing a few things out, still, but I
> should push this fix soon.
> 
> Still, your behavior of the filter length (increasing it by 100, that
> is) doesn't fit with what I'm seeing. What's the full filter
> definition you're using for the block?
> 
> Tom


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

Re: [Discuss-gnuradio] Arbitrary resampler question on gnuradio 3.7.2.1

[Tom Rondeau]

On Tue, Dec 17, 2013 at 9:06 PM, George  wrote:
> Hello all,
>
> Considering a simple gnuradio flowgraph as the following
>
> Random source -> chunks2symbols -> complex2float -> float2complex -> 
> pfb_arb_resampler-> USRP sink
>
> which used to work without any problem in the older gnuradio distributions, 
> in the newer 3.7.2.1 seems that the conversion above (from complex to float 
> and float to complex) introduces a problem, that has to do with USRP 
> transmissions.
>
> However, when I increased the number of taps used for the root raised cosine 
> filter in pfb_arb_resampler by a factor of 100, everything seems to work 
> properly.
>
> Note that if the conversions float2complex and complex2float miss everything 
> works.
>
> Any ideas why?
>
> Thanks,
> -George

Bug it the pfb_arb_resampler. I was trying to be too conscientious
about calls to work but made an assumption in the forecast function
that's not always correct. I'm testing a few things out, still, but I
should push this fix soon.

Still, your behavior of the filter length (increasing it by 100, that
is) doesn't fit with what I'm seeing. What's the full filter
definition you're using for the block?

Tom

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

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

[Sebastian Schmid]

Hello everybody,

I'm trying to do some channel measurements using a setup based on three 
PCs with two USRP2 devices (equipped with RFX2400 daughterboards) and 
GNU Radio 3.7.
One of the PCs acts as network controller, it creates data the other PCs 
should transceive. The network controller therefore iFFT processes some 
random data and tells the two daemons what the have to send. If the USRP 
of one of the daemons receives something the received data gets 
delivered back to the network controller, which FFT processes the data 
and does some calculations.


So the GNU Radio action is happening only on the daemons. From the 
transmitter point of view it's just adding the cyclic prefix, on 
receivers point of view there is a Schmidl & Cox correlator for 
synchronization and a block picking the samples of the payload.
The (i)FFT stuff is happening on the network controller, using NumPys 
FFT implementation.


My predecessor (whom I sadly can't ask) built this communication system 
and used a decimation factor of 16 and a FFT size of 64.
Now I wanted to try a different FFT size. I expected this modification 
to be straightforward, just changing values and using a proper, low PAPR 
preamble.
However, I tried it with FFT sizes of 32, 96 and 128 - still with a 
decimation factor of 16 - and had no success. Bit error rates were far 
too high (about 40%).


I looked into some log files and found that apparently at least the 
Schmidl & Cox correlator and the payload picking block is working, it 
catches the frame start and delivers the amount of samples needed for 
the FFT. Please notice, as already mentioned above, that I do the FFT 
with NumPy on the network controller after transmission has finished. 
Now if I compare the post FFT / frequency domain received data with the 
sent data, looking at the argument differences I can observe some 
strange values:
I would expect a straight line with an slope (which I could correct by 
equalizing), as in this figure: 
http://abload.de/img/nfft32_decfac32l2sy3.png
Please ignore the "jumps" by 2*pi (or 360°) and keep in mind it's drawn 
using Matlab, this means one-based indexing, therefore ignore subcarrier 
17 as it's the DC carrier.


Instead, I get some random jumps by pi on some of the carriers, as seen 
in this figure:

http://abload.de/img/nfft32_decfac163qsri.png

This happens with all FFT sizes I tried except the original FFT size of 
64 if I keep the decimation factor of 16.


Now I noticed that there seems to be some correlation with the 
decimation factor:
If I choose a decimation factor, so that the ratio between FFT size and 
sampling rate is the same as in my original and correctly working setup 
(FFT size: 64, decimation factor: 16, so about 100 kHz per subcarrier) , 
everything seems to work properly. The BER is low and comparing the 
argument of sent vs. received data I can see the expected line without 
any random jumps. This behaviour I could observe with FFT size 32 (using 
a decimation factor of 32) and 96 (using a decimation factor of 12) - 
with other decimation factors I didn't work.


Now I'm trying to understand this phenomenon. I expected, that I would 
be able to change FFT size without touching decimation factor. At least 
I thought that using less FFT bins with the same decimation factor 
shouldn't harm, giving each subcarrier more bandwidth.


It would be great if someone could help me regarding this problem as I'm 
quite confused now and don't really know what to do.


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

[Discuss-gnuradio] new Qt blocks and other helpful blocks

[Johannes Demel]

Hi everybody,

some time ago I stumbled over the problem that I missed a Qt version of
some blocks. In particular I wanted to have a Qt numbersink and a Compass.
Thus, I created them [1] with Qt designer and integrated them into a GR
block. For now, they use Python. There are '.ui' files that have to be used
to generate the '.py' files manually with pyuic4. Then they should install
along with the other blocks.
Along with the Qt blocks I converted one of the gr-specest blocks 'DOA
MUSIC' to the GR 3.7 API. The code I used for this is from Balint Seeber's
gr-baz.
Also I wanted to have a Qt version of uhd_fft. But I didn't want to add
code to the generated .py file. This lead to the creation of a 'Catch
Function Result' block. It is a pure xml block which calls another blocks
member function and stores the result into its own variable. I didn't want
to use 'Function Probe' because I don't want to spawn a new thread which
constantly calls a function.

For those of you who are eager to try those blocks. The uhd_fft_qt
flowgraph can be found in the projects examples folder.

In the hope that those blocks are helpful for others.
Johannes

[1] https://github.com/jdemel/gr-misc
___
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 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
wrote:

> Hi,
>
> after opening and generating the hier blocks still the top_level.grc has
> missing blocks, at least LTE estimator outputs and unpack MIB inputs are
> unconnected, leaving a large white area in between. How should this
> flowgraph look like, is there a screenshot available somewhere?
>
> Just wanted to put this all together in my lunch break, but seems too big
> for such a short break anyway :)
>
> 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: Sunday, 15 December, 2013 00:34
> > To: discuss-gnuradio
> > Subject: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
> >
> > Hello GNU Radio enthusiasts,
> >
> > some time after the GNU Radio 3.7 release I started to move the code for
> 'gr-lte' to the new API. Besides moving it to the new API, I
> > wanted to clean up code and rework a lot of tests. Thus, the whole
> transition took a lot of time and work.
> > Now, all current blocks are moved to the GNU Radio 3.7 API with lots of
> enhancements. e.g. I tried to remove all hierarchical python blocks
> > and created them as GRC hier blocks instead. Or runtime status events,
> like cell_id extraction, are all propagated through message ports
> > now.
> > Also, there is a PyBOMBS recipe now to ease the installation process.
> >
> > I hope 'gr-lte' can be useful for others.
> >
> > Source code is available at https://github.com/kit-cel/gr-lte
> >
> > Happy hacking
> > Johannes
> >
> > ___
> > 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
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Fwd: problem with top_block.stop()

[Sumedha Goyal]

Hi

I used a blank work() function as follows

def work(self,ins,outs):
 print " i m in work "
self.mark_done()

using "mark_done(), I got the control back in the main loop.

When I use my specific work() function with  mark_done() after a successful
event, I get following error message:

ASSERT FAIL
/usr/local/software/gnuradio-3.6.4.2/gras/lib/gras_impl/output_buffer_queues.hpp:60
not this->empty(i)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gras/GRAS_PyBlock.py", line
230, in _Py_work
ret = self.work(input_arrays, output_arrays)
  File "/usr/local/software/working_TRANS_19/new_split_tx.py", line 304, in
work

self.send_pkt_phy(self.outgoing_msg,self.arq_expected_sequence_no,self.h,DATA_PKT)
  File "/usr/local/software/working_TRANS_19/new_split_tx.py", line 324, in
send_pkt_phy
buff = self.get_output_buffer(PHY_PORT)
  File "/usr/local/lib/python2.7/dist-packages/gras/GRAS_Block.py", line
231, in get_output_buffer
def get_output_buffer(self, *args, **kwargs): return
_GRAS_Block.Block_get_output_buffer(self, *args, **kwargs)
RuntimeError: ASSERT FAIL not this->empty(i)


Could you help me in sorting this out?

Regards,
Sumedha



On Wed, Dec 18, 2013 at 10:23 PM, Tom Rondeau  wrote:

> On Wed, Dec 18, 2013 at 11:29 AM, Sumedha Goyal 
> wrote:
> > Hi Tom,
> >
> > I have removed tb.wait(). Now the sequence is
> >
> > tb=top_block(options,0.8)
> > tb.start()
> > sleep(3)
> > tb.stop()
> >
> > I want my program to stop here and take new values which is not happening
> > right now. It executes till sleep(3) and then hangs somewhere.
>
> Sounds like an internal problem with your block.
>
> > You have asked to stop the flowgraph internally, kindly suggest a way to
> do
> > that. As I have mentioned earlier too, I have an event in the work()
> > function which when occurs the flowgraph should be terminated.
> > I tried using thread.exit in work function but unfortunately it is
> > terminating the whole program.
> >
> > Kindly suggest a way to bring the control back to main loop.
> >
> > Regards,
> > Sumedha
>
> Don't use thread.exit (pretty much ever). This sounds like you have
> something wrong with the threading model in your block. You a source
> block from GNU Radio (analog.sig_source_c or something) just to make
> sure the rest of the flowgraph is behaving properly. That is, that
> tb.stop is actually stopping the flowgraph. Then go back and try and
> debug your block.
>
> Tom
>
>
>
> > On Wed, Dec 18, 2013 at 8:43 PM, Tom Rondeau  wrote:
> >>
> >> On Wed, Dec 18, 2013 at 1:39 AM, Sumedha Goyal 
> >> wrote:
> >> >
> >> >
> >> > -- Forwarded message --
> >> > From: Sumedha Goyal 
> >> > Date: Wed, Dec 18, 2013 at 10:50 AM
> >> > Subject: Re: [Discuss-gnuradio] problem with top_block.stop()
> >> > To: Tom Rondeau 
> >> >
> >> >
> >> > Hi
> >> > My flowgraph does not stop naturally. I want to stop and start it
> again
> >> > using different value for a parameter as shown in my above question.
> >> > There is an event in my program where the flowgraph finishes it's job
> >> > with
> >> > first parameter value (which is 0.8 here), at the occurrence of that
> >> > event I
> >> > want the control of flowgraph to come back to the main(). Then I want
> to
> >> > restart the flowgraph with a new parameter value (which is 0.4 here).
> >> > Kindly guide me on this.
> >> >
> >> > Also, can I forcibly bring the control back to main() even when the
> >> > flowgraph doesn't have anything to stop its execution?
> >> >
> >> > Thanks and Regards,
> >> > Sumedha
> >>
> >>
> >> As I said, tb.wait() is a blocking call. If there is nothing to stop
> >> your flowgraph, you will continue to block at the tb.wait() line
> >> forever. If it helps, the top_block is implemented as a multi-threaded
> >> application where each block is in its own thread. The tb.wait()
> >> performs a thread join() on all threads in the flowgraph. So the
> >> flowgraph must exit before wait will exit. You have to stop your
> >> flowgraph internally somehow to continue.
> >>
> >> Tom
> >>
> >>
> >>
> >> > On Tue, Dec 17, 2013 at 11:24 PM, Tom Rondeau 
> wrote:
> >> >>
> >> >> On Tue, Dec 17, 2013 at 12:23 PM, Sumedha Goyal <
> sumedha1...@gmail.com>
> >> >> wrote:
> >> >> > I am trying to pass two different parameters to my top_block class
> >> >> > I m not able to do this please help. The control of program gets
> >> >> > stuck
> >> >> > at
> >> >> > tb.stop() and doesn't go beyond that.
> >> >> >
> >> >> > tb=top_block(options,0.8)
> >> >> > tb.start()
> >> >> > tb.wait()
> >> >> > tb.stop()
> >> >> > sleep(5)
> >> >> > print "I AM BACK"
> >> >> > tb1=top_block(options,0.4)
> >> >> > tb1.start()
> >> >> > tb1.wait()
> >> >> > tb1.stop()
> >> >> > sleep()
> >> >> >
> >> >> > Regards,
> >> >> > Sumedha
> >> >>
> >> >> Does your flowgraph in tb naturally stop? The tb.wait() is a blocking
> >> >> call and will halt the main loop there until all threads (blocks) in
> >> >> tb are done. If your 

[Discuss-gnuradio] about gr-modtool

[alex]

Hi all,

I meet a problem with gr-modtool. I created a new out of tree mode. 
Compile and install work fine but when I want to create the GRC module 
via gr-modtool makexml, give me the following error.


No GNU Radio module found in the given directory. Quitting.

PS, I am quite sure I am in the right folder to run gr-modtool makexml.  
Does anybody meet this problem?


Best regards

Alex

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

Re: [Discuss-gnuradio] help me

[Tom Rondeau]

On Wed, Dec 18, 2013 at 11:38 AM, Maheshkumar Pandit
 wrote:
> hello every buddy
>
>as we know in any plot lik water flow or fft sink there is
> positive and negative values are present . if we want to present only ssb
> i.e. positive or negative  value .
>
> how it can be done 
>
> help me if any one done the same ...
>
> --
> Thanks and regard:
>
> MR.Maheshkumar Pandit

I'm not entirely sure what you mean. What plotting tools are you
using? When using the QTGUI, you can always zoom over just the
positive frequency.

Tom

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

Re: [Discuss-gnuradio] Fwd: problem with top_block.stop()

[Tom Rondeau]

On Wed, Dec 18, 2013 at 11:29 AM, Sumedha Goyal  wrote:
> Hi Tom,
>
> I have removed tb.wait(). Now the sequence is
>
> tb=top_block(options,0.8)
> tb.start()
> sleep(3)
> tb.stop()
>
> I want my program to stop here and take new values which is not happening
> right now. It executes till sleep(3) and then hangs somewhere.

Sounds like an internal problem with your block.

> You have asked to stop the flowgraph internally, kindly suggest a way to do
> that. As I have mentioned earlier too, I have an event in the work()
> function which when occurs the flowgraph should be terminated.
> I tried using thread.exit in work function but unfortunately it is
> terminating the whole program.
>
> Kindly suggest a way to bring the control back to main loop.
>
> Regards,
> Sumedha

Don't use thread.exit (pretty much ever). This sounds like you have
something wrong with the threading model in your block. You a source
block from GNU Radio (analog.sig_source_c or something) just to make
sure the rest of the flowgraph is behaving properly. That is, that
tb.stop is actually stopping the flowgraph. Then go back and try and
debug your block.

Tom



> On Wed, Dec 18, 2013 at 8:43 PM, Tom Rondeau  wrote:
>>
>> On Wed, Dec 18, 2013 at 1:39 AM, Sumedha Goyal 
>> wrote:
>> >
>> >
>> > -- Forwarded message --
>> > From: Sumedha Goyal 
>> > Date: Wed, Dec 18, 2013 at 10:50 AM
>> > Subject: Re: [Discuss-gnuradio] problem with top_block.stop()
>> > To: Tom Rondeau 
>> >
>> >
>> > Hi
>> > My flowgraph does not stop naturally. I want to stop and start it again
>> > using different value for a parameter as shown in my above question.
>> > There is an event in my program where the flowgraph finishes it's job
>> > with
>> > first parameter value (which is 0.8 here), at the occurrence of that
>> > event I
>> > want the control of flowgraph to come back to the main(). Then I want to
>> > restart the flowgraph with a new parameter value (which is 0.4 here).
>> > Kindly guide me on this.
>> >
>> > Also, can I forcibly bring the control back to main() even when the
>> > flowgraph doesn't have anything to stop its execution?
>> >
>> > Thanks and Regards,
>> > Sumedha
>>
>>
>> As I said, tb.wait() is a blocking call. If there is nothing to stop
>> your flowgraph, you will continue to block at the tb.wait() line
>> forever. If it helps, the top_block is implemented as a multi-threaded
>> application where each block is in its own thread. The tb.wait()
>> performs a thread join() on all threads in the flowgraph. So the
>> flowgraph must exit before wait will exit. You have to stop your
>> flowgraph internally somehow to continue.
>>
>> Tom
>>
>>
>>
>> > On Tue, Dec 17, 2013 at 11:24 PM, Tom Rondeau  wrote:
>> >>
>> >> On Tue, Dec 17, 2013 at 12:23 PM, Sumedha Goyal 
>> >> wrote:
>> >> > I am trying to pass two different parameters to my top_block class
>> >> > I m not able to do this please help. The control of program gets
>> >> > stuck
>> >> > at
>> >> > tb.stop() and doesn't go beyond that.
>> >> >
>> >> > tb=top_block(options,0.8)
>> >> > tb.start()
>> >> > tb.wait()
>> >> > tb.stop()
>> >> > sleep(5)
>> >> > print "I AM BACK"
>> >> > tb1=top_block(options,0.4)
>> >> > tb1.start()
>> >> > tb1.wait()
>> >> > tb1.stop()
>> >> > sleep()
>> >> >
>> >> > Regards,
>> >> > Sumedha
>> >>
>> >> Does your flowgraph in tb naturally stop? The tb.wait() is a blocking
>> >> call and will halt the main loop there until all threads (blocks) in
>> >> tb are done. If your flowgraph doesn't have something that stops
>> >> execution (like a finite file or a blocks.head block), then it will
>> >> continue to process forever and your tb.wait() will continue to block.
>> >>
>> >> Tom
>> >
>> >
>> >
>> >
>> > ___
>> > 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
>

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

[Discuss-gnuradio] help me

[Maheshkumar Pandit]

hello every buddy

   as we know in any plot lik water flow or fft sink there is
positive and negative values are present . if we want to present only ssb
i.e. positive or negative  value .

how it can be done 

help me if any one done the same ...

-- 
*Thanks and regard:*


*MR.Maheshkumar Pandit*

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

Re: [Discuss-gnuradio] Fwd: problem with top_block.stop()

[Sumedha Goyal]

Hi Tom,

I have removed tb.wait(). Now the sequence is

tb=top_block(options,0.8)
tb.start()
sleep(3)
tb.stop()

I want my program to stop here and take new values which is not happening
right now. It executes till sleep(3) and then hangs somewhere.

You have asked to stop the flowgraph internally, kindly suggest a way to do
that. As I have mentioned earlier too, I have an event in the work()
function which when occurs the flowgraph should be terminated.
I tried using thread.exit in work function but unfortunately it is
terminating the whole program.

Kindly suggest a way to bring the control back to main loop.

Regards,
Sumedha


On Wed, Dec 18, 2013 at 8:43 PM, Tom Rondeau  wrote:

> On Wed, Dec 18, 2013 at 1:39 AM, Sumedha Goyal 
> wrote:
> >
> >
> > -- Forwarded message --
> > From: Sumedha Goyal 
> > Date: Wed, Dec 18, 2013 at 10:50 AM
> > Subject: Re: [Discuss-gnuradio] problem with top_block.stop()
> > To: Tom Rondeau 
> >
> >
> > Hi
> > My flowgraph does not stop naturally. I want to stop and start it again
> > using different value for a parameter as shown in my above question.
> > There is an event in my program where the flowgraph finishes it's job
> with
> > first parameter value (which is 0.8 here), at the occurrence of that
> event I
> > want the control of flowgraph to come back to the main(). Then I want to
> > restart the flowgraph with a new parameter value (which is 0.4 here).
> > Kindly guide me on this.
> >
> > Also, can I forcibly bring the control back to main() even when the
> > flowgraph doesn't have anything to stop its execution?
> >
> > Thanks and Regards,
> > Sumedha
>
>
> As I said, tb.wait() is a blocking call. If there is nothing to stop
> your flowgraph, you will continue to block at the tb.wait() line
> forever. If it helps, the top_block is implemented as a multi-threaded
> application where each block is in its own thread. The tb.wait()
> performs a thread join() on all threads in the flowgraph. So the
> flowgraph must exit before wait will exit. You have to stop your
> flowgraph internally somehow to continue.
>
> Tom
>
>
>
> > On Tue, Dec 17, 2013 at 11:24 PM, Tom Rondeau  wrote:
> >>
> >> On Tue, Dec 17, 2013 at 12:23 PM, Sumedha Goyal 
> >> wrote:
> >> > I am trying to pass two different parameters to my top_block class
> >> > I m not able to do this please help. The control of program gets stuck
> >> > at
> >> > tb.stop() and doesn't go beyond that.
> >> >
> >> > tb=top_block(options,0.8)
> >> > tb.start()
> >> > tb.wait()
> >> > tb.stop()
> >> > sleep(5)
> >> > print "I AM BACK"
> >> > tb1=top_block(options,0.4)
> >> > tb1.start()
> >> > tb1.wait()
> >> > tb1.stop()
> >> > sleep()
> >> >
> >> > Regards,
> >> > Sumedha
> >>
> >> Does your flowgraph in tb naturally stop? The tb.wait() is a blocking
> >> call and will halt the main loop there until all threads (blocks) in
> >> tb are done. If your flowgraph doesn't have something that stops
> >> execution (like a finite file or a blocks.head block), then it will
> >> continue to process forever and your tb.wait() will continue to block.
> >>
> >> Tom
> >
> >
> >
> >
> > ___
> > 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] Fwd: problem with top_block.stop()

[Tom Rondeau]

On Wed, Dec 18, 2013 at 1:39 AM, Sumedha Goyal  wrote:
>
>
> -- Forwarded message --
> From: Sumedha Goyal 
> Date: Wed, Dec 18, 2013 at 10:50 AM
> Subject: Re: [Discuss-gnuradio] problem with top_block.stop()
> To: Tom Rondeau 
>
>
> Hi
> My flowgraph does not stop naturally. I want to stop and start it again
> using different value for a parameter as shown in my above question.
> There is an event in my program where the flowgraph finishes it's job with
> first parameter value (which is 0.8 here), at the occurrence of that event I
> want the control of flowgraph to come back to the main(). Then I want to
> restart the flowgraph with a new parameter value (which is 0.4 here).
> Kindly guide me on this.
>
> Also, can I forcibly bring the control back to main() even when the
> flowgraph doesn't have anything to stop its execution?
>
> Thanks and Regards,
> Sumedha


As I said, tb.wait() is a blocking call. If there is nothing to stop
your flowgraph, you will continue to block at the tb.wait() line
forever. If it helps, the top_block is implemented as a multi-threaded
application where each block is in its own thread. The tb.wait()
performs a thread join() on all threads in the flowgraph. So the
flowgraph must exit before wait will exit. You have to stop your
flowgraph internally somehow to continue.

Tom



> On Tue, Dec 17, 2013 at 11:24 PM, Tom Rondeau  wrote:
>>
>> On Tue, Dec 17, 2013 at 12:23 PM, Sumedha Goyal 
>> wrote:
>> > I am trying to pass two different parameters to my top_block class
>> > I m not able to do this please help. The control of program gets stuck
>> > at
>> > tb.stop() and doesn't go beyond that.
>> >
>> > tb=top_block(options,0.8)
>> > tb.start()
>> > tb.wait()
>> > tb.stop()
>> > sleep(5)
>> > print "I AM BACK"
>> > tb1=top_block(options,0.4)
>> > tb1.start()
>> > tb1.wait()
>> > tb1.stop()
>> > sleep()
>> >
>> > Regards,
>> > Sumedha
>>
>> Does your flowgraph in tb naturally stop? The tb.wait() is a blocking
>> call and will halt the main loop there until all threads (blocks) in
>> tb are done. If your flowgraph doesn't have something that stops
>> execution (like a finite file or a blocks.head block), then it will
>> continue to process forever and your tb.wait() will continue to block.
>>
>> Tom
>
>
>
>
> ___
> 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] problem with top_block.stop()

[Kevin Reid]

On Dec 17, 2013, at 9:23, Sumedha Goyal  wrote:

> I am trying to pass two different parameters to my top_block class 
> I m not able to do this please help. The control of program gets stuck at 
> tb.stop() and doesn't go beyond that.
> 
> tb=top_block(options,0.8)
> tb.start()
> tb.wait()
> tb.stop()
> sleep(5)

If you want to stop a running flow graph you must not wait() for it first. 
wait() waits until either it is stopped or it completes naturally. Thus, you 
want this order of operations:

  tb=top_block(options,0.8)
  tb.start()
  sleep(5)
  tb.stop()
  tb.wait()

The wait() occurs last so that what it is waiting for is only for the stop() to 
complete, not for anything else.

-- 
Kevin Reid  


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

Re: [Discuss-gnuradio] Need help identifying jammer signal

[Patrik Tast]

Well done!

Patrik

On Tue, 2013-12-17 at 17:40 -0500, Juha Vierinen wrote:
> Last Friday we managed to finally track this thing down. It was a
> broken FSK telemetry system on an FM radio tower. It was about 30 km
> Southwest of our radar.
> 
> 
> I did a small write up about this:
> http://kaira.sgo.fi/2013/12/perfect-incoherent-scatter-radar-jammer.html
> 
> 
> 
> Thanks for all the help. 
> 
> 
> juha
> 
> 
> On Wed, Dec 11, 2013 at 4:34 PM, Johnathan Corgan
>  wrote:
> On 12/10/2013 02:00 PM, Miki Lustig - KK6GEO wrote:
> 
> > These look like 2pi jumps -- which is the an artifact if the
> > unwrapping is not working well.
> 
> 
> Sure, I see what you mean.
> 
> Backing up and just plotting the unwrapped phase, you can see
> in the
> first image that overall it is increasing at one rate, then
> shifts to a
> lower rate about 1.5 seconds into the file.
> 
> The finer structure is much more interesting.  The second
> image shows
> the phase making fast jumps every 500 samples (10 ms), with
> periods of
> oscillation in between.  The detail on this is in image 3.
> 
> I still have no idea what this is, but it sort of looks like
> an
> oscillator that is disciplined at 100 Hz.
> 
> --
> Johnathan Corgan, Corgan Labs
> SDR Training and Development Services
> http://corganlabs.com
> 
> 
> 
> ___
> 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]

Hi,

after opening and generating the hier blocks still the top_level.grc has 
missing blocks, at least LTE estimator outputs and unpack MIB inputs are 
unconnected, leaving a large white area in between. How should this flowgraph 
look like, is there a screenshot available somewhere? 

Just wanted to put this all together in my lunch break, but seems too big for 
such a short break anyway :)

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: Sunday, 15 December, 2013 00:34
> To: discuss-gnuradio
> Subject: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
> 
> Hello GNU Radio enthusiasts,
> 
> some time after the GNU Radio 3.7 release I started to move the code for 
> 'gr-lte' to the new API. Besides moving it to the new API, I
> wanted to clean up code and rework a lot of tests. Thus, the whole transition 
> took a lot of time and work.
> Now, all current blocks are moved to the GNU Radio 3.7 API with lots of 
> enhancements. e.g. I tried to remove all hierarchical python blocks
> and created them as GRC hier blocks instead. Or runtime status events, like 
> cell_id extraction, are all propagated through message ports
> now.
> Also, there is a PyBOMBS recipe now to ease the installation process.
> 
> I hope 'gr-lte' can be useful for others.
> 
> Source code is available at https://github.com/kit-cel/gr-lte
> 
> Happy hacking
> Johannes
> 
> ___
> 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] Need help identifying jammer signal

[Ralph A. Schmid, dk5ras]

Thanks for the follow-up, this is similar to a 1 second noise burst every 60
seconds or so we had on our ham repeater. The reason could be identified
after months of search by coincidence. The repeater sysop visited his
fathers office, monitored the input frequency of the repeater like he had
done routinely for months to hear exactly nothing - but there it was, some
wideband noise pulse! 100 m from this office a paging system for a facility
management team was sitting on a tower, not actively used for years, still
transmitting its beacon every minute, and with age the TX started emitting
noise along with its POCSAG signal. Gnuradio also would have been useful in
our case, but it was way before we knew of this exciting stuff :) 


Ralph.

 

 

From: discuss-gnuradio-bounces+ralph=schmid@gnu.org
[mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of Juha
Vierinen
Sent: Tuesday, December 17, 2013 11:41 PM
Cc: gnuradio mailing list
Subject: Re: [Discuss-gnuradio] Need help identifying jammer signal

 

Last Friday we managed to finally track this thing down. It was a broken FSK
telemetry system on an FM radio tower. It was about 30 km Southwest of our
radar.

 

I did a small write up about this:

http://kaira.sgo.fi/2013/12/perfect-incoherent-scatter-radar-jammer.html

 

Thanks for all the help. 

 

juha

 

On Wed, Dec 11, 2013 at 4:34 PM, Johnathan Corgan 
wrote:

On 12/10/2013 02:00 PM, Miki Lustig - KK6GEO wrote:

> These look like 2pi jumps -- which is the an artifact if the
> unwrapping is not working well.

Sure, I see what you mean.

Backing up and just plotting the unwrapped phase, you can see in the
first image that overall it is increasing at one rate, then shifts to a
lower rate about 1.5 seconds into the file.

The finer structure is much more interesting.  The second image shows
the phase making fast jumps every 500 samples (10 ms), with periods of
oscillation in between.  The detail on this is in image 3.

I still have no idea what this is, but it sort of looks like an
oscillator that is disciplined at 100 Hz.


--
Johnathan Corgan, Corgan Labs
SDR Training and Development Services
http://corganlabs.com

 

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