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

[Mike Cornelius]

Hi Johannes,

Further to my last email I just noticed that the tests that are failing are
failing because test vectors are not available eg
'/home/johannes/tests/descramble.dat'.

Mike


On 19 December 2013 18: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 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] gr-lte updated to GNU Radio 3.7 API

[Johannes Demel]

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 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
>

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

[Ralph A. Schmid, dk5ras]

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 :)

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 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

Re: [Discuss-gnuradio] about gr-modtool

[alex]

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

following is the CMakeFile.txt:


# Project setup

cmake_minimum_required(VERSION 2.6)
project(gr-zigbeesink CXX C)
enable_testing()

#select the release build type by default to get optimization flags
if(NOT CMAKE_BUILD_TYPE)
   set(CMAKE_BUILD_TYPE "Release")
   message(STATUS "Build type not specified: defaulting to release.")
endif(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE ${CMAKE_BUILD_TYPE} CACHE STRING "")

list(APPEND CMAKE_MODULE_PATH ${CMAKE_SOURCE_DIR}/cmake/Modules)


# Compiler specific setup

if(CMAKE_COMPILER_IS_GNUCXX AND NOT WIN32)
#http://gcc.gnu.org/wiki/Visibility
add_definitions(-fvisibility=hidden)
endif()


# Find boost

if(UNIX AND EXISTS "/usr/lib64")
list(APPEND BOOST_LIBRARYDIR "/usr/lib64") #fedora 64-bit fix
endif(UNIX AND EXISTS "/usr/lib64")
set(Boost_ADDITIONAL_VERSIONS
"1.35.0" "1.35" "1.36.0" "1.36" "1.37.0" "1.37" "1.38.0" "1.38" 
"1.39.0" "1.39"
"1.40.0" "1.40" "1.41.0" "1.41" "1.42.0" "1.42" "1.43.0" "1.43" 
"1.44.0" "1.44"
"1.45.0" "1.45" "1.46.0" "1.46" "1.47.0" "1.47" "1.48.0" "1.48" 
"1.49.0" "1.49"
"1.50.0" "1.50" "1.51.0" "1.51" "1.52.0" "1.52" "1.53.0" "1.53" 
"1.54.0" "1.54"
"1.55.0" "1.55" "1.56.0" "1.56" "1.57.0" "1.57" "1.58.0" "1.58" 
"1.59.0" "1.59"
"1.60.0" "1.60" "1.61.0" "1.61" "1.62.0" "1.62" "1.63.0" "1.63" 
"1.64.0" "1.64"
"1.65.0" "1.65" "1.66.0" "1.66" "1.67.0" "1.67" "1.68.0" "1.68" 
"1.69.0" "1.69"

)
find_package(Boost "1.35" COMPONENTS filesystem system)

if(NOT Boost_FOUND)
message(FATAL_ERROR "Boost required to compile zigbeesink")
endif()


# Install directories

include(GrPlatform) #define LIB_SUFFIX
set(GR_RUNTIME_DIR  bin)
set(GR_LIBRARY_DIR  lib${LIB_SUFFIX})
set(GR_INCLUDE_DIR  include/zigbeesink)
set(GR_DATA_DIR share)
set(GR_PKG_DATA_DIR ${GR_DATA_DIR}/${CMAKE_PROJECT_NAME})
set(GR_DOC_DIR  ${GR_DATA_DIR}/doc)
set(GR_PKG_DOC_DIR  ${GR_DOC_DIR}/${CMAKE_PROJECT_NAME})
set(GR_CONF_DIR etc)
set(GR_PKG_CONF_DIR ${GR_CONF_DIR}/${CMAKE_PROJECT_NAME}/conf.d)
set(GR_LIBEXEC_DIR  libexec)
set(GR_PKG_LIBEXEC_DIR  ${GR_LIBEXEC_DIR}/${CMAKE_PROJECT_NAME})
set(GRC_BLOCKS_DIR  ${GR_PKG_DATA_DIR}/grc/blocks)


# Find gnuradio build dependencies

set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS FILTER)
find_package(Gnuradio)
find_package(CppUnit)

# To run a more advanced search for GNU Radio and it's components and
# versions, use the following. Add any components required to the list
# of GR_REQUIRED_COMPONENTS (in all caps) and change "version" to the
# minimum API compatible version required.
#
# set(GR_REQUIRED_COMPONENTS RUNTIME BLOCKS FILTER ...)
# find_package(Gnuradio "version")

if(NOT GNURADIO_RUNTIME_FOUND)
message(FATAL_ERROR "GnuRadio Runtime required to compile zigbeesink")
endif()
if(NOT CPPUNIT_FOUND)
message(FATAL_ERROR "CppUnit required to compile zigbeesink")
endif()


# Setup the include and linker paths

include_directories(
${CMAKE_SOURCE_DIR}/include
${Boost_INCLUDE_DIRS}
${CPPUNIT_INCLUDE_DIRS}
${GNURADIO_RUNTIME_INCLUDE_DIRS}
${GNURADIO_ALL_INCLUDE_DIRS}
)

link_directories(
${Boost_LIBRARY_DIRS}
${CPPUNIT_LIBRARY_DIRS}
${GNURADIO_RUNTIME_LIBRARY_DIRS}
${GNURADIO_ALL_LIBRARIES}
)

# Set component parameters
set(GR_ZIGBEESINK_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/include CACHE 
INTERNAL "" FORCE)
set(GR_ZIGBEESINK_SWIG_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/swig 
CACHE INTERNAL "" FORCE)



# Create uninstall target

