Re: [Discuss-gnuradio] Does a block always *have* to return something?

[Marcus Müller]

Hi Anil,

> Does a block always *have* to return something?
What you mean is the work function. I know this is a bit nit-picky, but
there has always been a lot of confusion caused by exactly that: The
block is the whole instance of a class derived from gr.block, and the
work() (or general_work()) is the method of that class which gets called
repeatedly at runtime. You can have state as properties of the instance.

I'm not quite sure what the effect of returning None (which is what
happens when you don't return something in python) is, because that
NoneObject would then be handled through SWIF to C++, and I have no idea
whether SWIG has a uniform way of converting NoneObjects to integers.

In essence: yes, general_work() must always return a number, but in most
cases it's totally O.K. to return 0 if your block wasn't able to produce
output.

Best regards,
Marcus

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

Re: [Discuss-gnuradio] FFT for FM Tx and Rx

[Marcus Müller]

Hi El,

this is a bit hard to tell -- are you using a direct cable or antennas
between TX and RX?
If you're using antennas, that might simply be something else
transmitting there.

Also, if you transmit at 560 MHz, but only observe
$\SI{562}{\mega\hertz}\pm\frac{\SI{0.2}{\mega\hertz}}{2}$, you can't see
your transmit signal, so I can't compare the strength of that and what
you see in your RX FFT plot.

Best regards,
Marcus

On 06/21/2015 03:47 PM, El El wrote:
> Hi,
> I implemented the FM transmitter and receiver from the tutorials
> (http://files.ettus.com/tutorials/labs/Lab_1-5.pdf), the carrier
> frequency is 560 MHz, audio rate = 48 kHz, and frequency deviation = 5
> kHz. My question is why don't the FFT plots look similar? The FFT for
> the transmitter is centered on 562 MHz, but for the receiver, the
> highest amplitude component is centered on 561.97 MHz, also there is
> one more component on 562.09 MHz. Screenshots of the FFT plots are
> attached.
> Thanks a lot,
>
> El
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Verifying Turbo encoder output (was: Re: (no subject))

[Marcus Müller]

Dear Salija,

convolutional encoders are hard to check by hand. Typically, you'd try
to decode to verify.
PCCCs can be made systematic, I'm not sure that's the case for the GNU
Radio implementation.

Regarding the interleaver: turbocodes rely on adding redundancy
calculated from the input data stream, and an permutated version of
that. That permutation is done by the interleaver. Without the
interleaver, you'd just have two times the same information added as
redundancy, and that wouldn't really be an advantage over just using a
simple convolutional code that adds twice the redundancy.

Best regards,
Marcus

On 06/20/2015 07:34 AM, Salija P wrote:
>
> Hello all,
>   I am working with turbo encoder and decoder. is there any method
> to check and verify the output of pccc encoder.  I want to see the the
> output of pccc encoder for corresponding binary input. is there any
> way to do this?
> also any body can help me to explain interleaver operation in pccc
> encoder?
>
> Thanks in advance
>
> Salija.P
>
>
>
>
>
>
>
> With Regards,
> Salija.P
>
>
> ___
> 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] Fw: pybombs-gnuradio-install-missing files

[Tom Rondeau]

On Sun, Jun 21, 2015 at 11:57 PM, Handy Kirk  wrote:

> Thank you for replying Tom,
>
> I seem to be struggling to get my replies to reach the "
> discuss-gnuradio@gnu.org" but this time I think and hope for the best.
>
> 1.. You guessed right about PCLinuxOS, I do want to use that, been a user
> for about 10 years, but as far as compiling I have very little experience.
> I understand the principle but when it comes down to details it is a
> struggle. I try to stay away unless I get really enthusiastic.  Gnuradio
> too fascinating so by hook or by crook I will try something and experiment.
>
> 2.. I did not realise that Python 2.6 is outdated, but your mention made
> me check this laptos current version and it is (this just confirming that
> this PCLinuxOS version is also using later version than 2.6):
>
> [gert@KDE64-tecra-A11 ~]$ python -V
> Python 2.7.9
> [gert@KDE64-tecra-A11 ~]$
>
> Also I can confirm that by inspection in my sandbox I see Python 2.6.4
>
>
> 3.. I mentioned I had a record of my attempts to use pybombs, and it seems
> very early in my experience I have had no trouble with Python installing
> from source. The Python 2.6 is instatlled by pybombs install, here is the
> section:
>
> 
>
> Installing from source: python
> --2015-06-11 18:43:40--
> http://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2
> Resolving www.python.org (www.python.org)... 103.245.222.223
> Connecting to www.python.org (www.python.org)|103.245.222.223|:80...
> connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2
> [following]
> --2015-06-11 18:43:41--
> https://www.python.org/ftp/python/2.6.4/Python-2.6.4.tar.bz2
> Connecting to www.python.org (www.python.org)|103.245.222.223|:443...
> connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 11249486 (11M) [application/octet-stream]
> Saving to: ‘Python-2.6.4.tar.bz2’
>
> Python-2.6.4.tar.bz2 100%[===>] 10.73M 256KB/s
> in 43s
>
> 2015-06-11 18:44:24 (256 KB/s) - ‘Python-2.6.4.tar.bz2’ saved
> [11249486/11249486]
>
> Extract Python-2.6.4.tar.bz2
>
> ./configure --prefix=/home/gert/gr-sandbox/target --enable-shared CC=gcc
> CXX=g++
>
> Configuring: (100%)
> [==]
> Building: (100%)
> [==]
>
> make install
>
> Installing: (100%)
> [===]
> installation ok via: src
>
> -
>
> My understanding is that installing from source means that an acceptable
> version of a required program is located somewhere on the net and
> installed.
>
> Does that not mean in this case that pybombs want Python 2.6.4? Further my
> interpretation in above is that a version has been retrieved from
> www.python.org?
>
> Does this mean that my PCLinuxOS version somehow has a say in what Python
> version is acceptable to pybombs?
>
> I think I will see if I can set up a completely new partition with KDE64
> and start all over again.
>
> Handy
>


