Re: [Discuss-gnuradio] GRC Fails to Display QT/WX Elements [SOLVED]

[Crypto.Troop]

Tom, THANK YOU. This worked wonderfully!

Here's the juicy bits for those whom may find this thread later on.

Mint 15 - Fully updated as of 21 Jun 2013


SDR: HackRF and RTL E4000 tuner dongle.

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-1ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --enable-plugin --with-system-zlib
--enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)

gnuradio-config-info -v
3.7.0rc0

VGA compatible controller: NVIDIA Corporation GF110 [GeForce GTX 570
Rev. 2] (rev a1)

Using the proprietary nvidia driver:

nvidia-310 310.44-0ubuntu2 amd64 NVIDIA binary Xorg driver, kernel
module and VDPAU library

python -V
Python 2.7.4

3.8.0-19-generic #29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux

Standard master git branch of gr-osmosdr.

Below, in the thread is more detail.


Thanks again to all whom offered suggestions!

Mark






On Fri, Jun 21, 2013 at 4:06 PM, Volker Schroer  wrote:
>* Do you see any messages in /var/log/Xorg.0.log or /var/log/dmesg ?*
>**
>* Am 21.06.2013 15:43, schrieb Crypto.Troop:*
>*>*
>*> Hi Volker,*
>*>*
>*> Yes sir, I've added throttles, and tried all of the provided demo's. I've*
>*> also done more research, and further down the list are people talking about*
>*> the same thing...*
>*>*
>*>*
>*> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00373.html*
>*>*
>*>*
>*> so I have hope it's not just me... :)*
>*>*
>*>*
>*> Thanks,*
>*>*
>*> Mark*
>*>*
>*>*
>*>> May be a silly question, but does your flow graph contain >a throttle*
>*>> block ?*
>*>>*
>*>> -- Volker*
>*>*
>*>*
>*>*
>*>*
>*> Am 21.06.2013 04:55, schrieb Crypto.Troop:*
>*>*
>*> Hi,*
>*>*
>*> I just installed GNURADIO from git, onto a brand new install of Mint*
>*> 15.*
>*> I followed the following instructions:*
>*> http://bgamari.github.io/posts/2013-06-15-hackrf.html*
>*>*
>*> gnuradio-config-info -v*
>*> 3.7.0git-143-gad1d52fd*
>*>*
>*> With Python 2.7, I was able to get everything compiled and installed.*
>*> The CMakeLists.txt in GNURADIO I had to tweak line(168)*
>*> to: find_package(PythonLibs 2.7) for it to include Python support.*
>*>*
>*> My environment vars:*
>*> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:*
>*> PYTHONPATH=:/usr/local/lib/python2.7/dist-packages*
>*>*
>*> I built GNURADIO with the following cmake:*
>*> cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7*
>*> -DPYTHON_INCLUDE_DIR=/usr/include/python2.7*
>*> -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1 ../*
>*>*
>*> I fire up gnuradio-companion and try a simple example dial_tone.grc. I*
>*> click generate, then execute, I see the standard "Executing*
>*> ..."/tmp/dial_tone.py" "Using Volk machine: svx_64_mmx"  etc... No*
>*> other*
>*> errors. My problem is, no QT/WX GUI elements show up.*
>*>*
>*> I built a simple grc file with a QT slider(and nothing else), and this*
>*> worked.*
>*> I tried a basic signal source, through a throttle right into a QT FFT*
>*> GUI element. The grc runs, no errors, yet the physical display of the*
>*> FFT fails.*
>*> I have on another box gnuradio 3.6.5 and all of this worked fine. I*
>*> compared qt/wx/python debs and verified both machines have similar*
>*> packages.*
>*>*
>*> The key common factor in this problem is if i remove the signal*
>*> sources*
>*> and sinks, the QT/WX basic sliders will show... Perhaps there is*
>*> something wrong with my version of gnuradio and how it handles*
>*> inputs/outputs, killing GUI display? I've also tried compiling against*
>*> python3, 3.3 and 3.3m...no luck.*
>*>*
>*> Is there a way I can enable an extra layer of debug into GRC for me to*
>*> see what it's doing??*
>*> I've tried running /tmp/dial_tone.py directly and it run's, but no*
>*> audio*
>*> or gui elements display. Another hint which may help, is a basic audio*
>*> source to audio sink, set to "pulse" does not output audio into my*
>*> speakers. The audio 

[Discuss-gnuradio] RA blocks

[Marcus D. Leech]

I've put a set of Radio Astronomy-related blocks up on cgran:

https://www.cgran.org/svn/projects/gr-ra_blocks

It includes

  o an oblivous "slicer" that can be used in a Dicke-switching 
environment when there's no way of explicitly tagging samples as to which
 "switch state" they belong to.  It requires that there be a 
significant power difference between "Sky", and "Reference". It's a 
decimator.


  o A synchronous detector.  Like above--again used in Dicke switching, 
but it has an explicit switch-state input.  It's left as an exercise for
 the reader as to how you actually synchronize the internal notion 
of the switch state with the switch hardware, and the resulting 
data-streams,
 given the latency-uncertainties of Gnu Radio.  Like the above, 
it's a decimator.


  o A "clock generator".  It takes a sample-stream as input, and 
produces a series of (logical) 1s and 0s as an output, using the input 
stream purely
 as a timing source.  It's a decimator, so you can produce any 
integer-fractional rate of the incoming data stream.  One might use this 
block
 to provide "switch state" to the synchronous detector block, 
above, perhaps with a delay block in between.


  o A "vector power" block (not sure what to actually call this).  It 
takes a vector as input, usually the output magnitude vector of a 
previous FFT,
 and allows you to synthesize sub-channels by combining numbers of 
adjacent FFT output bins into a signal power estimate for that collection
 of bins.  This is cheaper than a PFB, but is useful only for power 
estimation, since generally, it takes an already-IIR-filtered-and-decimated
 stream of FFT output vectors as input, and allows non-uniform 
output channels cheaply.


  o A pulsar folder -- of the true folding type.  It produces a fixed 
vector as output which hopefully contains the folded pulse profile.   
The input
 sample-rate must have already been fractionally-resampled to 
vector_size * notional-pulse-rate


  o Another pulsar folder -- using an IIR output filter.  Same 
sample-rate constraints as the "true folder", but it produces continuous 
vector
 outputs, and applies a single-pole IIR filter to each element of 
the output vector.  This is a GRC-derived hier block.


  o An RA-friendly FFT block -- very much like the Log Power FFT block, 
but with linear magnitude outputs.  Nothing fancy.  It's a GRC-derived

 hier block.

I'll likely add others as time and inspiration permit.   For example, a 
hier block that can be used for coherent de-dispersion where you just
   give it the DM, Fc, and bandwidth, and let it compute the filter 
coefficients.  I have Python "helper code" that can do this already, 
just not

   sure how to integrate it into a hier block "cleanly".

Similarly, an incoherent de-dispersion block using filter-and-delay 
might also be useful--again taking DM, Fc, and bandwidth as parameters,
  and breaking up the bandwidth uniformly, and inserting appropriate 
delays.


Simple_ra doesn't actually use any of these, although if I add pulsar 
capability, it's going to at least use on of the folder blocks, and one of

  the not-yet-written dedispersion blocks.




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

[Michael Dickens]

On Jun 21, 2013, at 5:40 PM, Sylvain Munaut <246...@gmail.com> wrote:
> <0001-wxgui-Fixes-to-solde-issues-using-wx-GL-sinks-on-OS-.patch>

Comparing this file to the commit that was reverted, the only difference I see 
is:

This file:
{{{
+   wx.glcanvas.GLCanvas.__init__(self, parent, wx.ID_ANY, 
attribList=attribList);  # Specifically use the CTOR which does NOT create an 
implicit GL context
}}}

Commit:
{{{
+   wx.glcanvas.GLCanvas.__init__(self, parent, wx.ID_ANY, 
attribList); # Specifically use the CTOR which does NOT create an implicit 
GL context
}}}

According to < http://wxpython.org/docs/api/wx.glcanvas.GLCanvas-class.html >, 
the API for this call should be:
{{{
__init__(self, parent, id=-1, pos=DefaultPosition, size=DefaultSize, style=0, 
name=GLCanvasNameStr, attribList=None,palette=wxNullPalette) 
}}}

So fixing the init call as above with "attribList=attribList" should fix a bug 
that might effect all implementations.  If the prior commit worked on OSX, and 
I believe it did, then this version should too since all it does differently is 
fix this one bug.  Nice catch, Sylvain!

I would encourage other Linux & Windows users to try out this fix, to make sure 
it works across all major platforms. - MLD



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

Re: [Discuss-gnuradio] Flow graph issue with usrp1+RFX2400 daughter board and TX/RX antenna

[Josh Blum]

On 06/21/2013 07:25 PM, Arturo Rinaldi wrote:
> Hi folks, I've recently bumped into an issue with two GRC flow graphs
> while running a rx/tx loop path interfacing with an external sensor :
> 
> *T**X path - UHD Usrp1 Sink (sending data to the sensor)*
> 
> http://img713.imageshack.us/img713/4540/gyz.png
> 
> *RX path - UHD Usrp1 Source (receiving data from the sensor)*
> 
> http://img822.imageshack.us/img822/521/dq8.png
> 
> I'm using a USRP1 mainboard and a RFX2400 daughter board using the TX/RX
> section. I can run the TX flow graph, but when i launch the other one,
> the shell warns me about an UHD error. The uhd driver can't find the
> usrp1 card (specifically, the *uhd source object* can't be built because
> the uhd driver is not able find the usrp device), it's like the tx path
> had an exclusive possession of the A:0 subdevice (the *TX/RX* one on
> which I put my antenna).
> 
> Do I have to pass some command line switches to the uhd driver to solve
> this issue ? Thanks in advance.
> 

The device can only be opened once per process. Either run both flow
graphs in the same process, or combine both flowgraphs into one flowgraph.

-josh

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

[Discuss-gnuradio] Flow graph issue with usrp1+RFX2400 daughter board and TX/RX antenna

[Arturo Rinaldi]

Hi folks, I've recently bumped into an issue with two GRC flow graphs 
while running a rx/tx loop path interfacing with an external sensor :


*T**X path - UHD Usrp1 Sink (sending data to the sensor)*

http://img713.imageshack.us/img713/4540/gyz.png

*RX path - UHD Usrp1 Source (receiving data from the sensor)*

http://img822.imageshack.us/img822/521/dq8.png

I'm using a USRP1 mainboard and a RFX2400 daughter board using the TX/RX 
section. I can run the TX flow graph, but when i launch the other one, 
the shell warns me about an UHD error. The uhd driver can't find the 
usrp1 card (specifically, the *uhd source object* can't be built because 
the uhd driver is not able find the usrp device), it's like the tx path 
had an exclusive possession of the A:0 subdevice (the *TX/RX* one on 
which I put my antenna).


Do I have to pass some command line switches to the uhd driver to solve 
this issue ? Thanks in advance.


Kind Regards, Arturo




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

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

[Sylvain Munaut]

Hi,

> I'd be very happy to include into the pending 3.7.0rc0 release a tested fix
> that solves OSX issues without affecting Linux.

Attached is a fixed up version of the 5f0aaf3d5397675d6f87acd7ab20526ac1fb0d4e

As far as testing goes, all I can say is that the original commit made
my WX fft flicker a lot under linux.
This commit seems to change nothing for me. (i.e. works fine before
and after, running on Gentoo Linux).

Now it should be tested by people on OSX to make sure it still fixes
their issue and it should be tested by other linux users to make sure
it doesn't break ...


Cheers,

 Sylvain Munaut


0001-wxgui-Fixes-to-solde-issues-using-wx-GL-sinks-on-OS-.patch
Description: Binary data
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GUI problems with 3.7

[Tom Rondeau]

On Fri, Jun 21, 2013 at 4:11 PM, Marcus D. Leech  wrote:
>> On Fri, Jun 21, 2013 at 3:39 PM, Tom Rondeau  wrote:
>>>
>>> On Fri, Jun 21, 2013 at 12:41 PM, Marcus D. Leech
>>> wrote:

 There are safe uses for unconstrained string functions.  Just, well, not
 very many...

 --
 Marcus Leech
>>>
>>> No. Never, ever, ever is it ok. I say this using a strlen call now...
>>> (but it's against strings that are hard-coded into our files by us, so
>>> if that breaks, we have only ourselves to blame).
>>>
>>> Also, just pushed a fix. This should take care of things.
>>>
>>> Tom
>>
>> Pardon my ignorance here, but would someone mind explaining this a
>> little more? My intuition is saying that it's unsafe to use strcmp on
>> user input because there's no checking that there is in fact a sane
>> string (null terminated), but I haven't been around long enough to be
>> sure that's the issue or if there's just something more sensible in
>> boost.
>>
>> I'd be happy with a link on the topic; I couldn't find anything useful
>> googling.
>>
>> -Nathan
>>
> The standard C string functions (the unconstrained ones) are well-known to
> be unsafe, and a rich source of buffer-overrun bugs/attacks in the
>   last couple of decades.
>
> Still, it's so much more convenient to type strcmp (a,b) rather than strncmp
> (a,b,l), etc, etc.
>
> So, sometimes you slip up and use the "unsafe" version.
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org


Yeah. Basically, you can send a string of any length and strcmp will
attempt to read it, which is what can lead to the buffer overrun.

Another problem, aside from laziness as Marcus says, is that you don't
often know the correct value for 'l'. It's just as suspect to
strlen(a) for some random string a. In this case, I /know/ that string
b is properly terminated (because I wrote it into the code). So I use
the length of b to compare with a and l = strlen(b). There are other
ways, too, but this was the most unobtrusive way to handle this case.

Tom

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

Re: [Discuss-gnuradio] GRC Fails to Display QT/WX Elements

[Tom Rondeau]

On Fri, Jun 21, 2013 at 4:06 PM, Volker Schroer  wrote:
> Do you see any messages in /var/log/Xorg.0.log or /var/log/dmesg ?
>
> Am 21.06.2013 15:43, schrieb Crypto.Troop:
>>
>> Hi Volker,
>>
>> Yes sir, I've added throttles, and tried all of the provided demo's. I've
>> also done more research, and further down the list are people talking about
>> the same thing...
>>
>>
>> http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00373.html
>>
>>
>> so I have hope it's not just me... :)
>>
>>
>> Thanks,
>>
>> Mark
>>
>>
>>> May be a silly question, but does your flow graph contain >a throttle
>>> block ?
>>>
>>> -- Volker
>>
>>
>>
>>
>> Am 21.06.2013 04:55, schrieb Crypto.Troop:
>>
>> Hi,
>>
>> I just installed GNURADIO from git, onto a brand new install of Mint
>> 15.
>> I followed the following instructions:
>> http://bgamari.github.io/posts/2013-06-15-hackrf.html
>>
>> gnuradio-config-info -v
>> 3.7.0git-143-gad1d52fd
>>
>> With Python 2.7, I was able to get everything compiled and installed.
>> The CMakeLists.txt in GNURADIO I had to tweak line(168)
>> to: find_package(PythonLibs 2.7) for it to include Python support.
>>
>> My environment vars:
>> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
>> PYTHONPATH=:/usr/local/lib/python2.7/dist-packages
>>
>> I built GNURADIO with the following cmake:
>> cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7
>> -DPYTHON_INCLUDE_DIR=/usr/include/python2.7
>> -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1 ../
>>
>> I fire up gnuradio-companion and try a simple example dial_tone.grc. I
>> click generate, then execute, I see the standard "Executing
>> ..."/tmp/dial_tone.py" "Using Volk machine: svx_64_mmx"  etc... No
>> other
>> errors. My problem is, no QT/WX GUI elements show up.
>>
>> I built a simple grc file with a QT slider(and nothing else), and this
>> worked.
>> I tried a basic signal source, through a throttle right into a QT FFT
>> GUI element. The grc runs, no errors, yet the physical display of the
>> FFT fails.
>> I have on another box gnuradio 3.6.5 and all of this worked fine. I
>> compared qt/wx/python debs and verified both machines have similar
>> packages.
>>
>> The key common factor in this problem is if i remove the signal
>> sources
>> and sinks, the QT/WX basic sliders will show... Perhaps there is
>> something wrong with my version of gnuradio and how it handles
>> inputs/outputs, killing GUI display? I've also tried compiling against
>> python3, 3.3 and 3.3m...no luck.
>>
>> Is there a way I can enable an extra layer of debug into GRC for me to
>> see what it's doing??
>> I've tried running /tmp/dial_tone.py directly and it run's, but no
>> audio
>> or gui elements display. Another hint which may help, is a basic audio
>> source to audio sink, set to "pulse" does not output audio into my
>> speakers. The audio does work with the OS audio tests, and I am
>> running
>> pulseaudio.
>>
>> I would like to stay with the latest GNURADIO simply to support my
>> HackRf board, in which the HackRf gr-osmosdr library seems to only
>> support the latest version. I tried with 3.6.5 and it failed to
>> compile...
>>
>> Thank you for any insight,
>> Mark


By the way, I just pushed a fix to master that should correct this problem.

Tom

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

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

[Tom Rondeau]

On Fri, Jun 21, 2013 at 4:43 PM, George Nychis  wrote:
> Great suggestion, Jonathan.  I've never used bisect (still migrating
> myself over to the git world), but I'll check out bisect and see if I
> can track down this bug.

George,

This should already be fixed. I pushed it to master an hour ago or so.

Tom


> On Fri, Jun 21, 2013 at 4:40 PM, Johnathan Corgan
>  wrote:
>> On Fri, Jun 21, 2013 at 1:36 PM, George Nychis  wrote:
>>
>>>
>>> I'm still trying to track this down to an exact commit that breaks
>>> this, but I know so far that the GUIs were not broken as of this
>>> commit:
>>>
>>>
>>> http://gnuradio.org/cgit/gnuradio.git/commit/?id=http://gnuradio.org/cgit/gnuradio.git/commit/?id=81cba98cb1a3adec261aa6b510ee152c3a24bb0d
>>>
>>> Trying to divide and conquer with a little bit of intelligence in what
>>> was committed...
>>
>>
>> Using git bisect is the best way I've found to discover these things; it
>> takes the guesswork out and scales O(log(n)) in the number of commits
>> between good and bad versions.
>>
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

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

Re: [Discuss-gnuradio] GUIs are not showing in 'master'

[George Nychis]

Great suggestion, Jonathan.  I've never used bisect (still migrating
myself over to the git world), but I'll check out bisect and see if I
can track down this bug.

On Fri, Jun 21, 2013 at 4:40 PM, Johnathan Corgan
 wrote:
> On Fri, Jun 21, 2013 at 1:36 PM, George Nychis  wrote:
>
>>
>> I'm still trying to track this down to an exact commit that breaks
>> this, but I know so far that the GUIs were not broken as of this
>> commit:
>>
>>
>> http://gnuradio.org/cgit/gnuradio.git/commit/?id=http://gnuradio.org/cgit/gnuradio.git/commit/?id=81cba98cb1a3adec261aa6b510ee152c3a24bb0d
>>
>> Trying to divide and conquer with a little bit of intelligence in what
>> was committed...
>
>
> Using git bisect is the best way I've found to discover these things; it
> takes the guesswork out and scales O(log(n)) in the number of commits
> between good and bad versions.
>
>
> --
> 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] GUIs are not showing in 'master'

[Johnathan Corgan]

On Fri, Jun 21, 2013 at 1:36 PM, George Nychis  wrote:


> I'm still trying to track this down to an exact commit that breaks
> this, but I know so far that the GUIs were not broken as of this
> commit:
>
>
> http://gnuradio.org/cgit/gnuradio.git/commit/?id=http://gnuradio.org/cgit/gnuradio.git/commit/?id=81cba98cb1a3adec261aa6b510ee152c3a24bb0d
>
> Trying to divide and conquer with a little bit of intelligence in what
> was committed...
>

Using git bisect is the best way I've found to discover these things; it
takes the guesswork out and scales O(log(n)) in the number of commits
between good and bad versions.

-- 
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] GUIs are not showing in 'master'

[George Nychis]

I'm still trying to track this down to an exact commit that breaks
this, but I know so far that the GUIs were not broken as of this
commit:

http://gnuradio.org/cgit/gnuradio.git/commit/?id=http://gnuradio.org/cgit/gnuradio.git/commit/?id=81cba98cb1a3adec261aa6b510ee152c3a24bb0d

Trying to divide and conquer with a little bit of intelligence in what
was committed...

On Wed, Jun 19, 2013 at 2:49 AM, George Nychis  wrote:
> My build is running on Ubuntu 12.04 within Parallels ,8 on a OS X
> 10.8.4 host (MacBook Air).  If there's any more debugging I can do to
> help this out, let me know
>
> On Tue, Jun 18, 2013 at 5:36 PM, Johnathan Corgan
>  wrote:
>> On Tue, Jun 18, 2013 at 2:22 PM, George Nychis  wrote:
>>>
>>> But if this were reverted, the Linux build should not be currently broken
>>> on the master HEAD, should it?
>>
>> I reverted the commit during the hackfest in Virginia a couple weeks ago.  I
>> can't replicate any issues with Ubuntu 12.04 32- or 64-bit, and recently
>> used 13.04 32-bit with no problems.  It may be be GL driver related; all the
>> above configurations were using the nvidia binary driver.
>>
>> --
>> 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] Build Script issue

[Marcus D. Leech]

I am using Ubuntu 11.10.
Though I installed Gnu Radio on two systems using same script, it's 
not working on new system!


wget http://www.sbrac.org/files/build-gnuradio && chmod a+x 
./build-gnuradio && ./build-gnuradio


..
.
.
checking for library libboost ...Found library libboost
Checking for library libcppunit ...Found library libcppunit
Checking for library libfftw ...Found library libfftw
Checking for library libgsl ...Found library libgsl
Done
Skipping git fetch, since 'uhd' and 'gnuradio' are new enough
*Starting function uhd_build at: Sat Jun 22 01:37:16 IST 2013
Building UHD...
=> THIS WILL TAKE SOME TIME <=

./build-gnuradio: line 780: cd: uhd/host: No such file or directory
UHD build apparently failed
Exiting UHD build*



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

You probably interrupted a fetch of UHD at "just the right moment".

rm -rf uhd

And run the script again.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Build Script issue

[Josh Blum]

On 06/21/2013 04:10 PM, Jay Prakash wrote:
> I am using Ubuntu 11.10.
> Though I installed Gnu Radio on two systems using same script, it's not
> working on new system!
> 
> wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
> ./build-gnuradio && ./build-gnuradio
> 
> ..
> .
> .
> checking for library libboost ...Found library libboost
> Checking for library libcppunit ...Found library libcppunit
> Checking for library libfftw ...Found library libfftw
> Checking for library libgsl ...Found library libgsl
> Done
> Skipping git fetch, since 'uhd' and 'gnuradio' are new enough
> *Starting function uhd_build at: Sat Jun 22 01:37:16 IST 2013
> Building UHD...
> => THIS WILL TAKE SOME TIME <=
> 
> ./build-gnuradio: line 780: cd: uhd/host: No such file or directory
> UHD build apparently failed
> Exiting UHD build*
> 

Chances are that this is the same firewall issue that you mentioned last
week. There are a lot of https links in the script. Why dont you find
out why your network is blocking https or if its a PC setup issue?

-josh

> 
> 
> ___
> 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] GUI problems with 3.7

[Marcus D. Leech]

On Fri, Jun 21, 2013 at 3:39 PM, Tom Rondeau  wrote:

On Fri, Jun 21, 2013 at 12:41 PM, Marcus D. Leech  wrote:

There are safe uses for unconstrained string functions.  Just, well, not
very many...

--
Marcus Leech

No. Never, ever, ever is it ok. I say this using a strlen call now...
(but it's against strings that are hard-coded into our files by us, so
if that breaks, we have only ourselves to blame).

Also, just pushed a fix. This should take care of things.

Tom

Pardon my ignorance here, but would someone mind explaining this a
little more? My intuition is saying that it's unsafe to use strcmp on
user input because there's no checking that there is in fact a sane
string (null terminated), but I haven't been around long enough to be
sure that's the issue or if there's just something more sensible in
boost.

I'd be happy with a link on the topic; I couldn't find anything useful googling.

-Nathan

The standard C string functions (the unconstrained ones) are well-known 
to be unsafe, and a rich source of buffer-overrun bugs/attacks in the

  last couple of decades.

Still, it's so much more convenient to type strcmp (a,b) rather than 
strncmp (a,b,l), etc, etc.


So, sometimes you slip up and use the "unsafe" version.



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

[Discuss-gnuradio] Build Script issue

[Jay Prakash]

I am using Ubuntu 11.10.
Though I installed Gnu Radio on two systems using same script, it's not
working on new system!

wget http://www.sbrac.org/files/build-gnuradio && chmod a+x
./build-gnuradio && ./build-gnuradio

..
.
.
checking for library libboost ...Found library libboost
Checking for library libcppunit ...Found library libcppunit
Checking for library libfftw ...Found library libfftw
Checking for library libgsl ...Found library libgsl
Done
Skipping git fetch, since 'uhd' and 'gnuradio' are new enough
*Starting function uhd_build at: Sat Jun 22 01:37:16 IST 2013
Building UHD...
=> THIS WILL TAKE SOME TIME <=

./build-gnuradio: line 780: cd: uhd/host: No such file or directory
UHD build apparently failed
Exiting UHD build*
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] GRC Fails to Display QT/WX Elements

[Volker Schroer]

Do you see any messages in /var/log/Xorg.0.log or /var/log/dmesg ?

Am 21.06.2013 15:43, schrieb Crypto.Troop:

Hi Volker,

Yes sir, I've added throttles, and tried all of the provided demo's. I've also 
done more research, and further down the list are people talking about the same 
thing...


http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00373.html


so I have hope it's not just me... :)


Thanks,

Mark



May be a silly question, but does your flow graph contain >a throttle block ?

-- Volker




Am 21.06.2013 04:55, schrieb Crypto.Troop:

Hi,

I just installed GNURADIO from git, onto a brand new install of Mint 15.
I followed the following instructions:
http://bgamari.github.io/posts/2013-06-15-hackrf.html

gnuradio-config-info -v
3.7.0git-143-gad1d52fd

With Python 2.7, I was able to get everything compiled and installed.
The CMakeLists.txt in GNURADIO I had to tweak line(168)
to: find_package(PythonLibs 2.7) for it to include Python support.

My environment vars:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
PYTHONPATH=:/usr/local/lib/python2.7/dist-packages

I built GNURADIO with the following cmake:
cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7
-DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1 ../

I fire up gnuradio-companion and try a simple example dial_tone.grc. I
click generate, then execute, I see the standard "Executing
..."/tmp/dial_tone.py" "Using Volk machine: svx_64_mmx"  etc... No other
errors. My problem is, no QT/WX GUI elements show up.

I built a simple grc file with a QT slider(and nothing else), and this
worked.
I tried a basic signal source, through a throttle right into a QT FFT
GUI element. The grc runs, no errors, yet the physical display of the
FFT fails.
I have on another box gnuradio 3.6.5 and all of this worked fine. I
compared qt/wx/python debs and verified both machines have similar packages.

The key common factor in this problem is if i remove the signal sources
and sinks, the QT/WX basic sliders will show... Perhaps there is
something wrong with my version of gnuradio and how it handles
inputs/outputs, killing GUI display? I've also tried compiling against
python3, 3.3 and 3.3m...no luck.

Is there a way I can enable an extra layer of debug into GRC for me to
see what it's doing??
I've tried running /tmp/dial_tone.py directly and it run's, but no audio
or gui elements display. Another hint which may help, is a basic audio
source to audio sink, set to "pulse" does not output audio into my
speakers. The audio does work with the OS audio tests, and I am running
pulseaudio.

I would like to stay with the latest GNURADIO simply to support my
HackRf board, in which the HackRf gr-osmosdr library seems to only
support the latest version. I tried with 3.6.5 and it failed to compile...

Thank you for any insight,
Mark



___
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] GUI problems with 3.7

[Nathan West]

On Fri, Jun 21, 2013 at 3:39 PM, Tom Rondeau  wrote:
>
> On Fri, Jun 21, 2013 at 12:41 PM, Marcus D. Leech  wrote:
> > There are safe uses for unconstrained string functions.  Just, well, not
> > very many...
> >
> > --
> > Marcus Leech
>
> No. Never, ever, ever is it ok. I say this using a strlen call now...
> (but it's against strings that are hard-coded into our files by us, so
> if that breaks, we have only ourselves to blame).
>
> Also, just pushed a fix. This should take care of things.
>
> Tom

Pardon my ignorance here, but would someone mind explaining this a
little more? My intuition is saying that it's unsafe to use strcmp on
user input because there's no checking that there is in fact a sane
string (null terminated), but I haven't been around long enough to be
sure that's the issue or if there's just something more sensible in
boost.

I'd be happy with a link on the topic; I couldn't find anything useful googling.

-Nathan

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

Re: [Discuss-gnuradio] GUI problems with 3.7

[Tom Rondeau]

On Fri, Jun 21, 2013 at 12:41 PM, Marcus D. Leech  wrote:
> On 06/21/2013 12:38 PM, Tom Rondeau wrote:
>>
>> First, I think calling it a GUI problem was a red herring. The problem
>> was much more fundamental. I traced it down to a 'strcmp'. And I am
>> very put out with whoever used that function in the first place.
>>
>> Just testing out the solution now and should have a fix pushed shortly.
>>
>> Tom
>>
> There are safe uses for unconstrained string functions.  Just, well, not
> very many...
>
> --
> Marcus Leech

No. Never, ever, ever is it ok. I say this using a strlen call now...
(but it's against strings that are hard-coded into our files by us, so
if that breaks, we have only ourselves to blame).

Also, just pushed a fix. This should take care of things.

Tom

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

Re: [Discuss-gnuradio] New SDR available

[Johnathan Corgan]

On Fri, Jun 21, 2013 at 12:21 PM, Matt D  wrote:


> On 06/19/2013 05:21 PM, mesar...@cox.net wrote:
>
> Zephyr Engineering has released a new SDR receiver with Gnu Radio
> compatibility:
> > http://sdrstick.com/
> >
> So this is supposed to be much better than the 20$ RTL sticks I use with
> GNU radio?  What will it do better that the cheap 20$ USB sticks?
>

I recommend you ask these types of questions directly of the manufacturer;
they have a contact address on their webpage.

-- 
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] New SDR available

[Matt D]

On 06/19/2013 05:21 PM, mesar...@cox.net wrote:
> Zephyr Engineering has released a new SDR receiver with Gnu Radio 
> compatibility:
> http://sdrstick.com/
> 
So this is supposed to be much better than the 20$ RTL sticks I use with
GNU radio?  What will it do better that the cheap 20$ USB sticks?
Currently I use the e4000 but that is only because I am low on cash. I
am trying to gather some funds for a real SDR like the USRP.

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

Re: [Discuss-gnuradio] HIer block---Generate error

[stefosee]

Yes, the problem was the greek words in the path!
Thank you very much! :)



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/HIer-block-Generate-error-tp42161p42185.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] Anyone have any clue? I've run out of ideas

[Marcus D. Leech]

User has run build-gnuradio.  The verbose log looks just fine, their 
settings for PYTHONPATH, and ld.so.conf.d settings are all just fine.


Yet, for osmosdr:



michele@Workstation:~$ python -c "import osmosdr"
linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.003-83-g3924a4d7

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/__init__.py", 
line 45, in 

from osmosdr_swig import *
  File 
"/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 
26, in 

_osmosdr_swig = swig_import_helper()
  File 
"/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 
22, in swig_import_helper

_mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: dynamic module does not define init function 
(init_osmosdr_swig)


And gnuradio itself:

michele@Workstation:~$ python -c "import osmosdr"
linux; GNU C++ version 4.7.3; Boost_105300; UHD_003.005.003-83-g3924a4d7

Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/local/lib/python2.7/dist-packages/osmosdr/__init__.py", 
line 45, in 

from osmosdr_swig import *
  File 
"/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 
26, in 

_osmosdr_swig = swig_import_helper()
  File 
"/usr/local/lib/python2.7/dist-packages/osmosdr/osmosdr_swig.py", line 
22, in swig_import_helper

_mod = imp.load_module('_osmosdr_swig', fp, pathname, description)
ImportError: dynamic module does not define init function 
(init_osmosdr_swig)


And of course, when they try to run gnuradio-companion, it all falls apart.

This rather looks like a linker issue, but I can't find any reason for 
it.  The target system is Ubuntu 13.04 x86_64.


I've been through their build log--nothing untoward.  Their system 
appears to be configured properly, and PYTHONPATH appears to be good.

  But this persists.  I even had them manually:

sudo ldconfig /usr/local/lib

Just to see if maybe the config in ld.so.conf.d wasn't being handled.

The only thing I can think of now is that se-linux is getting in the 
way, but does Ubuntu 13.04 ship with se-linux turned on?



--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] HIer block---Generate error

[Josh Blum]

On 06/21/2013 01:59 PM, stefosee wrote:
>  
> 
> 

Can you try using an all ASCII path for the grc file? I think the XML
parser may be having trouble w/ the characters in the file path.

-josh

> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/HIer-block-Generate-error-tp42161p42181.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] Meetup in London?

[Mike Jameson]

Hi Tom,

Count me in! Either day is good for me.

Cheers,

Mike
 On 21 Jun 2013 15:11, "Tom Rondeau"  wrote:

> Hi everyone,
>
> I'll be in London the week of July 8 for a few lectures at a summer
> school at King's College [1]. I'd like to have a meetup of GNU Radio
> and SDR people while I'm in town. I'm working with a venue now to set
> things up. We can either do Tuesday (July 9) or Thursday (July 11).
>
> Can I get a show of hands who might be able and willing to come out
> and join me for an evening? If there's a strong preference on the
> date, let me know that, too.
>
> Tom
>
> [1] http://www.iot.kcl.ac.uk/summerschool2013/
>
> ___
> 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] HIer block---Generate error

[stefosee]

 



--
View this message in context: 
http://gnuradio.4.n7.nabble.com/HIer-block-Generate-error-tp42161p42181.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] HIer block---Generate error

[Josh Blum]

On 06/21/2013 07:02 AM, stefosee wrote:
> Hi,
> 
> i'm trying to create my first hier block following these rules:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Hierarchical-Blocks
> 
> but when i'm going to generate the flow graph, i get the error message:
> 
> Generate Error: All strings must be XML compatible: Unicode or ASCII, no
> NULL bytes or control characters
> 

Is there more verbose to go with that error?

Can you attach a minimal example that causes the problem?

-josh

> I also tried a very simple graph like pad
> source(float)->throttle(float)->pad sink(float) but i face the same problem.  
> 
> throttle rate's value is the value of a parameter i set as sample_rate.
> 
> Any advice?
> thx
> 
> 
> 
> 
> 
> 
> --
> View this message in context: 
> http://gnuradio.4.n7.nabble.com/HIer-block-Generate-error-tp42161.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] Run time FIFO error

[Josh Blum]

On 06/21/2013 09:41 AM, Tim Newman wrote:
> Yes, bringing this back up. Back to the original topic.  When I get this
> FIFO ctrl error, the host is sending back an icmp port unreachable msg to
> the usrp, I grab this using wireshark.
> 

Well if the app shutdown from the error. That could be the host's
response to a stray packet coming from the USRP after the socket was
closed. For example a UDP packet w/ a GPSDO NMEA message. So this ICMP
error may not be indicative of anything.

> All I'm doing is running "uhd_usrp_probe".  I've tried with and without
> adding the --args addr= parameter, same thing using both.
> 
> I've debugged a bit, and increased the ACK_TIMEOUT in
> usrp/usrp2/usrp2_fifo_ctrl.cpp from 0.5 to 10.0 and it literally just sits
> at:
> 
> Creating the usrp device with: ...
> -- Opening a USRP2/N-Series device...
> -- Current recv frame size: 1472 bytes
> -- Current send frame size: 1472 bytes
> 
> 
> Then spits out
> RuntimeError: RuntimeError: fifo ctrl timed out looking for acks
> 
> Again, there is a switch in between the USRP and the host.
> 

Yup, definitely a lost packet. Its gone and more time isnt going to
help. Question is, where is the packet lost? We have a control packet
from host to switch, then switch to USRP. Then a response packet from
USRP to switch, then switch to host.

-josh

> Tim
> 
> 
> On Thu, Jun 13, 2013 at 12:27 AM, Sean Nowlan
> wrote:
> 
>> I think 512 is the max value for N on N200/N210 hence 195kSps is minimum
>> sample rate.
>>
>>
>> Karan Talasila  wrote:
>>
>> @sean can you please tell me how you got minimum sampling rate for usrp
>> N210 as 100*e6/512. I know that the sampling rate should be 100*e6/N where
>> N is an integer. So N can be any integer even greater than 512 right. In
>> that way, what is the minimum that the USRP accepts. what is maximum N that
>> can be used.
>>
>>
>> On Thu, Jun 13, 2013 at 6:20 AM, Sean Nowlan 
>> wrote:
>>
>>> On 06/12/2013 08:49 PM, Marcus D. Leech wrote:
>>>
 On 06/12/2013 08:29 PM, Sean Nowlan wrote:

>
> The minimum "reasonable" sample rate I've used is 2e5 (100e6/2e5 =
> 500). I think 100e6/512 = 195312.5 is the smallest supported rate.
>
>  Yup, sorry, you're right.  I tend to pick values that are valid for
 both 64Msps and 100Msps master clock rates, since I write apps that need to
 be reasonably
   agnostic with respect to hardware.


  Ah, makes sense.
>>>
>>>


>>>
>>> __**_
>>> Discuss-gnuradio mailing list
>>> Discuss-gnuradio@gnu.org
>>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>>>
>>
>>
>>
>> --
>> Regards
>> Karan Talasila
>>
>> ___
>> 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] WX GUI Widgets missing

[Marcus D. Leech]

On 06/21/2013 01:11 PM, Josh Blum wrote:


On 06/21/2013 04:35 AM, Les Barker wrote:

Hi All

I have built gnuradio from the s.b.r.a.c link without any errors.
When using GR Companion there are only 2 items under WX GUI Widgets i.e. Plot 
Sink and WX DOA Compass. The waterfall sink and FFT sink, together with many 
others, are not available.

I have checked under the "blocks" list and these are listed.

How do I get GRC to make these blocks available?

Either you didnt have wx python installed when gnuradio was configured
or the category has moved. Try looking inGUI
Widgets/WX  or use the search feature.

-josh

The GUI things like FFT sinks, Scope Sinks, etc, have moved under 
"Instrumentation"





--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] WX GUI Widgets missing

[Josh Blum]

On 06/21/2013 04:35 AM, Les Barker wrote:
> Hi All
> 
> I have built gnuradio from the s.b.r.a.c link without any errors.
> When using GR Companion there are only 2 items under WX GUI Widgets i.e. Plot 
> Sink and WX DOA Compass. The waterfall sink and FFT sink, together with many 
> others, are not available.
> 
> I have checked under the "blocks" list and these are listed.
> 
> How do I get GRC to make these blocks available?

Either you didnt have wx python installed when gnuradio was configured
or the category has moved. Try looking in GUI
Widgets/WX or use the search feature.

-josh

> 
> Your help will be appreciated.
> 
> Regards
> Les
> 
> 
> 
> ___
> 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] GRC Fails to Display QT/WX Elements

[Sean Nowlan]

On 06/21/2013 09:56 AM, Tom Rondeau wrote:
The only thing that comes to mind is a problem we had with something 
else that seems to be a result of using GCC 4.7. I always just use 4.6 
to that I can build and use ControlPort. If someone who is having 
these problems can tell me if they are using 4.7 or not, that'd be 
great. Also, if you are using 4.7, could you move back to using 4.6 
and rebuild GNU Radio with that and see if that fixes things? You can 
apt-get install {gcc-4.6, g++-4.6} and then symlink /usr/bin/gcc-4.6 
to /usr/local/bin/{gcc,cc} and /usr/bin/g++ /usr/local/bin/{g++,c++}. 
Tom ___ Discuss-gnuradio 
mailing list Discuss-gnuradio@gnu.org 
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio 


On a Ubuntu system I find it easier to pass cmake the following to use 
GCC 4.6 instead of messing around with symlinks:


cd ~/gnuradio/build
cmake -DCMAKE_CXX_COMPILER=g++-4.6 -DCMAKE_C_COMPILER=gcc-4.6 
-DENABLE_GR_CTRLPORT=ON ../


--sean

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

[Discuss-gnuradio] GUI problems with 3.7

[Tom Rondeau]

First, I think calling it a GUI problem was a red herring. The problem
was much more fundamental. I traced it down to a 'strcmp'. And I am
very put out with whoever used that function in the first place.

Just testing out the solution now and should have a fix pushed shortly.

Tom

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

Re: [Discuss-gnuradio] GUI problems with 3.7

[Marcus D. Leech]

On 06/21/2013 12:38 PM, Tom Rondeau wrote:

First, I think calling it a GUI problem was a red herring. The problem
was much more fundamental. I traced it down to a 'strcmp'. And I am
very put out with whoever used that function in the first place.

Just testing out the solution now and should have a fix pushed shortly.

Tom

There are safe uses for unconstrained string functions.  Just, well, not 
very many...




--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] Meetup in London?

[Iain Young, G7III]

Hi Tom,

I'm up for that. The Tuesday or Thursday are both good for me, just
let me know where and when, and I'll sort out how to get there (I
live approx 1 hour by train from London)


Iain

On 21/06/13 15:10, Tom Rondeau wrote:

Hi everyone,

I'll be in London the week of July 8 for a few lectures at a summer
school at King's College [1]. I'd like to have a meetup of GNU Radio
and SDR people while I'm in town. I'm working with a venue now to set
things up. We can either do Tuesday (July 9) or Thursday (July 11).

Can I get a show of hands who might be able and willing to come out
and join me for an evening? If there's a strong preference on the
date, let me know that, too.

Tom

[1] http://www.iot.kcl.ac.uk/summerschool2013/

___
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] Meetup in London?

[Ben Reynwar]

I'll be in England that week, and should be able to make it.  No
preference on the day.

On Fri, Jun 21, 2013 at 7:10 AM, Tom Rondeau  wrote:
> Hi everyone,
>
> I'll be in London the week of July 8 for a few lectures at a summer
> school at King's College [1]. I'd like to have a meetup of GNU Radio
> and SDR people while I'm in town. I'm working with a venue now to set
> things up. We can either do Tuesday (July 9) or Thursday (July 11).
>
> Can I get a show of hands who might be able and willing to come out
> and join me for an evening? If there's a strong preference on the
> date, let me know that, too.
>
> Tom
>
> [1] http://www.iot.kcl.ac.uk/summerschool2013/
>
> ___
> 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] Introducing PyBOMBS!

[Tom Rondeau]

We would like to introduce everyone to our new GNU Radio build system,
PyBOMBS. For more details, see the new project page:

gnuradio.org/pybombs

This is meant to offer an easy way to build GNU Radio and its
dependencies. It's also a really nice way to co-locate and build
out-of-tree projects (gr-osmosdr, gr-baz, etc.). We encourage people
who have out-of-tree projects that you'd like to have more visibility
to submit new recipes for your project. The wiki page in the above
link should help you do this using github and pull requests. But first
check to see if your project is already there as many of them are.

PyBOMBS will hopefully take the burden off of Marcus for his
build-gnuradio script, which was a great solution, but he's expressed
his interest in moving on. One benefit of PyBOMBS is the easier
inclusion of other OOT projects and the ability to selectively and
easily install them.

Note that this has been developed for Debian/Ubunut and Redhat/Fedora.
So it wants to use debs and rpms where possible. It will be buggy on
other systems, though it should be able to install everything from
source if the recipe is built correctly. Patches are welcome!

Tom

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

[Discuss-gnuradio] GNU Radio release candidate 3.7.0rc0 available for download and testing

[Johnathan Corgan]

GNU Radio release candidate 3.7.0rc0 is available for download and testing:

http://gnuradio.org/releases/gnuradio/gnuradio-3.7.0rc0.tar.gz

This is a snapshot of the repository master branch at tag v3.7.0rc0, and is
intended for final testing by users.

As this is not a formal release, it is not accompanied by release notes.
The full list of changes between the 3.6 and 3.7 APIs will be made
available at the time of 3.7.0 release.

It does indicate, however, that the 3.7 API is now frozen and we will only
be merging bug fixes into the source code until the final release.
 --
Johnathan Corgan
Corgan Labs - SDR Training and Development Services
http://corganlabs.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Meetup in London?

[Tom Rondeau]

Hi everyone,

I'll be in London the week of July 8 for a few lectures at a summer
school at King's College [1]. I'd like to have a meetup of GNU Radio
and SDR people while I'm in town. I'm working with a venue now to set
things up. We can either do Tuesday (July 9) or Thursday (July 11).

Can I get a show of hands who might be able and willing to come out
and join me for an evening? If there's a strong preference on the
date, let me know that, too.

Tom

[1] http://www.iot.kcl.ac.uk/summerschool2013/

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

Re: [Discuss-gnuradio] GRC Fails to Display QT/WX Elements

[Tom Rondeau]

On Thu, Jun 20, 2013 at 10:55 PM, Crypto.Troop  wrote:
> Hi,
>
> I just installed GNURADIO from git, onto a brand new install of Mint 15. I
> followed the following instructions:
> http://bgamari.github.io/posts/2013-06-15-hackrf.html
>
> gnuradio-config-info -v
> 3.7.0git-143-gad1d52fd
>
> With Python 2.7, I was able to get everything compiled and installed. The
> CMakeLists.txt in GNURADIO I had to tweak line(168) to:
> find_package(PythonLibs 2.7) for it to include Python support.
>
> My environment vars:
> PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
> PYTHONPATH=:/usr/local/lib/python2.7/dist-packages
>
> I built GNURADIO with the following cmake:
> cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7
> -DPYTHON_INCLUDE_DIR=/usr/include/python2.7
> -DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1 ../
>
> I fire up gnuradio-companion and try a simple example dial_tone.grc. I click
> generate, then execute, I see the standard "Executing ..."/tmp/dial_tone.py"
> "Using Volk machine: svx_64_mmx"  etc... No other errors. My problem is, no
> QT/WX GUI elements show up.

There are only 2 WX sliders in this graph, no other gui elements. You
are saying that neither of those sliders appear?

> I built a simple grc file with a QT slider(and nothing else), and this
> worked.
> I tried a basic signal source, through a throttle right into a QT FFT GUI
> element. The grc runs, no errors, yet the physical display of the FFT fails.
> I have on another box gnuradio 3.6.5 and all of this worked fine. I compared
> qt/wx/python debs and verified both machines have similar packages.
>
> The key common factor in this problem is if i remove the signal sources and
> sinks, the QT/WX basic sliders will show... Perhaps there is something wrong
> with my version of gnuradio and how it handles inputs/outputs, killing GUI
> display? I've also tried compiling against python3, 3.3 and 3.3m...no luck.

No, we don't have any guarantees or expectations that Python 3 will work.

> Is there a way I can enable an extra layer of debug into GRC for me to see
> what it's doing??

If you launched GRC from a terminal, take a look at the output of the
terminal when you run your program; you may see something there that
indicates what's going on. There's no extra verbose mode for GRC. You
can also just run the built .py file by hand in a terminal, which will
show you any errors or warnings generated, too.

> I've tried running /tmp/dial_tone.py directly and it run's, but no audio or
> gui elements display. Another hint which may help, is a basic audio source
> to audio sink, set to "pulse" does not output audio into my speakers. The
> audio does work with the OS audio tests, and I am running pulseaudio.

I tend to use 'pulse' with no problems. You could also try
'plughw:0,0' or just 'hw:0,0' to use the ALSA drivers directly.

> I would like to stay with the latest GNURADIO simply to support my HackRf
> board, in which the HackRf gr-osmosdr library seems to only support the
> latest version. I tried with 3.6.5 and it failed to compile...
>
> Thank you for any insight,
> Mark

Yeah, you'd have to go back a bit in the gr-osmosdr git history before
they updated to the 3.7 style.

Unfortunately, you aren't the only one who has claimed issues with the
GUI elements with 3.7. The biggest problem is that it seems random who
does and who does not have a problem. I've tested 3.7 on many machines
with different video cards, versions of Ubuntu, and non-Ubuntu Linux
VMs and all of them have worked fine for me. Without being able to
duplicate this error, I don't even know where to start with addressing
it.

The only thing that comes to mind is a problem we had with something
else that seems to be a result of using GCC 4.7. I always just use 4.6
to that I can build and use ControlPort. If someone who is having
these problems can tell me if they are using 4.7 or not, that'd be
great. Also, if you are using 4.7, could you move back to using 4.6
and rebuild GNU Radio with that and see if that fixes things? You can
apt-get install {gcc-4.6, g++-4.6} and then symlink /usr/bin/gcc-4.6
to /usr/local/bin/{gcc,cc} and /usr/bin/g++ /usr/local/bin/{g++,c++}.

Tom

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

Re: [Discuss-gnuradio] GRC Fails to Display QT/WX Elements

[Crypto.Troop]

Hi Volker,

Yes sir, I've added throttles, and tried all of the provided demo's.
I've also done more research, and further down the list are people
talking about the same thing...


http://lists.gnu.org/archive/html/discuss-gnuradio/2013-06/msg00373.html


so I have hope it's not just me... :)


Thanks,

Mark


>May be a silly question, but does your flow graph contain >a throttle block ?
>
>-- Volker



Am 21.06.2013 04:55, schrieb Crypto.Troop:

Hi,

I just installed GNURADIO from git, onto a brand new install of Mint 15.
I followed the following
instructions:http://bgamari.github.io/posts/2013-06-15-hackrf.html

gnuradio-config-info -v
3.7.0git-143-gad1d52fd

With Python 2.7, I was able to get everything compiled and installed.
The CMakeLists.txt in GNURADIO I had to tweak line(168)
to: find_package(PythonLibs 2.7) for it to include Python support.

My environment vars:
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:
PYTHONPATH=:/usr/local/lib/python2.7/dist-packages

I built GNURADIO with the following cmake:
cmake -DPYTHON_EXECUTABLE=/usr/bin/python2.7
-DPYTHON_INCLUDE_DIR=/usr/include/python2.7
-DPYTHON_LIBRARY=/usr/lib/x86_64-linux-gnu/libpython2.7.so.1 ../

I fire up gnuradio-companion and try a simple example dial_tone.grc. I
click generate, then execute, I see the standard "Executing
..."/tmp/dial_tone.py" "Using Volk machine: svx_64_mmx"  etc... No other
errors. My problem is, no QT/WX GUI elements show up.

I built a simple grc file with a QT slider(and nothing else), and this
worked.
I tried a basic signal source, through a throttle right into a QT FFT
GUI element. The grc runs, no errors, yet the physical display of the
FFT fails.
I have on another box gnuradio 3.6.5 and all of this worked fine. I
compared qt/wx/python debs and verified both machines have similar packages.

The key common factor in this problem is if i remove the signal sources
and sinks, the QT/WX basic sliders will show... Perhaps there is
something wrong with my version of gnuradio and how it handles
inputs/outputs, killing GUI display? I've also tried compiling against
python3, 3.3 and 3.3m...no luck.

Is there a way I can enable an extra layer of debug into GRC for me to
see what it's doing??
I've tried running /tmp/dial_tone.py directly and it run's, but no audio
or gui elements display. Another hint which may help, is a basic audio
source to audio sink, set to "pulse" does not output audio into my
speakers. The audio does work with the OS audio tests, and I am running
pulseaudio.

I would like to stay with the latest GNURADIO simply to support my
HackRf board, in which the HackRf gr-osmosdr library seems to only
support the latest version. I tried with 3.6.5 and it failed to compile...

Thank you for any insight,
Mark
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Run time FIFO error

[Tim Newman]

Yes, bringing this back up. Back to the original topic.  When I get this
FIFO ctrl error, the host is sending back an icmp port unreachable msg to
the usrp, I grab this using wireshark.

All I'm doing is running "uhd_usrp_probe".  I've tried with and without
adding the --args addr= parameter, same thing using both.

I've debugged a bit, and increased the ACK_TIMEOUT in
usrp/usrp2/usrp2_fifo_ctrl.cpp from 0.5 to 10.0 and it literally just sits
at:

Creating the usrp device with: ...
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes


Then spits out
RuntimeError: RuntimeError: fifo ctrl timed out looking for acks

Again, there is a switch in between the USRP and the host.

Tim


On Thu, Jun 13, 2013 at 12:27 AM, Sean Nowlan
wrote:

> I think 512 is the max value for N on N200/N210 hence 195kSps is minimum
> sample rate.
>
>
> Karan Talasila  wrote:
>
> @sean can you please tell me how you got minimum sampling rate for usrp
> N210 as 100*e6/512. I know that the sampling rate should be 100*e6/N where
> N is an integer. So N can be any integer even greater than 512 right. In
> that way, what is the minimum that the USRP accepts. what is maximum N that
> can be used.
>
>
> On Thu, Jun 13, 2013 at 6:20 AM, Sean Nowlan 
> wrote:
>
>> On 06/12/2013 08:49 PM, Marcus D. Leech wrote:
>>
>>> On 06/12/2013 08:29 PM, Sean Nowlan wrote:
>>>

 The minimum "reasonable" sample rate I've used is 2e5 (100e6/2e5 =
 500). I think 100e6/512 = 195312.5 is the smallest supported rate.

  Yup, sorry, you're right.  I tend to pick values that are valid for
>>> both 64Msps and 100Msps master clock rates, since I write apps that need to
>>> be reasonably
>>>   agnostic with respect to hardware.
>>>
>>>
>>>  Ah, makes sense.
>>
>>
>>>
>>>
>>
>> __**_
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>>
>
>
>
> --
> Regards
> Karan Talasila
>
> ___
> 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] Postprocessing simple_ra data

[Marcus D. Leech]

On 06/21/2013 07:08 AM, Alberto Trentadue wrote:

Hello

We would like to use data collected by simple_ra and post-process it with 
Octave.
May you please advise the most
straightforward way?

Thanks in advance
BR
Alberto



The README file that comes with simple_ra describes the data format used.

I'm not much of an Octave expert.

There are post-processing scripts that come with the software to produce 
graphs, etc.





--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org


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

Re: [Discuss-gnuradio] GNURadio - Failed rtl-sdr/gr-osmosdr build using buildscript

[Marcus D. Leech]

On 06/21/2013 05:39 AM, fei phung wrote:

dell@ubuntu:~$ ./build-gnuradio
This script will install Gnu Radio from current GIT sources
You will require Internet access from the computer on which this
script runs. You will also require SUDO access. You will require
approximately 500MB of free disk space to perform the build.

This script will, as a side-effect, remove any existing Gnu Radio
installation that was installed from your Linux distribution packages.
It must do this to prevent problems due to interference between
a linux-distribution-installed Gnu Radio/UHD and one installed from 
GIT source.


The whole process may take up to two hours to complete, depending on the
capabilities of your system.


NOTE: if you run into problems while running this script, you can 
re-run it with
the --verbose option to produce lots of diagnostic output to help 
debug problems.
This script has been written to anticipate some of the more common 
problems one might
encounter building ANY large, complex software package. But it is not 
pefect, and
there are certainly some situations it could encounter that it cannot 
deal with
gracefully. Altering the system configuration from something 
reasonably standard,
removing parts of the filesystem, moving system libraries around 
arbitrarily, etc,
it likely cannot cope with. It is just a script. It isn't intuitive or 
artificially
intelligent. It tries to make life a little easier for you, but at the 
end of the day

if it runs into trouble, a certain amount of knowledge on your part about
system configuration and idiosyncrasies will inevitably be necessary.


Proceed?y
Starting all functions at: Fri Jun 21 15:50:50 HKT 2013
SUDO privileges are required
Do you have SUDO privileges?y
Continuing with script
Installing prerequisites.
> THIS MAY TAKE QUITE SOME TIME <=
Checking for package libfontconfig1-dev
Checking for package libxrender-dev
Checking for package libpulse-dev
Checking for package swig
Checking for package g++
Checking for package automake
Checking for package autoconf
Checking for package libtool
Checking for package python-dev
Checking for package libfftw3-dev
Checking for package libcppunit-dev
Checking for package libboost1.48-all-dev
Checking for package libusb-dev
Checking for package libusb-1.0-0-dev
Checking for package fort77
Checking for package libsdl1.2-dev
Checking for package python-wxgtk2.8
Checking for package git-core
Checking for package libqt4-dev
Checking for package python-numpy
Checking for package ccache
Checking for package python-opengl
Checking for package libgsl0-dev
Checking for package python-cheetah
Checking for package python-lxml
Checking for package doxygen
Checking for package qt4-dev-tools
Checking for package libusb-1.0-0-dev
Checking for package libqwt5-qt4-dev
Checking for package libqwtplot3d-qt4-dev
Checking for package pyqt4-dev-tools
Checking for package python-qwt5-qt4
Checking for package cmake
Checking for package git-core
Checking for package wget
Checking for package libxi-dev
Checking for package python-docutils
Checking for package gtk2-engines-pixbuf
Checking for package r-base-dev
Checking for package python-tk
Checking for package liborc-0.4-0
Checking for package liborc-0.4-dev
Checking for package libasound2-dev
Checking for package python-gtk2
Done checking packages
Checking for library libusb ...Found library libusb
Checking for library libboost ...Found library libboost
Checking for library libcppunit ...Found library libcppunit
Checking for library libfftw ...Found library libfftw
Checking for library libgsl ...Found library libgsl
Done
Fetching various packages (Gnu Radio, UHD, gr-osmosdr, etc)
via the Internet
===> THIS MAY TAKE QUITE SOME TIME <=
Fetching Gnu Radio via GIT...Done
Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, and gr-osmosdr) via GIT
Done
Starting function uhd_build at: Fri Jun 21 15:56:45 HKT 2013
Building UHD...
=> THIS WILL TAKE SOME TIME <=

Done building/installing UHD
Done function uhd_build at: Fri Jun 21 16:07:24 HKT 2013
Starting function firmware at: Fri Jun 21 16:07:24 HKT 2013
Downloading images from: 
http://files.ettus.com/binaries/maint_images/archive/uhd-images_003.005.003-release.zip

 7.21 MB/7.21 MB (100.00%)
Images successfully installed to: /usr/local/share/uhd/images
Done downloading firmware to /usr/local/share/uhd/images
Done function firmware at: Fri Jun 21 16:07:57 HKT 2013
Starting function gnuradio_build at: Fri Jun 21 16:07:57 HKT 2013
/usr/local/lib already in ld.so.conf.d
Doing ldconfig...
Building Gnu Radio...
=> THIS WILL TAKE QUITE A WHILE <=

...Doing cmake
...Cmaking
...Building
...Installing
Done building and installing Gnu Radio
GRC freedesktop icons install ...Done
Done function gnuradio_build at: Fri Jun 21 17:10:56 HKT 2013
Starting function rtl_build at: Fri Jun 21 17:10:56 HKT 2013
Building rtl-sdr...g

Re: [Discuss-gnuradio] GNURadio - Failed rtl-sdr/gr-osmosdr build using buildscript

[Mike Jameson]

Hi,

Go into the gr-osmosdr directory and type 'make'.  When the build fails
again you should be able to pinpoint the problem from the error message
produced.

Regards,

Mike

--
Mike Jameson M0MIK BSc MIET
Email: m...@scanoo.com
Web: http://scanoo.com


On Fri, Jun 21, 2013 at 10:39 AM, fei phung  wrote:

> dell@ubuntu:~$ ./build-gnuradio
> This script will install Gnu Radio from current GIT sources
> You will require Internet access from the computer on which this
> script runs. You will also require SUDO access. You will require
> approximately 500MB of free disk space to perform the build.
>
> This script will, as a side-effect, remove any existing Gnu Radio
> installation that was installed from your Linux distribution packages.
> It must do this to prevent problems due to interference between
> a linux-distribution-installed Gnu Radio/UHD and one installed from GIT
> source.
>
> The whole process may take up to two hours to complete, depending on the
> capabilities of your system.
>
>
> 
> NOTE: if you run into problems while running this script, you can re-run
> it with
> the --verbose option to produce lots of diagnostic output to help debug
> problems.
> This script has been written to anticipate some of the more common
> problems one might
> encounter building ANY large, complex software package. But it is not
> pefect, and
> there are certainly some situations it could encounter that it cannot deal
> with
> gracefully. Altering the system configuration from something reasonably
> standard,
> removing parts of the filesystem, moving system libraries around
> arbitrarily, etc,
> it likely cannot cope with. It is just a script. It isn't intuitive or
> artificially
> intelligent. It tries to make life a little easier for you, but at the end
> of the day
> if it runs into trouble, a certain amount of knowledge on your part about
> system configuration and idiosyncrasies will inevitably be necessary.
>
>
> Proceed?y
> Starting all functions at: Fri Jun 21 15:50:50 HKT 2013
> SUDO privileges are required
> Do you have SUDO privileges?y
> Continuing with script
> Installing prerequisites.
> > THIS MAY TAKE QUITE SOME TIME <=
> Checking for package libfontconfig1-dev
> Checking for package libxrender-dev
> Checking for package libpulse-dev
> Checking for package swig
> Checking for package g++
> Checking for package automake
> Checking for package autoconf
> Checking for package libtool
> Checking for package python-dev
> Checking for package libfftw3-dev
> Checking for package libcppunit-dev
> Checking for package libboost1.48-all-dev
> Checking for package libusb-dev
> Checking for package libusb-1.0-0-dev
> Checking for package fort77
> Checking for package libsdl1.2-dev
> Checking for package python-wxgtk2.8
> Checking for package git-core
> Checking for package libqt4-dev
> Checking for package python-numpy
> Checking for package ccache
> Checking for package python-opengl
> Checking for package libgsl0-dev
> Checking for package python-cheetah
> Checking for package python-lxml
> Checking for package doxygen
> Checking for package qt4-dev-tools
> Checking for package libusb-1.0-0-dev
> Checking for package libqwt5-qt4-dev
> Checking for package libqwtplot3d-qt4-dev
> Checking for package pyqt4-dev-tools
> Checking for package python-qwt5-qt4
> Checking for package cmake
> Checking for package git-core
> Checking for package wget
> Checking for package libxi-dev
> Checking for package python-docutils
> Checking for package gtk2-engines-pixbuf
> Checking for package r-base-dev
> Checking for package python-tk
> Checking for package liborc-0.4-0
> Checking for package liborc-0.4-dev
> Checking for package libasound2-dev
> Checking for package python-gtk2
> Done checking packages
> Checking for library libusb ...Found library libusb
> Checking for library libboost ...Found library libboost
> Checking for library libcppunit ...Found library libcppunit
> Checking for library libfftw ...Found library libfftw
> Checking for library libgsl ...Found library libgsl
> Done
> Fetching various packages (Gnu Radio, UHD, gr-osmosdr, etc)
> via the Internet
> ===> THIS MAY TAKE QUITE SOME TIME <=
> Fetching Gnu Radio via GIT...Done
> Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, and gr-osmosdr) via GIT
> Done
> Starting function uhd_build at: Fri Jun 21 15:56:45 HKT 2013
> Building UHD...
> => THIS WILL TAKE SOME TIME <=
>
> Done building/installing UHD
> Done function uhd_build at: Fri Jun 21 16:07:24 HKT 2013
> Starting function firmware at: Fri Jun 21 16:07:24 HKT 2013
> Downloading images from:
> http://files.ettus.com/binaries/maint_images/archive/uhd-images_003.005.003-release.zip
>  7.21 MB/7.21 MB (100.00%)
> Images successfully installed to: /usr/local/share/uhd/images
> Done downloading firmware to /usr/local/share/uhd/images
> Done function firmware at: Fri Jun 21 16:07:57 HKT 2

[Discuss-gnuradio] Postprocessing simple_ra data

[Alberto Trentadue]

Hello

We would like to use data collected by simple_ra and post-process it with 
Octave.
May you please advise the most 
straightforward way?

Thanks in advance
BR
Alberto 


Invita i tuoi amici e Tiscali ti premia! Il consiglio di un amico vale più di 
uno spot in TV. Per ogni nuovo abbonato 30 € di premio per te e per lui! Un 
amico al mese e parli e navighi sempre gratis: http://freelosophy.tiscali.it/

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

[Discuss-gnuradio] HIer block---Generate error

[stefosee]

Hi,

i'm trying to create my first hier block following these rules:
http://gnuradio.org/redmine/projects/gnuradio/wiki/GNURadioCompanion#Hierarchical-Blocks

but when i'm going to generate the flow graph, i get the error message:

Generate Error: All strings must be XML compatible: Unicode or ASCII, no
NULL bytes or control characters

I also tried a very simple graph like pad
source(float)->throttle(float)->pad sink(float) but i face the same problem.  

throttle rate's value is the value of a parameter i set as sample_rate.

Any advice?
thx






--
View this message in context: 
http://gnuradio.4.n7.nabble.com/HIer-block-Generate-error-tp42161.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] GNURadio - Failed rtl-sdr/gr-osmosdr build using buildscript

[fei phung]

dell@ubuntu:~$ ./build-gnuradio
This script will install Gnu Radio from current GIT sources
You will require Internet access from the computer on which this
script runs. You will also require SUDO access. You will require
approximately 500MB of free disk space to perform the build.

This script will, as a side-effect, remove any existing Gnu Radio
installation that was installed from your Linux distribution packages.
It must do this to prevent problems due to interference between
a linux-distribution-installed Gnu Radio/UHD and one installed from GIT
source.

The whole process may take up to two hours to complete, depending on the
capabilities of your system.


NOTE: if you run into problems while running this script, you can re-run it
with
the --verbose option to produce lots of diagnostic output to help debug
problems.
This script has been written to anticipate some of the more common problems
one might
encounter building ANY large, complex software package. But it is not
pefect, and
there are certainly some situations it could encounter that it cannot deal
with
gracefully. Altering the system configuration from something reasonably
standard,
removing parts of the filesystem, moving system libraries around
arbitrarily, etc,
it likely cannot cope with. It is just a script. It isn't intuitive or
artificially
intelligent. It tries to make life a little easier for you, but at the end
of the day
if it runs into trouble, a certain amount of knowledge on your part about
system configuration and idiosyncrasies will inevitably be necessary.


Proceed?y
Starting all functions at: Fri Jun 21 15:50:50 HKT 2013
SUDO privileges are required
Do you have SUDO privileges?y
Continuing with script
Installing prerequisites.
> THIS MAY TAKE QUITE SOME TIME <=
Checking for package libfontconfig1-dev
Checking for package libxrender-dev
Checking for package libpulse-dev
Checking for package swig
Checking for package g++
Checking for package automake
Checking for package autoconf
Checking for package libtool
Checking for package python-dev
Checking for package libfftw3-dev
Checking for package libcppunit-dev
Checking for package libboost1.48-all-dev
Checking for package libusb-dev
Checking for package libusb-1.0-0-dev
Checking for package fort77
Checking for package libsdl1.2-dev
Checking for package python-wxgtk2.8
Checking for package git-core
Checking for package libqt4-dev
Checking for package python-numpy
Checking for package ccache
Checking for package python-opengl
Checking for package libgsl0-dev
Checking for package python-cheetah
Checking for package python-lxml
Checking for package doxygen
Checking for package qt4-dev-tools
Checking for package libusb-1.0-0-dev
Checking for package libqwt5-qt4-dev
Checking for package libqwtplot3d-qt4-dev
Checking for package pyqt4-dev-tools
Checking for package python-qwt5-qt4
Checking for package cmake
Checking for package git-core
Checking for package wget
Checking for package libxi-dev
Checking for package python-docutils
Checking for package gtk2-engines-pixbuf
Checking for package r-base-dev
Checking for package python-tk
Checking for package liborc-0.4-0
Checking for package liborc-0.4-dev
Checking for package libasound2-dev
Checking for package python-gtk2
Done checking packages
Checking for library libusb ...Found library libusb
Checking for library libboost ...Found library libboost
Checking for library libcppunit ...Found library libcppunit
Checking for library libfftw ...Found library libfftw
Checking for library libgsl ...Found library libgsl
Done
Fetching various packages (Gnu Radio, UHD, gr-osmosdr, etc)
via the Internet
===> THIS MAY TAKE QUITE SOME TIME <=
Fetching Gnu Radio via GIT...Done
Fetching UHD via GIT...Fetching rtl-sdr (rtl-sdr, and gr-osmosdr) via GIT
Done
Starting function uhd_build at: Fri Jun 21 15:56:45 HKT 2013
Building UHD...
=> THIS WILL TAKE SOME TIME <=

Done building/installing UHD
Done function uhd_build at: Fri Jun 21 16:07:24 HKT 2013
Starting function firmware at: Fri Jun 21 16:07:24 HKT 2013
Downloading images from:
http://files.ettus.com/binaries/maint_images/archive/uhd-images_003.005.003-release.zip
 7.21 MB/7.21 MB (100.00%)
Images successfully installed to: /usr/local/share/uhd/images
Done downloading firmware to /usr/local/share/uhd/images
Done function firmware at: Fri Jun 21 16:07:57 HKT 2013
Starting function gnuradio_build at: Fri Jun 21 16:07:57 HKT 2013
/usr/local/lib already in ld.so.conf.d
Doing ldconfig...
Building Gnu Radio...
=> THIS WILL TAKE QUITE A WHILE <=

...Doing cmake
...Cmaking
...Building
...Installing
Done building and installing Gnu Radio
GRC freedesktop icons install ...Done
Done function gnuradio_build at: Fri Jun 21 17:10:56 HKT 2013
Starting function rtl_build at: Fri Jun 21 17:10:56 HKT 2013
Building rtl-sdr...gr-osmosdr build apparently failed
Exit rtl-sdr/gr-osmosdr

[Discuss-gnuradio] WX GUI Widgets missing

[Les Barker]

Hi All

I have built gnuradio from the s.b.r.a.c link without any errors.
When using GR Companion there are only 2 items under WX GUI Widgets i.e. Plot 
Sink and WX DOA Compass. The waterfall sink and FFT sink, together with many 
others, are not available.

I have checked under the "blocks" list and these are listed.

How do I get GRC to make these blocks available?

Your help will be appreciated.

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