configure_file(
${CMAKE_SOURCE_DIR}/cmake/cmake_uninstall.cmake.in
${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake
@ONLY)

add_custom_target(uninstall
${CMAK

[Discuss-gnuradio] Some issues with Mac OS X (MacPorts) installed GnuRadio

[Rickard]

Hi,

Installing GnuRadio via MacPorts works very well and without efforts! 
Tried it both on 10.8 and 10.9  OSX:es. 
Finally, its a big improvement from earlier troubles of installing manually on 
OSX which could be very tricky and error prone. 
Many thanks to Michael Dickens!

However, on both systems I encounter some issues after installation (there may 
be more, haven’t tried GnuRadio extensively on OSX):

In a "Wx GUI Scope Sinc”  I cannot change/select the "Channel Options” such as 
“Ch1, Ch2, Trig, XY”. The buttons doesn’t respond.
Only “Coupling” and “Marker” options are possible to select and change values 
as normal.

Also, I get a lot of python and font related warnings when running a simple 
script, see below.

What am I missing in my installations?!

This relates to the MacPorts installation (also previous 3.7 versions):
gnuradio 
@3.7.2.1_0+docs+grc+jack+orc+portaudio+python27+qtgui+sdl+swig+uhd+wavelet+wxgui
 (active)

Help in resolving this is much appreciated although I use mainly GnuRadio on 
Linux machines.

Thanks in advance,
Rickard



Warning: failed to XInitThreads()
2013-12-19 12:38:08.982 Python[48260:507] CoreText performance note: Client 
called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with 
PostScript name ".LucidaGrandeUI". For best performance, only use PostScript 
names when calling this API.
2013-12-19 12:38:08.982 Python[48260:507] CoreText performance note: Set a 
breakpoint on CTFontLogSuboptimalRequest to debug.
2013-12-19 12:38:09.024 Python[48260:507] CoreText performance note: Client 
called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with 
PostScript name ".LucidaGrandeUI". For best performance, only use PostScript 
names when calling this API.
Using Volk machine: sse4_1_64_orc
2013-12-19 12:38:09.452 Python[48260:507] CoreText performance note: Client 
called CTFontCreateWithName() using name ".Lucida Grande UI" and got font with 
PostScript name ".LucidaGrandeUI". For best performance, only use PostScript 
names when calling this API.
...___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Some issues with Mac OS X (MacPorts) installed GnuRadio

[Michael Dickens]

Hi Rickard - I'm glad to hear of your successes with GNU Radio on OSX from 
MacPorts.  Wx on OSX is notorious for being slow and taking a lot of CPU time, 
and being non-multi-thread friendly.  I often have issues getting any wx GUI 
working in "real time" ... I use the Qt GUI when possible since it actually 
works, and it provides a much greater feature set.  I wish we could use Qwt 6+, 
but that's not the way MacPorts works ... so we're limited to Qwt 5.2.  All of 
the warnings and notes you list are normal when running on 10.9 and using wx.  
We're working on getting rid of the XInitThreads warning; the rest come from wx 
and I certainly have to believe that the wx developers know about this and are 
working on it.  So ... I think what this means is that you have a normal GR 
install, working about as expected.  Try the Qt GUI if you can use it instead 
:) - MLD

On Dec 19, 2013, at 7:15 AM, Rickard  wrote:

> In a "Wx GUI Scope Sinc”  I cannot change/select the "Channel Options” such 
> as “Ch1, Ch2, Trig, XY”. The buttons doesn’t respond.
> Only “Coupling” and “Marker” options are possible to select and change values 
> as normal.
> 
> Also, I get a lot of python and font related warnings when running a simple 
> script, see below.
> 
> Warning: failed to XInitThreads()
> 2013-12-19 12:38:08.982 Python[48260:507] CoreText performance note: Client 
> called CTFontCreateWithName() using name ".Lucida Grande UI" and got font 
> with PostScript name ".LucidaGrandeUI". For best performance, only use 
> PostScript names when calling this API.
> 2013-12-19 12:38:08.982 Python[48260:507] CoreText performance note: Set a 
> breakpoint on CTFontLogSuboptimalRequest to debug.
> 2013-12-19 12:38:09.024 Python[48260:507] CoreText performance note: Client 
> called CTFontCreateWithName() using name ".Lucida Grande UI" and got font 
> with PostScript name ".LucidaGrandeUI". For best performance, only use 
> PostScript names when calling this API.
> Using Volk machine: sse4_1_64_orc
> 2013-12-19 12:38:09.452 Python[48260:507] CoreText performance note: Client 
> called CTFontCreateWithName() using name ".Lucida Grande UI" and got font 
> with PostScript name ".LucidaGrandeUI". For best performance, only use 
> PostScript names when calling this API.
> 

--
Michael Dickens, Mac OS X Programmer
Ettus Research Technical Support
Email: supp...@ettus.com
Web: http://www.ettus.com


___
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 Wed, Dec 18, 2013 at 7:47 PM, George  wrote:
> Tom,
>
> Is there going to be a fix soon or should I go with the 3.6.5 version of 
> gnuradio?
>
> Thanks,
> -George

George,

The patch was pushed last night. I will make it into the next bug
release, which will probably be in a month, plus or minus. In the
meantime, you can get the patch by looking at commit
b3b8a1f4965f8283f2c3d22ae45b569b2fe6d713

Tom



> 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

[Discuss-gnuradio] Error with latest 3.7 build

[Ralph A. Schmid, dk5ras]

Hi,

The last git pull brings me this one below; any ideas what went wrong?
Kubuntu 12.04 32bit, the pull a few days ago ran through just fine, deleting
the build folder, cmake .., make changes nothing.

With best regards

Ralph.


[ 66%] Built target pygen_gr_pager_swig_cf5bb [ 67%] Built target
pygen_gr_pager_apps_f9137 [ 67%] Building CXX object
gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/DisplayPlot.cc.o
/home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:95:2: error: #else without
#if
/home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:100:2: error: #endif without
#if
/home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc: In constructor
‘DisplayPlot::DisplayPlot(int, QWidget*)’:
/home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:96:18: error: ‘class
QwtLegend’ has no member named ‘setDefaultItemMode’
/home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:96:37: error: ‘QwtLegendData’
has not been declared
make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/DisplayPlot.cc.o]
Error 1
make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
make: *** [all] Error 2



--

Ralph A. Schmid
Mondstr. 10
90762 Fürth
+49-171-3631223
ra...@schmid.xxx
http://www.bclog.de/






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

Re: [Discuss-gnuradio] Error with latest 3.7 build

[Tom Rondeau]

On Thu, Dec 19, 2013 at 9:35 AM, Ralph A. Schmid, dk5ras
 wrote:
> Hi,
>
> The last git pull brings me this one below; any ideas what went wrong?
> Kubuntu 12.04 32bit, the pull a few days ago ran through just fine, deleting
> the build folder, cmake .., make changes nothing.
>
> With best regards
>
> Ralph.
>
>
> [ 66%] Built target pygen_gr_pager_swig_cf5bb [ 67%] Built target
> pygen_gr_pager_apps_f9137 [ 67%] Building CXX object
> gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/DisplayPlot.cc.o
> /home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:95:2: error: #else without
> #if
> /home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:100:2: error: #endif without
> #if
> /home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc: In constructor
> ‘DisplayPlot::DisplayPlot(int, QWidget*)’:
> /home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:96:18: error: ‘class
> QwtLegend’ has no member named ‘setDefaultItemMode’
> /home/ras/gnuradio/gr-qtgui/lib/DisplayPlot.cc:96:37: error: ‘QwtLegendData’
> has not been declared
> make[2]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/DisplayPlot.cc.o]
> Error 1
> make[1]: *** [gr-qtgui/lib/CMakeFiles/gnuradio-qtgui.dir/all] Error 2
> make: *** [all] Error 2