That's very strange behavior to install Python 2.6. The dependency tree
must have identified that for some other package it was installing. This
is, of course, the problem with trying to use a general build overlay
system like PyBOMBS on top of the OS's package manager: there are so many
of these distros out there and they all behave differently.

Tom




>  --
>  *From:* Tom Rondeau 
> *To:* Handy Kirk 
> *Cc:* "discuss-gnuradio@gnu.org" 
> *Sent:* Friday, 19 June 2015, 23:22
> *Subject:* Re: [Discuss-gnuradio] Fw: pybombs-gnuradio-install-missing
> files
>
>
>
> On Fri, Jun 19, 2015 at 1:58 AM, Handy Kirk 
> wrote:
>
>
>
> After a lot of work, I am a beginner concerning gnuradio, only an average
> linux user concentration on PCLinuxOS, now have an awfull lot of files
> installed in my sandbox.  I have had many goes at installing 'pybombs' and
> I think I have an understanding of the concept of installing from source.
>
> What really knocked me about was a very precise position during the
> process the file 'boost'  would terminate the process without any error
> message that I could find. The lack of finding the reason/errors probably
> because I know very little about compiling details.
>
> What came to my rescue was during one attempt the 'boost' download/install
> process became atrocciously slow but at the same time I could see it was
> trying to connect to my usual mirror (internode in Australia). I gave up
> but then a day of two later boots installed and the process could continue.
> (A resh install).
>
> Ufotunately I encounterd more files where the process simply was
> terminated with the command prompt but also reason quite clear, such as
> "source not found.." Others it was not so clear to me, so I decided to
> continue anyway as some files by inspec

Re: [Discuss-gnuradio] Control Ports On/Off and Config file

[Tom Rondeau]

On Fri, Jun 19, 2015 at 1:42 PM, Richard Bell 
wrote:

> I just ran a new pull, I don't see any updates related to
> gr-perf-monitorx, so I think I already have that commit. Here is the pull
> details just in case:
>


The patch that fixed it for me went in a while ago, just about when we put
back ControlPort support in April.

If I can duplicate the failure mode, then I might be able to fix it.
Otherwise, there's no much I can do to debug the problem.

Tom




> rbell@rbell:~/Documents/gnuradio$ git pull origin master
> remote: Counting objects: 32, done.
> remote: Total 32 (delta 22), reused 22 (delta 22), pack-reused 10
> Unpacking objects: 100% (32/32), done.
> From https://github.com/gnuradio/gnuradio
>  * branchmaster -> FETCH_HEAD
>7b684a2..28f69a5  master -> origin/master
> Updating 7b684a2..28f69a5
> Fast-forward
>  CMakeLists.txt | 35 +++--
>  .../include/gnuradio/thrift_application_base.h |  4 +-
>  gnuradio-runtime/lib/CMakeLists.txt|  7 ++-
>  gr-digital/grc/digital_constellation.xml   | 21 +---
>  gr-digital/grc/digital_constellation_rect.xml  | 60
> +-
>  grc/python/Generator.py|  2 +-
>  6 files changed, 75 insertions(+), 54 deletions(-)
> rbell@rbell:~/Documents/gnuradio$
>
>
> Is there anyway I can help you figure out the cause of the crash?
>
> Rich
>
> On Fri, Jun 19, 2015 at 10:37 AM, Tom Rondeau  wrote:
>
>> On Fri, Jun 19, 2015 at 12:58 PM, Richard Bell 
>> wrote:
>>
>>> That was the first thing I checked. No I don't have any config file in
>>> there. I'm not sure where it's picking up these other settings.
>>>
>>> I added a local config file to ~/.gnuradio with the same settings and
>>> now they seem to be picked up correctly. Shrug. I had to install one last
>>> python module, python-graphviz, but it starts up and runs now!
>>>
>>> If I leave it on the default view, it seems to run stably. If I switch
>>> to the 'Buffer Table->Graph View' or 'Run Table->Graph View', then
>>> Performance Monitor crashes, sometimes instantly, sometimes after a few
>>> seconds, with the following error:
>>>
>>> ControlPort Monitor running.
>>> monitor::endpoints() = -h rbell -p 57991
>>> running: ['gr-perf-monitorx', 'rbell', '57991']
>>> Traceback (most recent call last):
>>>   File "/usr/local/bin/gr-perf-monitorx", line 370, in update
>>> if(self.perfTable.isVisible()):
>>> RuntimeError: wrapped C/C++ object of type QTableWidget has been deleted
>>>
>>>
>>> Have I overlooked something?
>>>
>>> Rich
>>>
>>
>>
>> Darn, I thought that I fixed that bug here:
>>
>>
>> https://github.com/gnuradio/gnuradio/commit/3b41bb4dec9b6ce89e4909d20fbc7ffd764a80f3
>>
>> Tom
>>
>>
>>
>>
>>> On Fri, Jun 19, 2015 at 6:38 AM, Tom Rondeau  wrote:
>>>
 On Thu, Jun 18, 2015 at 7:38 PM, Richard Bell 
 wrote:

> I set my gnuradio configuration file (located here:
> /usr/local/etc/gnuradio/conf.d/gnuradio-runtime.conf) to the
> following:
>
> [PerfCounters]
> on = True #False
> export = True #False
> clock = thread
> #clock = monotonic
>
> [ControlPort]
> on = True #False
> edges_list = True #False
>
> I continue to run into the following message when I include a
> 'ctrlport performance monitor' in my flowgraph:
>
> ControlPort Monitor running.
> monitor::endpoints() = -h rbell -p 49158
> running: ['gr-perf-monitorx', 'rbell', '49158']
> Configuration has not turned on all of the appropriate ControlPort
> features:
> [ControlPort] on = True
> [ControlPort] edges_list = False
> [PerfCounters] on = True
> [PerfCounters] export = False
>
> Is there another file overriding the config file I set above to cause
> this?
>
> v/r,
> Rich
>

 Do you have a local config file in ~/.gnuradio/config.conf? Entries in
 there will override the system installed settings. See the manual page here
 for details:

 http://gnuradio.org/doc/doxygen/page_prefs.html

 Tom


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

Re: [Discuss-gnuradio] Issues using "Correlata and Sync" block, inside Hier_block2

[Tom Rondeau]

On Fri, Jun 19, 2015 at 9:25 AM, Marius Cachelin 
wrote:

> Hi everybody,
>
> I am writing here because I am experiencing an issue (for some weeks now),
> and I can't fixed it! I did some research about this problem, but I found
> nothing!
>
> I want to develop a hierarchical block, (called "RX_PATH"). In this block,
> I want to use the "Correlate and Sync" block... And here is my problem!
> When I compile my module (using make), all work well. But, when I run my
> .grc model in GNURadio-Companion, it's like the "Correlate and Sync" block
> freeze.
>
> Actually, no samples are outputted (neither in "out" port nor in "corr"
> port). I don't understand why, because when I use the "correlate and sync"
> block outside my hier_block, it work fine!
>
> I think, this is a misunderstood of how to use these type of blocks, so if
> someone could explain to me where is my mistake, I would be very grateful!
>
> Thanks in advance!
>
> Marius
>

That definitely sounds like unexpected behavior, and I can't think of much
to say right now about what might be going on.

However, we are deprecating that correlate_and_sync block in favor of the
corr_est block. There are a number of improvements in corr_est, and
something in the scheduling might work better for you because of that.

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

Re: [Discuss-gnuradio] gnuradio-companion-3.7.7.1 debian package

[Murray Thomson]

Hi Marcus,

I used a new installation of 12.04. I got the sources for 3.7.7.1 instead
of 3.7.7 this time. The generated debian package works fine.
My previous environment could have been wrong or maybe it was something in
3.7.7.
In any case, thanks a lot for your help.

Cheers,
Murray

2015-06-19 16:36 GMT+01:00 Marcus Müller :

>  Hi Murray,
>
> that's strange:
>
> > ImportError: libboost_system.so.1.58.0: cannot open shared object file:
> No such file or directory
>
> contradicts
>
> libboost_system.so.1.48.0 => /usr/lib/libboost_system.so.1.48.0
> (0xb71d8000)
>
>
> There's something seriously wrong about this situation. If not
> gnuradio-config-info was linked against boost 1.58 symbols, then one of the
> libraries it tries to use one your second PC is. That error comes from
> *somewhere*. Maybe you'd want to compare the "ldd $(...)" output of both
> systems, especially the individual paths of the libraries. Did you happen
> to build a custom boost on the second machine at some point?
>
> Best regards,
> Marcus
>
>
> On 06/19/2015 05:27 PM, Murray Thomson wrote:
>
> Hello again
>
> 2015-06-19 14:35 GMT+01:00 Marcus Müller :
>
>>  Hi!
>>
>> user@pc:~$ gnuradio-config-info
>>  ImportError: libboost_system.so.1.58.0: cannot open shared object file:
>> No such file or directory
>>
>>
>>  This means that the gnuradio-config-info was definitely built with
>> another version of boost (1.58) than what is found at the moment you start
>> it.
>>
> This is what I thought too but  sudo find / -name "libboost*" only finds
> libraries for boost 1.46 and 1.48.
>
>   The point about distributions is that they strive to keep all their
>> libraries coherent in one release. So, although the install script might
>> have installed the modern boost version correctly and set up some paths so
>> that on your first PC, linux knows where to look for boost 1.58, on the
>> other, this won't work automatically.
>> You can find out where the libboost_system.so.1.58.0 is on the system
>> where it works by running "ldd $(which gnuradio-config-info)".
>>
>  The system works but win a Gnuradio installed from the build_gnuradio
> script, not the debian package that I built.
> user@pc:~$ ldd $(which gnuradio-config-info)
> linux-gate.so.1 =>  (0xb776)
> libgnuradio-runtime-3.7.8git.so.0.0.0 =>
> /usr/local/lib/libgnuradio-runtime-3.7.8git.so.0.0.0 (0xb7671000)
> libboost_program_options.so.1.48.0 =>
> /usr/lib/libboost_program_options.so.1.48.0 (0xb7612000)
> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb75f6000)
> libstdc++.so.6 => /usr/lib/i386-linux-gnu/libstdc++.so.6 (0xb7511000)
> libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb74f3000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb7349000)
> libgnuradio-pmt-3.7.8git.so.0.0.0 =>
> /usr/local/lib/libgnuradio-pmt-3.7.8git.so.0.0.0 (0xb730b000)
> libvolk.so.1.0 => /usr/local/lib/libvolk.so.1.0 (0xb71fa000)
> libboost_filesystem.so.1.48.0 =>
> /usr/lib/libboost_filesystem.so.1.48.0 (0xb71dc000)
> libboost_system.so.1.48.0 => /usr/lib/libboost_system.so.1.48.0
> (0xb71d8000)
> libboost_thread.so.1.48.0 => /usr/lib/libboost_thread.so.1.48.0
> (0xb71bf000)
> librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb71b6000)
> libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb7189000)
> /lib/ld-linux.so.2 (0xb7761000)
> liborc-0.4.so.0 => /usr/lib/i386-linux-gnu/liborc-0.4.so.0 (0xb70f9000)
>
>
>> So the question is: which tool did you exactly use to install GNU Radio?
>>
> I used cmake with the following parameters:
> cmake -DCMAKE_INSTALL_PREFIX=/usr SYSCONFDIR=/etc
> -DENABLE_STATIC_LIBS=False \
> -DENABLE_DOXYGEN=False -DENABLE_GR_WXGUI=OFF -DENABLE_GR_VOCODER=OFF \
> -DENABLE_GR_DTV=OFF -DENABLE_GR_ATSC=OFF ..
>
>
>>  If you use pyBOMBS, you get the ability to install everything, including
>> updated versions of boost etc., into a specific private directory, and
>> generate a script that sets up all paths accordingly. You can then just
>> copy that prefix and script over to the other PC; that's pretty
>> distribution agnostic, but to be honest: If you wanted to make packages for
>> all the things that GNU Radio likes to have a bit more recent, you'd be
>> basically producing packages for half the development libraries that GNU
>> Radio needs -- 12.04 is 3 years old...
>>
> I wish I could upgrade my Ubuntu but I'm stack with 12.04 for other
> reasons. I'll try the pybombs way and also the same method for gnuradio
> 3.7.5 to check that I get the same error
>
>
>>
>> Best regards,
>> Marcus
>>
>
>  Thank you for your help
>  Murray
>
>>
>> On 06/19/2015 02:52 PM, Murray Thomson wrote:
>>
>>   Thanks for that Marcus, I got around that first step.
>>
>> My computer runs Ubuntu 12.04 with libboost 1.48 and it has a working
>> gnuradio installation v3.7.7.1-120-g67463e74 from the script in the web.
>> I used that computer to create the debian package based on
>> https://github.com/gnuradio/gnuradio.git tag v3.7.7 a

Re: [Discuss-gnuradio] Fw: pybombs-gnuradio-install-missing files

[Handy Kirk]

  From: Tom Rondeau 
 To: Handy Kirk  
Cc: "discuss-gnuradio@gnu.org"  
 Sent: Monday, 22 June 2015, 22:10
 Subject: Re: [Discuss-gnuradio] Fw: pybombs-gnuradio-install-missing files
   

That's very strange behavior to install Python 2.6. The dependency tree must 
have identified that for some other package it was installing. This is, of 
course, the problem with trying to use a general build overlay system like 
PyBOMBS on top of the OS's package manager: there are so many of these distros 
out there and they all behave differently.