I have absolutely no clue what happened here. There was a fix on maint
to allow use of Qwt 6.1 yesterday, but somehow when I merged maint
into master, this file got corrupted. I'm looking at it now; should be
able to push a fix soon.

Tom

___
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

[Philip Balister]

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 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
>>> 
>>> > 

Re: [Discuss-gnuradio] Error with latest 3.7 build

[Ralph A. Schmid, dk5ras]

Hi,

> I have absolutely no clue what happened here. There was a fix on maint to
> allow use of Qwt 6.1 yesterday, but somehow when I merged maint into
> master, this file got corrupted. I'm looking at it now; should be able to
push a
> fix soon.

Thank you for the fast reply - so I was not wrong in the assumption, it
should not have been my fault. No need to hurry :) 
 
> Tom

Ralph.



___
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

[Tom Rondeau]

On Mon, Dec 16, 2013 at 4:02 PM, Nowlan, Sean
 wrote:
> I’m trying to learn the message passing API by reviewing the examples in
> gr-blocks/examples/msg_passing. Message ports are not connected upon opening
> GRC (this seems to be a gnuradio-wide problem – same thing happens with
> gr-ieee802-11). I know the workaround is to open each hier block and build
> so that code gets put in ~/.grc_gnuradio. However, I’m not sure how to hook
> up the ports as they were intended. Does anybody have screen captures of
> strobe.grc, test_msg_hier.grc, and test_msg_hier_topblock.grc with the ports
> connected correctly?
>
>
> Thanks,
> Sean


I wonder if the message connection problem is due to a fairly recent
change in how the message connections are displayed? We changed it
from a solid to a dashed line to make it easier to identify the
different types of connections.  Hopefully, once the connections are
remade using the new code, it'll stay that way. I'll try to fix things
up on my end and push the changes.

Sebastian, do you have any comments on this?

Tom

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

Re: [Discuss-gnuradio] SNR or Other Metrics

[Tom Rondeau]

On Mon, Dec 16, 2013 at 11:22 PM, Dan CaJacob  wrote:
> I'd like to report some signal metrics for satellite downlinks.  SNR would
> seem to be one example, but most algorithms I see for SNR assume that you
> are generating a signal from a separate clean signal and noise source, each
> with known power.  What I have are recordings of real, narrow-band, digital
> FM signals.  I don't have a very strong DSP background.
>
> Can anyone point me to a good textbook that covers such practical
> applications?
>
> Thanks for your help!

Hi Dan,

SNR estimations are quite tricky in real life. If you look at the
digital::mpsk_snr_est blocks, there are multiple implementation inside
that do SNR estimations for M-ary PSK constellations. The different
algorithms have varying accuracy and (mostly) proportional complexity.
But as the name implies, this won't work for FM.

Looking at Google, I found a short paper from Virginia Tech,
co-authored by Steve Ellingson. I know Steve a bit, though he came
just as I was finishing up my work there, and he tends to be pretty
good with these things. So it's likely a good start mathematically for
what you need.

http://www.ece.vt.edu/swe/asmr/docs/ASMR_R16_Kumar2.pdf

Tom

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

Re: [Discuss-gnuradio] SNR or Other Metrics

[Dan CaJacob]

Thanks, Tom!  Yeah, I have avoided the MPSK SNR blocks because I figured
they were specific to PSK.

Very Respectfully,

Dan CaJacob


On Thu, Dec 19, 2013 at 10:30 AM, Tom Rondeau  wrote:

> On Mon, Dec 16, 2013 at 11:22 PM, Dan CaJacob 
> wrote:
> > I'd like to report some signal metrics for satellite downlinks.  SNR
> would
> > seem to be one example, but most algorithms I see for SNR assume that you
> > are generating a signal from a separate clean signal and noise source,
> each
> > with known power.  What I have are recordings of real, narrow-band,
> digital
> > FM signals.  I don't have a very strong DSP background.
> >
> > Can anyone point me to a good textbook that covers such practical
> > applications?
> >
> > Thanks for your help!
>
> Hi Dan,
>
> SNR estimations are quite tricky in real life. If you look at the
> digital::mpsk_snr_est blocks, there are multiple implementation inside
> that do SNR estimations for M-ary PSK constellations. The different
> algorithms have varying accuracy and (mostly) proportional complexity.
> But as the name implies, this won't work for FM.
>
> Looking at Google, I found a short paper from Virginia Tech,
> co-authored by Steve Ellingson. I know Steve a bit, though he came
> just as I was finishing up my work there, and he tends to be pretty
> good with these things. So it's likely a good start mathematically for
> what you need.
>
> http://www.ece.vt.edu/swe/asmr/docs/ASMR_R16_Kumar2.pdf
>
> Tom
>
___
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]

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 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
 

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

[Johannes Demel]