Tom
-
PyBOMBS GNU Radio Build Quick Start¶"You can opt to just use the source, 'src', 
install and build everything from source."
I selected to install from src only, my interpretation of above is that this 
would bypass PCLinuxOS already installed files even if they were acceptable for 
use in PyBOMBS (of course taking extra time) is this correct?
Or is that only part true?
PCLinuxOS is rpm/Synaptic based, I have also tried install with options: 
rpm,src but that failed in grander style so I soon changed to src only as a 
safer starting point.
In the next day or two I will have new partition installed with fresh KDE64 
install and try again. I have the liveDVD part installed but need a bit 1 GB 
update to bring it to todays date should be done the coming day with PyBOMBS 
attempt 1 day later.
h.





   



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

[Discuss-gnuradio] #include "vector.hpp"

[dcardona]

Hello

I'm trying to create a block which C++ code needs to use  include
"vector.hpp". But I;m getting this error:  fatal error: vector.hpp: No such
file or directory.

Is there a way to do this?

Thank you very much.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

Re: [Discuss-gnuradio] #include "vector.hpp"

[Michael Berman]

Hi,

Try dropping the ".hpp" portion of your include.  This file does not have
any extension and is usually included as follows:

#include 

Hope this helps,

Michael

On Mon, Jun 22, 2015 at 9:16 AM, dcardona  wrote:

> Hello
>
> I'm trying to create a block which C++ code needs to use  include
> "vector.hpp". But I;m getting this error:  fatal error: vector.hpp: No such
> file or directory.
>
> Is there a way to do this?
>
> Thank you very much.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] #include "vector.hpp"

[Marcus Müller]

Hi!
Um, there's no vector.hpp in GNU Radio; are you maybe referring to the
header that contains std::vector?

You would normally include that as

#include 

and let your compiler figure out the file name suffix.

Best regards,
Marcus

On 06/22/2015 06:16 PM, dcardona wrote:
> Hello
>
> I'm trying to create a block which C++ code needs to use  include
> "vector.hpp". But I;m getting this error:  fatal error: vector.hpp: No such
> file or directory.
>
> Is there a way to do this?
>
> Thank you very much.
>
>
>
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

[Discuss-gnuradio] (no subject)

[Achilleas Anastasopoulos]

Salija,

can you specify which blocks are you working with?

Are they in gr-trellis or in gr-fec?

If the former I can help you (since I wrote most of it).

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

Re: [Discuss-gnuradio] Control Ports On/Off and Config file

[Richard Bell]

Is there a way I can give you feedback from my crash that will help you
figure out the cause? If so, I'm happy to do it.

Rich

On Mon, Jun 22, 2015 at 5:21 AM, Tom Rondeau  wrote:

> On Fri, Jun 19, 2015 at 1:42 PM, Richard Bell 
> wrote:
>
>> I just ran a new pull, I don't see any updates related to
>> gr-perf-monitorx, so I think I already have that commit. Here is the pull
>> details just in case:
>>
>
>
> The patch that fixed it for me went in a while ago, just about when we put
> back ControlPort support in April.
>
> If I can duplicate the failure mode, then I might be able to fix it.
> Otherwise, there's no much I can do to debug the problem.
>
> Tom
>
>
>
>
>> rbell@rbell:~/Documents/gnuradio$ git pull origin master
>> remote: Counting objects: 32, done.
>> remote: Total 32 (delta 22), reused 22 (delta 22), pack-reused 10
>> Unpacking objects: 100% (32/32), done.
>> From https://github.com/gnuradio/gnuradio
>>  * branchmaster -> FETCH_HEAD
>>7b684a2..28f69a5  master -> origin/master
>> Updating 7b684a2..28f69a5
>> Fast-forward
>>  CMakeLists.txt | 35 +++--
>>  .../include/gnuradio/thrift_application_base.h |  4 +-
>>  gnuradio-runtime/lib/CMakeLists.txt|  7 ++-
>>  gr-digital/grc/digital_constellation.xml   | 21 +---
>>  gr-digital/grc/digital_constellation_rect.xml  | 60
>> +-
>>  grc/python/Generator.py|  2 +-
>>  6 files changed, 75 insertions(+), 54 deletions(-)
>> rbell@rbell:~/Documents/gnuradio$
>>
>>
>> Is there anyway I can help you figure out the cause of the crash?
>>
>> Rich
>>
>> On Fri, Jun 19, 2015 at 10:37 AM, Tom Rondeau  wrote:
>>
>>> On Fri, Jun 19, 2015 at 12:58 PM, Richard Bell 
>>> wrote:
>>>
 That was the first thing I checked. No I don't have any config file in
 there. I'm not sure where it's picking up these other settings.

 I added a local config file to ~/.gnuradio with the same settings and
 now they seem to be picked up correctly. Shrug. I had to install one last
 python module, python-graphviz, but it starts up and runs now!

 If I leave it on the default view, it seems to run stably. If I switch
 to the 'Buffer Table->Graph View' or 'Run Table->Graph View', then
 Performance Monitor crashes, sometimes instantly, sometimes after a few
 seconds, with the following error:

 ControlPort Monitor running.
 monitor::endpoints() = -h rbell -p 57991
 running: ['gr-perf-monitorx', 'rbell', '57991']
 Traceback (most recent call last):
   File "/usr/local/bin/gr-perf-monitorx", line 370, in update
 if(self.perfTable.isVisible()):
 RuntimeError: wrapped C/C++ object of type QTableWidget has been deleted


 Have I overlooked something?

 Rich