Hi Mike,

just saw this mail. Basically this means that you're using an old
version. Newer versions don't use these files any more. I recommend
updating your gr-lte version. It runs on GR 3.7 now, so you don't have
to worry about an old version there and I put in all the bugfixes into
the latest master branch.
Besides that, which version do you use exactly?

Happy hacking
Johannes

On 18.12.2013 23:59, Mike Cornelius wrote:
> Hi Johannes,
> 
> Further to my last email I just noticed that the tests that are failing
> are failing because test vectors are not available eg
> '/home/johannes/tests/descramble.dat'.
> 
> Mike
> 
> 
> On 19 December 2013 18: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 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
> >   

Re: [Discuss-gnuradio] Error with latest 3.7 build

[Tom Rondeau]

On Thu, Dec 19, 2013 at 9:49 AM, Ralph A. Schmid, dk5ras
 wrote:
> Hi,
>
>> I have absolutely no clue what happened here. There was a fix on maint to
>> allow use of Qwt 6.1 yesterday, but somehow when I merged maint into
>> master, this file got corrupted. I'm looking at it now; should be able to
> push a
>> fix soon.
>
> Thank you for the fast reply - so I was not wrong in the assumption, it
> should not have been my fault. No need to hurry :)
>
>> Tom
>
> Ralph.


Ok, pushed the fix.

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

[Koslowski, Sebastian (CEL)]

Was offline this week...

I looked at the example in gr-blocks and this is not an issue with the
way connections are displayed. Sean, you should see some error messages
in the console detailing which connections (including their blocks and
ports) could not be made. That should help to reconstruct the original
connections.

In any case, the reason for these connections not been made is change of
the way message ports are identified within GRC. Up until recently a
numeric index (same as the stream ports) was used which caused problems
with using "nports" tags. Now, the message port name is used as key
because it is more consistent with the 'connect' method calls. This is
the root cause of what your experiencing.

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...

Anyway, I will add a backward compatibility fix to resolve this.

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

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

[Ralph A. Schmid, dk5ras]

Hi,

 

just wanted to let you know that now, after pulling and building latest gr and 
gr-lte, it worked. Don't know if from pulling, or if from chosing F6 instead of 
F5 within grc.

 

Should it work with life reception, or only from a file? Maybe I'll have a 
closer look later, now on board the train I do not want to play with a 
blinkenlight piece of naked SDR electronics J

 

Ralph.

 

From: Johannes Demel [mailto:johannes.de...@ettus.com] 
Sent: Wednesday, 18 December, 2013 18:47
To: Ralph A. Schmid, dk5ras
Cc: uf...@student.kit.edu; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API

 

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] Error with latest 3.7 build

[Ralph A. Schmid, dk5ras]

 
> Ok, pushed the fix.

Everything fine now, built without further issues.

 
> Tom

Thanks a lot!

Ralph.




___
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

[Johnathan Corgan]

On 12/19/2013 08:45 AM, Koslowski, Sebastian (CEL) wrote:

> Anyway, I will add a backward compatibility fix to resolve this.

Thanks, let me know when it's ready and I'll get it in right away.

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

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

Re: [Discuss-gnuradio] Spectrum Sensing

[Johannes Demel]

Hi Nikita,

uhd_fft uses a WX sink. It does its own FFT calculations. They are not
meant to be used elsewhere. I recommend using a FFT block and then format
the output according to your needs.

Happy hacking
Johannes


On Wed, Dec 18, 2013 at 8:30 PM, Nikita Sharakhov  wrote:

> Hello Johannes,
>
>
>
> Thanks for giving me a solution to explore.  Also, would modifying
> uhd_fft.py (to output a text file rather than displaying a GUI) be a good
> way to accomplish my goal?  Has anyone done that before?
>
>
>
> Regards,
>
>
>
> Nikita
>
>
>
>
>
>
>
> *From:* Johannes Demel [mailto:johannes.de...@ettus.com]
> *Sent:* Tuesday, December 17, 2013 5:26 PM
>
> *To:* Nikita Sharakhov
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Spectrum Sensing
>
>
>
> Hi Nikita,
>
> so basically what you want is a couple of calculated FFTs per second.
> These are then sent to the web service and delivered to who ever connects
> to it.
>
> Let's assume every USRP has its own flowgraph. Then The thing to do is,
> receive samples, convert them to a vector with the size of your FFT, use a
> 'Keep one in N' block to decimate the number of FFTs per second and feed
> the output to a FFT block. Then pass your results around as you like.
>
> Happy hacking
>
> Johannes
>
>
>
> On Tue, Dec 17, 2013 at 11:26 AM, Nikita Sharakhov  wrote:
>
> Hi Johannes,
>
>
>
> Here are some more details.  I am building a web service, which returns
> spectrum data (the amount of energy at different frequencies) for a USRP,
> like so:
>
>
>
>
> http://128.173.221.40/WebServices/SpectrumAPIfineGrain.php?node=49&frq=20
>
>
>
> The script behind this data service calls a python program to calculate
> the spectrum and write the results to a text file.  Here is my goal:  I
> would like to find an alternative to the python program.
>
>
>
> This data is visualized in a web application:
>
>
>
> http://filebox.vt.edu/users/sharni/Radio/new.html
>
>
>
> clicking on a node visualizes the spectrum for the USRP.  The RAND button
> toggles between fake and real data.  Currently the data is not accurate.
>
>
>
> Thanks,
>
>
>
> Nikita
>
>
>
>
>
> *From:* Johannes Demel [mailto:johannes.de...@ettus.com]
> *Sent:* Tuesday, December 17, 2013 12:30 PM
> *To:* Nikita Sharakhov
> *Cc:* discuss-gnuradio@gnu.org
>
>
> *Subject:* Re: [Discuss-gnuradio] Spectrum Sensing
>
>
>
> Hi Nikita,
>
> In order to answer your question we need more information on what you want
> to do exactly. gr-fosphor takes all unprocessed samples and does everything
> on the GPU. Calculating spectrum, graphical output etc. As far as I know
> there isn't a way to get the samples back from the GPU.
>
> Cheers
>
> Johannes
>
>
>
> On Mon, Dec 16, 2013 at 8:12 PM, Nikita Sharakhov  wrote:
>
> Hi Johannes,
>
>
>
> Thanks for the answer!  I am building my own web-based GUI, so I just need
> a script that just writes the spectrum data to a text file or to standard
> command-line output.  Is that possible with gr-fosphor?  Is there any other
> software that I should look at?
>
>
>
> Best regards,
>
>
>
> Nikita
>
>
>
> *From:* Johannes Demel [mailto:johannes.de...@ettus.com]
> *Sent:* Monday, December 16, 2013 10:58 PM
> *To:* Nikita Sharakhov
> *Subject:* Re: [Discuss-gnuradio] Spectrum Sensing
>
>
>
> Hi Nikita,
>
> 'uhd_fft' is only a graphical frontend for your flowgraph. It contains a
> WX FFT Sink and some information about your setup. The WX FFT Sink itself
> seems to be so fast because it only calculates about 10 FFTs per second.
> All the other input samples are simply dropped. If you want to have a real
> real-time GUI take a look at gr-fosphor.
>
> If a few snapshots of the spectrum per second are sufficient for you,
> think about a keeping only a tiny fraction of your input samples. This will
> speed things up. On the other hand, if you want to calculate a FFT for all
> samples, look at the FFT block. BTW: the output of the FFT block would be
> the 'raw samples' you were asking for.
>
> Happy hacking
>
> Johannes
>
>
>
> On Mon, Dec 16, 2013 at 8:03 AM, Nikita Sharakhov  wrote:
>
> I would like to do spectrum sensing with GNU radio. Is there a good way to
> get the raw output from uhd_fft.py (the value for each frequency)? I would
> like to do this programatically (with code), rather than through a GUI.
>
> I have tried doing spectrum sensing with usrp_spectrum_sense.py, and this
> script has questionable accuracy and seems to be much slower than
> uhd_fft.py.
>
> Thanks!
>
>
>
>
> ___
> 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]

Technically it could work with life data. Unfortunately it creates a too
heavy load to be processed in realtime, unless you have the computing power
or reduce the bandwidth/fft length to a small value. But then you are
probably not able to decode more than the PBCH.


On Thu, Dec 19, 2013 at 8:49 AM, Ralph A. Schmid, dk5ras
wrote:

> Hi,
>
>
>
> just wanted to let you know that now, after pulling and building latest gr
> and gr-lte, it worked. Don’t know if from pulling, or if from chosing F6
> instead of F5 within grc.
>
>
>
> Should it work with life reception, or only from a file? Maybe I’ll have a
> closer look later, now on board the train I do not want to play with a
> blinkenlight piece of naked SDR electronics J
>
>
>
> Ralph.
>
>
>
> *From:* Johannes Demel [mailto:johannes.de...@ettus.com]
> *Sent:* Wednesday, 18 December, 2013 18:47
> *To:* Ralph A. Schmid, dk5ras
> *Cc:* uf...@student.kit.edu; discuss-gnuradio
> *Subject:* Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API
>
>
>
> 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

[Discuss-gnuradio] December Developers Call YouTube Link

[Martin Braun]

The call is available via:

https://www.youtube.com/watch?v=oLijSnXGK-I

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

[Discuss-gnuradio] December Dev Call

[West, Nathan]

The dev call is currently live @ https://www.youtube.com/watch?v=oLijSnXGK-I

The agenda is on the wiki:
http://gnuradio.org/redmine/projects/gnuradio/wiki/Call20131219

-Nathan

___
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

[Tom Tsou]

On Thu, Dec 19, 2013 at 12:55 PM, Johannes Demel
 wrote:
> Technically it could work with life data. Unfortunately it creates a too
> heavy load to be processed in realtime, unless you have the computing power
> or reduce the bandwidth/fft length to a small value. But then you are
> probably not able to decode more than the PBCH.

It's certainly possible, and advisable, to downsample from a full LTE
capturing bandwidth to a more manageable rate of 1.92 Msps or 960
ksps. The latter can be handled very efficiently for initial
acquisition, though the cyclic prefix length becomes fractional, which
is annoying to handle. In either case, the complexity of the
downsampling is mainly dictated by the output rate of the resampler.

Done efficiently, even a small processor can handle PBCH decoding from
a relatively high capture sample rate. Though, this would require a
rather substantial change from the gr-lte synchronization approach and
overall structure.

  -TT

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

[Discuss-gnuradio] gnuradio-companion segfaults with latest gnuradio master and gr-osmosdr

[Nowlan, Sean]

When I run gnuradio-companion with the latest gnuradio master and gr-osmosdr 
master, it segfaults. A backtrace reveals that there's a problem when Python 
tries to load _osmosdr_swig. If I uninstall gr-osmosdr, gnuradio-companion 
opens normally.

GDB backtrace:
http://pastebin.com/PYmyAbqE

Let me know if I should open a bug report. I'm not sure if others are 
experiencing this, or there is just something weird or misconfigured on my 
system.

Ubuntu 13.04 x86_64

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

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

[Sylvain Munaut]

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] OOT enums

[Michael Berman]

I am trying to access a C++ enumeration within an OOT module from a python
instance of my OOT.  When I try to run my python code it cannot find the
enumeration.

My OOT module is called pll_freq_phase_det_cf and is included in python as:
from pll_freq_phase_det_cf import pll_freq_phase_det_cf

The C++ enum is defined in the public section of the object class
definition in the include header and looks like:
  enum ld_determination {
USE_NONE = 0, USE_PHASE_THRESHOLD = 1, USE_SIG_THRESHOLD = 2,
USE_ALL = 3, USE_FULL = USE_ALL
  };

I would expect to be able to reference this from my python code like
"pll_freq_phase_det_cf.USE_ALL", but the python interpreter cannot find a
reference to this.

I have looked at gr-filter firdes windowing enum and I do not see anything
special about how this was declared, or within any CMake or swig files for
this, so I do not know where to go from here.