>>>
>>>
>>> Darn, I thought that I fixed that bug here:
>>>
>>>
>>> https://github.com/gnuradio/gnuradio/commit/3b41bb4dec9b6ce89e4909d20fbc7ffd764a80f3
>>>
>>> Tom
>>>
>>>
>>>
>>>
 On Fri, Jun 19, 2015 at 6:38 AM, Tom Rondeau  wrote:

> On Thu, Jun 18, 2015 at 7:38 PM, Richard Bell  > wrote:
>
>> I set my gnuradio configuration file (located here:
>> /usr/local/etc/gnuradio/conf.d/gnuradio-runtime.conf) to the
>> following:
>>
>> [PerfCounters]
>> on = True #False
>> export = True #False
>> clock = thread
>> #clock = monotonic
>>
>> [ControlPort]
>> on = True #False
>> edges_list = True #False
>>
>> I continue to run into the following message when I include a
>> 'ctrlport performance monitor' in my flowgraph:
>>
>> ControlPort Monitor running.
>> monitor::endpoints() = -h rbell -p 49158
>> running: ['gr-perf-monitorx', 'rbell', '49158']
>> Configuration has not turned on all of the appropriate ControlPort
>> features:
>> [ControlPort] on = True
>> [ControlPort] edges_list = False
>> [PerfCounters] on = True
>> [PerfCounters] export = False
>>
>> Is there another file overriding the config file I set above to cause
>> this?
>>
>> v/r,
>> Rich
>>
>
> Do you have a local config file in ~/.gnuradio/config.conf? Entries in
> there will override the system installed settings. See the manual page 
> here
> for details:
>
> http://gnuradio.org/doc/doxygen/page_prefs.html
>
> Tom
>
>

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

Re: [Discuss-gnuradio] Control Ports On/Off and Config file

[Marcus Müller]

Hi Rich,

this might be more complicated than it sounds at first, but:

1. Build GNU Radio with debugging symbols (ie. cmake
-DCMAKE_BUILD_TYPE=RelWithDebInfo); install debugging symbols for your
QT build (how to do this depends on your distribution)
2. run "gdb --args python $(which gr-perf-monitorx)"
3. "run"
4. Wait for crash
5. "bt" (for backtrace) will give you information on who called the
function that tried to access a deleted QTableWidget. That might or
might not be helpful.

Assuming the QTableWidget shouldn't actually have been deleted:

Running python inside gdb, you might be able to add a breakpoint at the
destructor of QTableWidget; it's "break functionname", but I'd have to
look up whether that function would be
QT::GUI::QTableWidget::~QTableWidget or something else.
Then, gdb would interrupt the execution of gr-perf-monitorx the moment
that table widget gets deleted.

For a bit of background:
https://gnuradio.org/redmine/projects/gnuradio/wiki/TutorialsGDB