I have also looked at the python files in
/usr/local/lib/python2.7/site-packages for my OOT and firdes and see no
differences between how the enum values look (besides the names obviously
being different...).

Any help on this would be greatly appreciated.


Thank you very much,

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

Re: [Discuss-gnuradio] gnuradio-companion segfaults with latest gnuradio master and gr-osmosdr

[Tom Rondeau]

On Thu, Dec 19, 2013 at 1:50 PM, Nowlan, Sean
 wrote:
> When I run gnuradio-companion with the latest gnuradio master and gr-osmosdr
> master, it segfaults. A backtrace reveals that there’s a problem when Python
> tries to load _osmosdr_swig. If I uninstall gr-osmosdr, gnuradio-companion
> opens normally.

I just tried this with the latest git checkouts of everything
(gnuradio, osmosdr, hackrf, rtlsdr, gr-omosdr). Here's the enabled
stuff in my gr-osmosdr:

-- ##
-- # gr-osmosdr enabled components
-- ##
--   * Python support
--   * sysmocom OsmoSDR
--   * FUNcube Dongle
--   * IQ File Source
--   * Osmocom RTLSDR
--   * RTLSDR TCP Client
--   * Ettus USRP Devices
--   * HackRF Jawbreaker
--   * RFSPACE NetSDR
-- 
-- ##
-- # gr-osmosdr disabled components
-- ##
--   * Osmocom IQ Imbalance Correction
--   * FUNcube Dongle Pro+
--   * Osmocom MiriSDR
--   * nuand bladeRF


Everything runs fine for me with this setup.

Tom

___
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]

Currently synchronization doesn't support fractional CPs. Besides this,
reducing the sample rate helps a lot to make it run faster. Only thing to
keep in mind though, having a different number of blocks than used by the
base station will only allow you to decode PBCH. But for a start. That's
not much of a problem.


On Thu, Dec 19, 2013 at 10:33 AM, Tom Tsou  wrote:

> On Thu, Dec 19, 2013 at 12:55 PM, Johannes Demel
>  wrote:
> > Technically it could work with life data. Unfortunately it creates a too
> > heavy load to be processed in realtime, unless you have the computing
> power
> > or reduce the bandwidth/fft length to a small value. But then you are
> > probably not able to decode more than the PBCH.
>
> It's certainly possible, and advisable, to downsample from a full LTE
> capturing bandwidth to a more manageable rate of 1.92 Msps or 960
> ksps. The latter can be handled very efficiently for initial
> acquisition, though the cyclic prefix length becomes fractional, which
> is annoying to handle. In either case, the complexity of the
> downsampling is mainly dictated by the output rate of the resampler.
>
> Done efficiently, even a small processor can handle PBCH decoding from
> a relatively high capture sample rate. Though, this would require a
> rather substantial change from the gr-lte synchronization approach and
> overall structure.
>
>   -TT
>
___
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]

OK, I understand. So I need some file J My Intel i5 tablet PC may be too slow 
for life decode.

 

Ralph.

 

From: Johannes Demel [mailto:johannes.de...@ettus.com] 
Sent: Thursday, 19 December, 2013 18:55
To: Ralph A. Schmid, dk5ras
Cc: uf...@student.kit.edu; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API

 

Technically it could work with life data. Unfortunately it creates a too heavy 
load to be processed in realtime, unless you have the computing power or reduce 
the bandwidth/fft length to a small value. But then you are probably not able 
to decode more than the PBCH.

 

On Thu, Dec 19, 2013 at 8:49 AM, Ralph A. Schmid, dk5ras  
wrote:

Hi,

 

just wanted to let you know that now, after pulling and building latest gr and 
gr-lte, it worked. Don't know if from pulling, or if from chosing F6 instead of 
F5 within grc.

 

Should it work with life reception, or only from a file? Maybe I'll have a 
closer look later, now on board the train I do not want to play with a 
blinkenlight piece of naked SDR electronics J

 

Ralph.

 

From: Johannes Demel [mailto:johannes.de...@ettus.com] 
Sent: Wednesday, 18 December, 2013 18:47
To: Ralph A. Schmid, dk5ras
Cc: uf...@student.kit.edu; discuss-gnuradio
Subject: Re: [Discuss-gnuradio] gr-lte updated to GNU Radio 3.7 API

 

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

[Discuss-gnuradio] FOSDEM '14: Final Schedule

[Martin Braun (CEL)]

Hi everyone,

as you might remember, FOSDEM '14 is having a dedicated SDR track for
the first time. Despite being new and all, we managed to get a full
speaker lineup ready before the first deadline was over.

The schedule is available on the FOSDEM website:
https://fosdem.org/2014/schedule/track/software_defined_radio/

I'd like to thank all the speakers for preparing their talks.
Also, note that we have specifically set aside some time for hackery.

I hope to see lots of you guys in Brussels!

- The FOSDEM SDR-Track TPC (Phil, Sylvain and Martin)


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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT -- University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association


pgpJ4vrNBLSn0.pgp
Description: PGP signature
___
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

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

As much as I like the tracker solution, it leads to orphaned torrents
with time passing... There won't be a hundred people willing to seed
this for years.

My suggestion: Does anyone remember sourceforge? It used to be
popular. But then again, many of these young folks don't even remember
slashdot...

ah nevermind:
http://sourceforge.net/apps/trac/sourceforge/ticket/18131
5GB should be fine, and you get free CDN.

Greetings,
Marcus

On 19.12.2013 15: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
 mailto:uf...@student.kit.edu>>
 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.or

Re: [Discuss-gnuradio] OOT enums

[Tom Rondeau]