On 06/22/2015 08:38 PM, Richard Bell wrote:
> Is there a way I can give you feedback from my crash that will help
> you figure out the cause? If so, I'm happy to do it.
>
> Rich
>
> On Mon, Jun 22, 2015 at 5:21 AM, Tom Rondeau  > wrote:
>
> On Fri, Jun 19, 2015 at 1:42 PM, Richard Bell
> mailto:richard.be...@gmail.com>> wrote:
>
> I just ran a new pull, I don't see any updates related to
> gr-perf-monitorx, so I think I already have that commit. Here
> is the pull details just in case:
>
>
>
> The patch that fixed it for me went in a while ago, just about
> when we put back ControlPort support in April.
>
> If I can duplicate the failure mode, then I might be able to fix
> it. Otherwise, there's no much I can do to debug the problem.
>
> Tom
>
>
>  
>
> rbell@rbell:~/Documents/gnuradio$ git pull origin master
> remote: Counting objects: 32, done.
> remote: Total 32 (delta 22), reused 22 (delta 22), pack-reused 10
> Unpacking objects: 100% (32/32), done.
> From https://github.com/gnuradio/gnuradio
>  * branchmaster -> FETCH_HEAD
>7b684a2..28f69a5  master -> origin/master
> Updating 7b684a2..28f69a5
> Fast-forward
>  CMakeLists.txt | 35
> +++--
>  .../include/gnuradio/thrift_application_base.h |  4 +-
>  gnuradio-runtime/lib/CMakeLists.txt|  7 ++-
>  gr-digital/grc/digital_constellation.xml   | 21 +---
>  gr-digital/grc/digital_constellation_rect.xml  | 60
> +-
>  grc/python/Generator.py|  2 +-
>  6 files changed, 75 insertions(+), 54 deletions(-)
> rbell@rbell:~/Documents/gnuradio$
>
>
> Is there anyway I can help you figure out the cause of the crash?
>
> Rich
>
> On Fri, Jun 19, 2015 at 10:37 AM, Tom Rondeau
> mailto:t...@trondeau.com>> wrote:
>
> On Fri, Jun 19, 2015 at 12:58 PM, Richard Bell
> mailto:richard.be...@gmail.com>>
> wrote:
>
> That was the first thing I checked. No I don't have
> any config file in there. I'm not sure where it's
> picking up these other settings.
>
> I added a local config file to ~/.gnuradio with the
> same settings and now they seem to be picked up
> correctly. Shrug. I had to install one last python
> module, python-graphviz, but it starts up and runs now!
>
> If I leave it on the default view, it seems to run
> stably. If I switch to the 'Buffer Table->Graph View'
> or 'Run Table->Graph View', then Performance Monitor
> crashes, sometimes instantly, sometimes after a few
> seconds, with the following error:
>
> ControlPort Monitor running.
> monitor::endpoints() = -h rbell -p 57991
> running: ['gr-perf-monitorx', 'rbell', '57991']
> Traceback (most recent call last):
>   File "/usr/local/bin/gr-perf-monitorx", line 370, in
> update
> if(self.perfTable.isVisible()):
> RuntimeError: wrapped C/C++ object of type
> QTableWidget has been deleted
>
>
> Have I overlooked something?
>
> Rich
>
>
>
> Darn, I thought that I fixed that bug here:
>
> 
> https://github.com/gnuradio/gnuradio/commit/3b41bb4dec9b6ce89e4909d20fbc7ffd764a80f3
>
> Tom
>
>
>  
>
> On Fri, Jun 19, 2015 at 6:38 AM, Tom Rondeau
> mailto:t...@trondeau.com>> wrote:
>
> On Thu, Jun 18, 2015 at 7:38 PM, Richard Bell
>   

Re: [Discuss-gnuradio] #include "vector.hpp"

[dcardona]

Hi

Yes, I tried to use only #include , but it gives me an error for
each vector a I use.

Vector f (at the beginning the following code) is one of the vectors which
needs the #include "vector.hpp". 

intentooptimizar.cpp
  

Thank you.



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344p54350.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] Remove portion of tagged stream

[Richard Bell]

Hello all,

Question 1:
I have another "Does this exist already" question. I'm using the correlate
access code block to tag a stream of data. Is there a block that exists
that will identify a tag and then remove the next X items, where X is user
defined?

I'm not looking to use the Header Payload/Demux for this, because the
specification I'm designing to does not call out a header and I need to
remain interoperable.

Question 2:
Assuming I have to write this block myself, I'd like some confirmation of
my current thought process.

Since the input/output relationship is not constant, as I will be removing
samples (decimating) sometimes but other times copying input to output
(sync), is the conclusion that I have to use a general block here correct?

Question 3:
When using a general block, it is my responsibility to consume and produce
everything. With this said, if I call produce(X) to place samples in the
output buffer, then what does the return statement do? If I return 8000,
what does this mean?

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

Re: [Discuss-gnuradio] Remove portion of tagged stream

[Johnathan Corgan]

On Mon, Jun 22, 2015 at 4:09 PM, Richard Bell 
wrote:


> Is there a block that exists that will identify a tag and then remove the
> next X items, where X is user defined?
>

No.



> is the conclusion that I have to use a general block here correct?
>

Yes



> if I call produce(X) to place samples in the output buffer, then what does
> the return statement do? If I return 8000, what does this mean?
>

Use 'return WORK_CALLED_PRODUCE'.

-- 
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Remove portion of tagged stream

[Richard Bell]

Thank you!

Rich

On Mon, Jun 22, 2015 at 4:16 PM, Johnathan Corgan 
wrote:

> On Mon, Jun 22, 2015 at 4:09 PM, Richard Bell 
> wrote:
>
>
>> Is there a block that exists that will identify a tag and then remove the
>> next X items, where X is user defined?
>>
>
> No.
>
>
>
>> is the conclusion that I have to use a general block here correct?
>>
>
> Yes
>
>
>
>> if I call produce(X) to place samples in the output buffer, then what
>> does the return statement do? If I return 8000, what does this mean?
>>
>
> Use 'return WORK_CALLED_PRODUCE'.
>
> --
> Johnathan Corgan
> Corgan Labs - SDR Training and Development Services
> http://corganlabs.com
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] #include "vector.hpp"

[Michael Berman]

It looks like you are trying to create your own vector class named Vector
(keeping notice of the capitalized 'V').

These Vector method definitions need a definition for the Vector class,
which is presumably in your Vector.hpp.  I would like to note that the .hpp
extension indicates a template header library, and all of the method
definitions should be inline in the template class definition, or in an
include file; not in a compiled object file.