On Thu, Dec 19, 2013 at 2:07 PM, Michael Berman  wrote:
> I am trying to access a C++ enumeration within an OOT module from a python
> instance of my OOT.  When I try to run my python code it cannot find the
> enumeration.
>
> My OOT module is called pll_freq_phase_det_cf and is included in python as:
> from pll_freq_phase_det_cf import pll_freq_phase_det_cf
>
> The C++ enum is defined in the public section of the object class definition
> in the include header and looks like:
>   enum ld_determination {
> USE_NONE = 0, USE_PHASE_THRESHOLD = 1, USE_SIG_THRESHOLD = 2,
> USE_ALL = 3, USE_FULL = USE_ALL
>   };
>
> I would expect to be able to reference this from my python code like
> "pll_freq_phase_det_cf.USE_ALL", but the python interpreter cannot find a
> reference to this.
>
> I have looked at gr-filter firdes windowing enum and I do not see anything
> special about how this was declared, or within any CMake or swig files for
> this, so I do not know where to go from here.
>
> I have also looked at the python files in
> /usr/local/lib/python2.7/site-packages for my OOT and firdes and see no
> differences between how the enum values look (besides the names obviously
> being different...).
>
> Any help on this would be greatly appreciated.
>
>
> Thank you very much,
>
> Michael Berman

It sounds like you're definitely on the right track. My only
suggestion is to double-check your swig file that the header is being
included properly. But you're right; it's nothing special exporting
those enums through swig.

Another place to look is sig_source_waveform.h in gr-analog.

Tom

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

Re: [Discuss-gnuradio] OOT enums

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I had a hard time adding the tag_propagation_policy_t enum to the swig
gateway; maybe my pull request from back then might help you:
https://github.com/gnuradio/gnuradio/pull/69

The point is that I haven't been able to have an enum definition as
class member; only directly in the namespace.

Happy hacking,
Marcus


On 19.12.2013 21:36, Tom Rondeau wrote:
> On Thu, Dec 19, 2013 at 2:07 PM, Michael Berman
>  wrote:
>> I am trying to access a C++ enumeration within an OOT module from
>> a python instance of my OOT.  When I try to run my python code it
>> cannot find the enumeration.
>> 
>> My OOT module is called pll_freq_phase_det_cf and is included in
>> python as: from pll_freq_phase_det_cf import
>> pll_freq_phase_det_cf
>> 
>> The C++ enum is defined in the public section of the object class
>> definition in the include header and looks like: enum
>> ld_determination { USE_NONE = 0, USE_PHASE_THRESHOLD = 1,
>> USE_SIG_THRESHOLD = 2, USE_ALL = 3, USE_FULL = USE_ALL };
>> 
>> I would expect to be able to reference this from my python code
>> like "pll_freq_phase_det_cf.USE_ALL", but the python interpreter
>> cannot find a reference to this.
>> 
>> I have looked at gr-filter firdes windowing enum and I do not see
>> anything special about how this was declared, or within any CMake
>> or swig files for this, so I do not know where to go from here.
>> 
>> I have also looked at the python files in 
>> /usr/local/lib/python2.7/site-packages for my OOT and firdes and
>> see no differences between how the enum values look (besides the
>> names obviously being different...).
>> 
>> Any help on this would be greatly appreciated.
>> 
>> 
>> Thank you very much,
>> 
>> Michael Berman
> 
> It sounds like you're definitely on the right track. My only 
> suggestion is to double-check your swig file that the header is
> being included properly. But you're right; it's nothing special
> exporting those enums through swig.
> 
> Another place to look is sig_source_waveform.h in gr-analog.
> 
> Tom
> 
> ___ 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/

iQEcBAEBAgAGBQJSs1vHAAoJEAFxB7BbsDrLi3cH/RVDAeTG8Ql4ctSd1LuSf/tF
aiNQ+XX+wIB3CskMcwiFGLvUHfrg9/slOK8QehSG2/oZJWji1dGc9Tqko7DbYRhR
GfZzHWpRjpUlzwiclm9IqKy4ZV1zkzH+DH5Im9FGwdbFBK+cDpupKB4lsKV9Cosm
Q+JZXdMjGkqepraI58Aw9UsBML3akOrjSIYyE41BxCPEfLX9BXdM9aJxPnWl/gJY
xKR38HAwZOTJh6/yojZZ9dOHrWbdJPxFaTF9XaaDrNjEf3SEsvUBV1XQgpUZj/12
jImHwCLBGhoaXbuNf5gw89NSbgSucZRPlus0eX78IK6LNAWInmr3W4BRxHGKIC8=
=Eb1v
-END PGP SIGNATURE-

___
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

[Johnathan Corgan]

On 12/19/2013 12:33 PM, Marcus Müller wrote:

> As much as I like the tracker solution, it leads to orphaned torrents
> with time passing... There won't be a hundred people willing to seed
> this for years.

It is possible to host a data file on a web server, then incorporate a
"web seed" in the torrent file.  In the case where nobody is seeding the
file, or where nobody seeding has the portion you need, the web seed is
accessed via HTTP.

This is how we host the GNU Radio Live DVD image on gnuradio.org.

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

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

Re: [Discuss-gnuradio] OOT enums

[Sylvain Munaut]

Hi,

For what it's worth, I have enums in fosphor and the way I had to
access them is :

from gnuradio.fosphor.fosphor_swig import base_sink_c
base_sink_c.REF_DOWN

Because the base_sink_c from gnuradio.fosphor directly isn't really
the SWIG object ... it's just the wrapper for the make() function that
creates the sptr and you can't access any of the members.

Cheers,

Sylvain

___
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