It appears (at least from this lone file) that you are not using
std::vector at all, and you may wish to remove the '#include ' line
to keep things clean in your code and not include not used pieces of code.

Back to your example not working, your #include "Vector.hpp" must point to
the file that presumably contains the class definition.  for this include
to work as stated, the Vector.hpp file will have to be in the same
directory as the file that you posted; otherwise you will have to give a
relative (or absolute) path to this file in the include statement.


I hope this helps you some!

Michael


P.S. Why are you not using std::vector?


On Mon, Jun 22, 2015 at 3:35 PM, dcardona  wrote:

> Hi
>
> Yes, I tried to use only #include , but it gives me an error for
> each vector a I use.
>
> Vector f (at the beginning the following code) is one of the vectors which
> needs the #include "vector.hpp".
>
> intentooptimizar.cpp
> 
>
> Thank you.
>
>
>
> --
> View this message in context:
> http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344p54350.html
> Sent from the GnuRadio mailing list archive at Nabble.com.
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] #include "vector.hpp"

[Tom Rondeau]

On Mon, Jun 22, 2015 at 7:40 PM, Michael Berman 
wrote:

> It looks like you are trying to create your own vector class named Vector
> (keeping notice of the capitalized 'V').
>
> These Vector method definitions need a definition for the Vector class,
> which is presumably in your Vector.hpp.  I would like to note that the .hpp
> extension indicates a template header library, and all of the method
> definitions should be inline in the template class definition, or in an
> include file; not in a compiled object file.
>
> It appears (at least from this lone file) that you are not using
> std::vector at all, and you may wish to remove the '#include ' line
> to keep things clean in your code and not include not used pieces of code.
>
> Back to your example not working, your #include "Vector.hpp" must point to
> the file that presumably contains the class definition.  for this include
> to work as stated, the Vector.hpp file will have to be in the same
> directory as the file that you posted; otherwise you will have to give a
> relative (or absolute) path to this file in the include statement.
>
>
> I hope this helps you some!
>
> Michael
>
>
> P.S. Why are you not using std::vector?
>


David,
While I'm kind of curious about you making your own vector class, too, this
is not about GNU Radio but generally C++ coding issues. Please move this
conversation to a more appropriate forum about programming.

Thanks,
Tom




> On Mon, Jun 22, 2015 at 3:35 PM, dcardona  wrote:
>
>> Hi
>>
>> Yes, I tried to use only #include , but it gives me an error for
>> each vector a I use.
>>
>> Vector f (at the beginning the following code) is one of the vectors which
>> needs the #include "vector.hpp".
>>
>> intentooptimizar.cpp
>> 
>>
>> Thank you.
>>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] #include "vector.hpp"

[dcardona]

Yes Tom, you are absolutely right. I'm sorry and thank you.





--
View this message in context: 
http://gnuradio.4.n7.nabble.com/include-vector-hpp-tp54344p54356.html
Sent from the GnuRadio mailing list archive at Nabble.com.

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

[Discuss-gnuradio] hello

[monika sharma]

i have started using this GNUradio 3.7.7.1  recently ,some librarys
are missing in it like graphical sinks and sinks .can anyone help me
out that from where i have to download these packages and install it.
regards
monika

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

Re: [Discuss-gnuradio] hello

[Marcus Müller]

Hello Monika,

Generally, GNU Radio gets build with everything that is possible with
the development headers installed on the system that was used.

So, the question is: How did you get GNU Radio?

Best regards,
Marcus


On 06/23/2015 08:28 AM, monika sharma wrote:
> i have started using this GNUradio 3.7.7.1  recently ,some librarys
> are missing in it like graphical sinks and sinks .can anyone help me
> out that from where i have to download these packages and install it.
> regards
> monika
>
> ___
> 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] hello

[Marcus Müller]

So you used the build-gnuradio script or followed the instructions
further down on that page?

Best regards,
Marcus

PS: when replying, make sure to reply to the mailing list address rather
than to individual people!

On 06/23/2015 08:46 AM, monika sharma wrote:
> hello Marcus
> i have installed it from this site
> https://gnuradio.org/redmine/projects/gnuradio/wiki/UbuntuInstall
> regards
> monika
>
> On Tue, Jun 23, 2015 at 12:10 PM, Marcus Müller
>  wrote:
>> Hello Monika,
>>
>> Generally, GNU Radio gets build with everything that is possible with
>> the development headers installed on the system that was used.
>>
>> So, the question is: How did you get GNU Radio?
>>
>> Best regards,
>> Marcus
>>
>>
>> On 06/23/2015 08:28 AM, monika sharma wrote:
>>> i have started using this GNUradio 3.7.7.1  recently ,some librarys
>>> are missing in it like graphical sinks and sinks .can anyone help me
>>> out that from where i have to download these packages and install it.
>>> regards
>>> monika
>>>
>>> ___
>>> 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