[Marcus Müller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

That'd actually be rather awesome :)

On 19.12.2013 22:07, Johnathan Corgan wrote:
> On 12/19/2013 12:33 PM, Marcus Müller wrote:
> 
>> As much as I like the tracker solution, it leads to orphaned
>> torrents with time passing... There won't be a hundred people
>> willing to seed this for years.
> 
> It is possible to host a data file on a web server, then
> incorporate a "web seed" in the torrent file.  In the case where
> nobody is seeding the file, or where nobody seeding has the portion
> you need, the web seed is accessed via HTTP.
> 
> This is how we host the GNU Radio Live DVD image on gnuradio.org.
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSs2BUAAoJEAFxB7BbsDrLXvgH/RG3lgU9yGpa1LauvpzrzE2A
rGbDfzleinWVtwnfKaTX+2A3nNOMnANyqIxnxZsllFiwJ0V7seQhheyFwBEYxTZu
XUmxhw9oHyQFuOhxWolovLNUGEGMu2fjnCsR+g2VDKDRbkHNQA+zccvMA/DSDhZR
QMk8eSrcnm18cRA+J4+2ORSCnBWPbmoBohwMvG14V9WjF/gLjDSNPdrK4Q4DHXmx
0aqZphE0vudeBFiHhHomNGv3YgSwfaqkV7ShIoCC/MID39OCGzfYLnH50XKGpDjD
aPIWTq4iswVeaPFcbrfdIMjdF4AzNB+AEGwLnmt4sxn2Ts8vjaiDDHBZpGO6k1E=
=9bBr
-END PGP SIGNATURE-

___
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

[Tom Tsou]

On Thu, Dec 19, 2013 at 3:07 PM, Johannes Demel
 wrote:
> Currently synchronization doesn't support fractional CPs. Besides this,
> reducing the sample rate helps a lot to make it run faster. Only thing to
> keep in mind though, having a different number of blocks than used by the
> base station will only allow you to decode PBCH. But for a start. That's not
> much of a problem.

The fractional CP is a pain to deal with. Performing acquisition at
1.92 Msps, though, is quite reasonable and is appropriate for 1.4 MHz
LTE channels anyways.

UE side LTE decoding is inherently a multirate process. PBCH decoding
should ideally be performed at the reduced sample rate because any
data outside of the inner 6 RBs provides no useful information to the
search and decoding process. The same concept extends to any channel
configurations below the full LTE 30.72 Msps rate. But, since the
channel bandwidth is unknown until PCBH acquisition, the receiver
should, ideally, support all rates and dynamically switch between them
as needed.

Practically speaking, the issue with real-time operation on USRP type
devices is that we can't switch device sample rates without breaking
symbol timing or slot alignment. That means running a fixed device
rate and multiple resampling chains to cover the desired channel
bandwidths.

But yes, sticking with one sample rate avoids all of the above, and is
a much simpler way to start. Perhaps multirate handling is something
to consider for future development. If there were only more hours in a
day...

  -TT

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

[Discuss-gnuradio] Integrate block outputting inconsistent results.

[Miguel Duarte]

Hello everyone.

I have a system that depends on the integrate block. It integrates samples
and then divides them for averaging. I noticed something wasn't working
properly after updating to the last GR version and I don't know what's
going on, but testing a simple schematic with some blocks:


Const Source -> Integrator > File Sink

Where the constant source is set at 1024 and the integrator decimation at
1000, the output file contains these values:


1024000 (correct)
0
1024000
0
1024000
0
1024000
0
1024000

And so on. Is there something I'm doing wrong? Did anything change?

Thanks in advance, everyone.

Miguel
___
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]

Thanks, got it!

-George


On Dec 19, 2013, at 9:21 AM, Tom Rondeau  wrote:

> On Wed, Dec 18, 2013 at 7:47 PM, George  wrote:
>> Tom,
>> 
>> Is there going to be a fix soon or should I go with the 3.6.5 version of 
>> gnuradio?
>> 
>> Thanks,
>> -George
> 
> George,
> 
> The patch was pushed last night. I will make it into the next bug
> release, which will probably be in a month, plus or minus. In the
> meantime, you can get the patch by looking at commit
> b3b8a1f4965f8283f2c3d22ae45b569b2fe6d713
> 
> Tom
> 
> 
> 
>> 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

[Discuss-gnuradio] Integrate block outputting inconsistent results.

[Miguel Duarte]

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

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

[Mike Cornelius]

Hi Johannes and all,

I just pulled a new copy and make test still fails for me with various
missing .dat files.
Can anyone else confirm that make test is working ok for them with the
latest version?

Mike



On 20 December 2013 03:11, Johannes Demel  wrote:

> Hi Mike,
>
> just saw this mail. Basically this means that you're using an old
> version. Newer versions don't use these files any more. I recommend
> updating your gr-lte version. It runs on GR 3.7 now, so you don't have
> to worry about an old version there and I put in all the bugfixes into
> the latest master branch.
> Besides that, which version do you use exactly?
>
> Happy hacking
> Johannes
>
> On 18.12.2013 23:59, Mike Cornelius wrote:
> > Hi Johannes,
> >
> > Further to my last email I just noticed that the tests that are failing
> > are failing because test vectors are not available eg
> > '/home/johannes/tests/descramble.dat'.
> >
> > Mike
> >
> >
> > On 19 December 2013 18: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 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
> > 
> > 

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

[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] Unable to use WX widgets

[Sandhya G]

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

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

[Marcus Müller]

-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

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

[Sandhya G]

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

[Johannes Demel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Mike,

it would be really helpful if you posted the error message. If it is
more than a few lines, pastebin'ing would be good. Also can you tell
on which branch you're on? I'm worried about missing '.dat' because
they shouldn't be there. I thought I removed all references to them a
while ago.

Happy hacking
Johannes

On 19.12.2013 17:14, Mike Cornelius wrote:
> Hi Johannes and all,
> 
> I just pulled a new copy and make test still fails for me with
> various missing .dat files. Can anyone else confirm that make test
> is working ok for them with the latest version?
> 
> Mike
> 
> 
> 
> On 20 December 2013 03:11, Johannes Demel  > wrote:
> 
> Hi Mike,
> 
> just saw this mail. Basically this means that you're using an old 
> version. Newer versions don't use these files any more. I
> recommend updating your gr-lte version. It runs on GR 3.7 now, so
> you don't have to worry about an old version there and I put in all
> the bugfixes into the latest master branch. Besides that, which
> version do you use exactly?
> 
> Happy hacking Johannes
> 
> On 18.12.2013 23:59, Mike Cornelius wrote:
>> Hi Johannes,
>> 
>> Further to my last email I just noticed that the tests that are
> failing
>> are failing because test vectors are not available eg 
>> '/home/johannes/tests/descramble.dat'.
>> 
>> Mike
>> 
>> 
>> On 19 December 2013 18: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
> mailto:uf...@student.kit.edu>
>>  >> 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
> 
>>  >
>>>