Re: [Discuss-gnuradio] GNU Radio LiveDVD 2013-1110 (based on 3.7.2)

[Ralph A. Schmid, dk5ras]

> I'm pretty sure if you look hard enough you'll find some blocks in GR that
> implement or could implement some patented telecom technique ...

Uh, oh, don't open Pandoras box :-)

Ralph.



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

Re: [Discuss-gnuradio] GNU Radio LiveDVD 2013-1110 (based on 3.7.2)

[Marcus Müller]

I don't support the "let's keep our eyes closed" approach.
Everyone that generates a product or service he intends to sell is 
(should be) aware of the fact that he has to care about foreign rights 
(patents, especially) can be involved.
The inclusion of such software on a scientific/free live dvd is quite 
unspectacular, I guess. Unless someone starts selling products bundled 
with that DVD. But I think everyone involved with selling GR-related 
product has quite a nice idea of the intellectual property involved in 
designing signal processing hard- and software.


Greetings
Marcus
On 13.11.2013 09:07, Ralph A. Schmid, dk5ras wrote:

I'm pretty sure if you look hard enough you'll find some blocks in GR that
implement or could implement some patented telecom technique ...

Uh, oh, don't open Pandoras box :-)

Ralph.



___
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] [install-usrppythonPYTHON] Error 127

[Robert Light]

The reson for 3.4.2 is always the same for everyone - OpenBTS, and for that reason important for many people.

v3.4.2 is in the repository tagged as "maintenance".

An old *tar version of 3.4.2 is installing without this problem.

I have now found a way round this problem but it would be good to know whether I was dong something wrong or it is a bug.

It could be that it is just my ubuntu.  I upgraded to 12.04 recently and already had to recover the system 3 times in the last week.

KR, Robert

 

Gesendet: Dienstag, 12. November 2013 um 19:36 Uhr
Von: "Ben Hilburn" 
An: "Robert Light" 
Cc: "GNURadio Discussion List" 
Betreff: Re: [Discuss-gnuradio] [install-usrppythonPYTHON] Error 127


Hi Robert -
 

Is there a reason you are using such an old release of GNURadio? We are up to 3.7.2 now, and have a completely different build system that resolved many of the issues with the old autofoo-based system.

 

Cheers,

Ben


 
On Sun, Nov 10, 2013 at 11:32 AM, Robert Light  wrote:




Hi, Can anyone help me with this error ?

I  do:

git checkout v3.4.2git

./configure  --prefix=/home/robert/gr342 --disable-gr-qtgui --with-fusb-tech=libusb1 --enable-usrp --enable-gr-usrp --enable-gnuradio-core --disable-usrp2 --disable-volk

 

make  works just fine

when I run make install I get this:

 

test -z "/home/robert/gr342/lib/python2.7/site-packages/usrpm" || /bin/mkdir -p "/home/robert/gr342/lib/python2.7/site-packages/usrpm"
 /usr/bin/install -c -m 644 usrp_dbid.py '/home/robert/gr342/lib/python2.7/site-packages/usrpm'
/bin/bash: line 15: --destdir: command not found
make[7]: *** [install-usrppythonPYTHON] Error 127
make[6]: *** [install-am] Error 2
make[5]: *** [install] Error 2
make[4]: *** [install-recursive] Error 1
make[3]: *** [install-recursive] Error 1
make[2]: *** [install] Error 2
make[1]: *** [install-recursive] Error 1
make: *** [install] Error 2

 

when I run

/home/robert/gr342/lib/python2.7/site-packages/usrpm/

i see only one file "usrp_dbid.py"

 

Linux Astro 3.8.0-33-generic #48~precise1-Ubuntu SMP Thu Oct 24 16:28:06 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

 



___
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] FOSDEM '14 - Call for Participation

[Martin Braun (CEL)]

On Mon, Nov 11, 2013 at 06:32:28PM +0100, Martin Braun (CEL) wrote:
> Hi guys,
> 
> once again, I'd like to invite everyone to submit presentations!
> We are very open to anything you have, and the slots don't have fixed
> lengths, so be it short or long, tutorial or presentation, come and
> participate!

Since I've been getting lots of questions regarding this, here's the
FAQ:

* What do I have to submit?

For the CfP deadline (1.12.) we only need a short abstract, a title and
an approx. duration (usually 30 mins). Basically, we need to know who's
definitely coming and what they're talking about, so we can make a nice
schedule, perhaps group the presentations by subject etc.

This takes about 5 Minutes, as we don't need any slides etc. right now.
(But you have to sign up to Pentabarf).

* What kind of presentation are you expecting?

We're very open here. Most of the presentations will probably be along
the lines of "here's cool project X I've been working on", which is
great. We want to see lots of different cool projects X, Y and Z!

However, if you want do do a tutorial, a group experiment etc., why not?
Or a contest? Perhaps contact us outside of Pentabarf if it's too funky.

* Relevant dates?

CfP deadline is December 1st, Notification December 20th and the actual
track is February 2nd.

MB

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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


pgpo4lXY4cfcK.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Make test failed

[YiZiRui Zhou]

Hi Tom,

Thanks for your advice.

I tried to uninstall ORC and test again. Unfortunately, just like Damon,
more tests failed.
https://lists.gnu.org/archive/html/discuss-gnuradio/2013-08/msg00353.html

I installed GNU Radio on another computer which run 64-bit Linux several
month ago. This remind me that something strange may happen when a 32bit OS
run on a 64bit processor. So I installed the Ubuntu 64bit and build GNU
Radio with the build-gnuradio script.

It works! All tests passed this time! ! !

Thanks!

Zhou


On Tue, Nov 12, 2013 at 9:07 PM, Tom Rondeau  wrote:

> On Tue, Nov 12, 2013 at 3:20 AM, 周易子睿  wrote:
> > Dear all,
> >
> > I tried to install GNU Radio v3.7 git on my computer, but some of the
> build
> > tests failed.
> >
> > The OS is Ubuntu 13.10 32bit, with kernel version Linux
> 3.11.0-12-generic,
> > the cpu is Intel® Core™ i5-2400 CPU @ 3.10GHz × 4.
> >
> > I installed the dependencies and get the following result after cmake.
> >
> > -- ##
> > -- # Gnuradio enabled components
> > -- ##
> > --   * python-support
> > --   * testing-support
> > --   * volk
> > --   * doxygen
> > --   * gnuradio-runtime
> > --   * gr-blocks
> > --   * gnuradio-companion
> > --   * gr-fec
> > --   * gr-fft
> > --   * gr-filter
> > --   * gr-analog
> > --   * gr-digital
> > --   * gr-atsc
> > --   * gr-audio
> > --   * gr-channels
> > --   * gr-noaa
> > --   * gr-pager
> > --   * gr-qtgui
> > --   * gr-trellis
> > --   * gr-uhd
> > --   * gr-utils
> > --   * gr-video-sdl
> > --   * gr-vocoder
> > --   * gr-fcd
> > --   * gr-wavelet
> > --   * gr-wxgui
> > --
> > -- ##
> > -- # Gnuradio disabled components
> > -- ##
> > --   * sphinx
> > --   * gr-ctrlport
> > --   * gr-comedi
> > --
> > -- Using install prefix: /usr/local
> > -- Building for version: v3.7.2-3-g9fb34ce4 / 3.7.3git
> > -- Configuring done
> > -- Generating done
> > -- Build files have been written to: /home/grief/Works/gnuradio/build
> >
> >
> > So I ran make and make test and the following tests FAILED:
> >
> > 97% tests passed, 6 tests failed out of 179
> >
> > Total Test time (real) =  98.40 sec
> >
> > The following tests FAILED:
> >   1 - qa_volk_test_all (Failed)
> >  80 - qa_fir_filter (Failed)
> >  97 - qa_freq_xlating_fir_filter (Failed)
> > 126 - qa_constellation_receiver (Failed)
> > 131 - qa_constellation (Failed)
> > 174 - qa_codec2_vocoder (Failed)
> > Errors while running CTest
> > make: *** [test] Error 8
> >
> > Then I ran ctest --output-on-failure -O ctest_log to get the log file.
> > The log file is attached to the mail.
> >
> > I am wondering how to fix the problem?
> > Thanks all !
>
>
> This looks like VOLK issue. Try removing ORC and recompiling since
> it's failing in VOLK on an ORC test.
>
> Also, why are you running a 32-bit OS on that processor? Seems a huge
> waste.
>
> Tom
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Announce OOT module for IEEE-802.15.4g MR-FSK

[Martin Braun (CEL)]

On Mon, Nov 11, 2013 at 03:17:14PM -0800, Wayne Roberts wrote:
> I have reached release functionality of out-of-tree module I use to help in 
> PHY
> conformance/interoperability to the MR-FSK standard in IEEE-802.15.4g.
> 
> [...]
> 
> For more info, see the wiki for it
> https://github.com/dudmuck/gr-ieee802154g

Hi Wayne,

and thanks a lot for publishing this!
Perhaps you can submit a recipe for PyBombs?

I had a very quick look at it (I don't really have anything to test it
with). One of the QA codes (qa_mrfsk_pkt_sink) doesn't work properly, it
uses the installed version to test.

Some more suggestions:
- Can you add a full UHD-to-bits GRC flow graph in apps/ ? That would
  help people see how it all works together.
- Perhaps you can add an IQ capture to test the code without having a
  transmitter nearby? I'm not sure of the overall bandwidth occupied,
  but if it's not too big, that might be useful.

Cheers,
Martin

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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


pgpMpwx8A3Py2.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Give sample rate to throttle block dynamically

[Jenny Galasso]

Hi,
I am parsing the sample rate from a file name and would like to dynamically 
pass that to a downstream block (for instance the throttle block).  I tried 
using a function proble to get the sample rate value and having the throttle 
get the sample rate from it.  It seems like the throttle is only getting the 
initial value from the function probe though and not updating.  Please let me 
know if I'm on the right track, or if there is a better way to pass the sample 
rate to other blocks.
Thanks!___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception

[Nowlan, Sean]

>
>From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
>[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On 
>Behalf Of Nowlan, Sean
>Sent: Monday, November 11, 2013 4:10 PM
>To: discuss-gnuradio@gnu.org
>Subject: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
>
>I'm using ControlPort to monitor transmissions through a USRP. I have a 
>flowgraph responsible for generating burst traffic and streaming to a 
>uhd_sink. Then I have a uhd_source tuned to the same frequency as the 
>uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I 
>have ControlPort support compiled-in and enabled from a config file. I'm able 
>to connect to a remotely running flowgraph using gr-ctrlport-monitor and plot 
>the PSD of the "samples" vector pulled from the probe2 block every 100 
>milliseconds. The problem is that after (what seems to be) a nondeterministic 
>time, the ICE port stops responding and gr-ctrlport-monitor reports an error:
>
>ctrlport-monitor: radio.get threw exception (exception 
>::Ice::ConnectTimeoutException
>{
>}).
>
>When I close and restart, gr-ctrlport-monitor times out and segfaults:
>
>2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error: 
>Traceback (most recent call last):
>  File "/usr/lib/pymodules/python2.7/Ice.py", line 984, in main
>status = self.doMain(args, initData)
>  File "/usr/lib/pymodules/python2.7/Ice.py", line 1031, in doMain
>return self.run(args)
>  File 
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py", 
> line 97, in run
>radio = self.getRadio(host, port)
>  File 
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py", 
> line 36, in getRadio
>radio = GNURadio.ControlPortPrx.checkedCast(base)
>  File "/usr/local/lib/python2.7/dist-packages/gnuradio_ice.py", line 1257, in 
> checkedCast
>return _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy, 
> '::GNURadio::ControlPort', facetOrCtx, _ctx)
>ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
>{
>}
>
>Segmentation fault (core dumped)
>
>So there are two issues to note here:
>-Something in the ICE instance is breaking on the GNU Radio flowgraph 
> side. The port is still open; it just times out. Trying to instantiate 
> gr-ctrlport-monitor to an incorrect port just says "connection refused," as 
> expected.
>-gr-ctrlport-monitor is not robust to connection-related errors like 
> timeouts or refused connections.
>
>Is there any advice of what I can turn on or enable in GNU Radio or my 
>flowgraph to debug the first problem? I can live with the second problem as 
>long as I can make sure ICE doesn't break on me.
>
>Thanks,
>Sean

Sorry for getting antsy about this, but I'm really not sure how to go about 
debugging ICE server stuff. It seems like it's buried pretty deeply in 
gnuradio-runtime. Where's the best place to start looking to find out why the 
ICE server stops responding?

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

Re: [Discuss-gnuradio] GnuradioConfig.cmake not working properly ?

[Tom Rondeau]

On Tue, Nov 12, 2013 at 1:28 PM, Martin Braun (CEL)
 wrote:
> On Tue, Nov 12, 2013 at 06:54:43PM +0100, Sylvain Munaut wrote:
>> The attached patch fixes that by re-declaring the variable in the parent 
>> scope.
>>
>> This fixes the gr-osmosdr build for me.
>> @Martin : could you give it a shot to check it fixes it for you too ?
>
> Yep, this fixes gr-osmosdr on my side.
>
> MB


Patches applied. I also updated the OOT tutorial to use REQUIRED and
gr-modtool now defaults to using the GnuradioConfig style checks with
REQUIRED as well.

Thanks!

Tom

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

Re: [Discuss-gnuradio] gr-ctrlport-monitor timeout exception

[Tim Newman]

I've seen ICE do this before, but usually its because my flowgraph dies,
via segfault or something.  When the flowgraph dies, the ice endpoints
aren't available anymore so the controlport monitor timesout when
attempting to query them.  Are you sure your flowgraph isn't crapping out
for some reason or another?

Tim


On Wed, Nov 13, 2013 at 11:10 AM, Nowlan, Sean
wrote:

>  >
>
> *>From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf
> Of *Nowlan, Sean
> *>Sent:* Monday, November 11, 2013 4:10 PM
> *>To:* discuss-gnuradio@gnu.org
> *>Subject:* [Discuss-gnuradio] gr-ctrlport-monitor timeout exception
>
> >
>
> >I’m using ControlPort to monitor transmissions through a USRP. I have a
> flowgraph responsible for generating burst traffic and streaming to a
> uhd_sink. Then I have a uhd_source tuned to the same frequency as the
> uhd_sink, and I connect it to a ctrlport_probe2_c block with length=128. I
> have ControlPort support compiled-in and enabled from a config file. I’m
> able to connect to a remotely running flowgraph using gr-ctrlport-monitor
> and plot the PSD of the “samples” vector pulled from the probe2 block every
> 100 milliseconds. The problem is that after (what seems to be) a
> nondeterministic time, the ICE port stops responding and
> gr-ctrlport-monitor reports an error:
>
> >
>
> >ctrlport-monitor: radio.get threw exception (exception
> ::Ice::ConnectTimeoutException
>
> >{
>
> >}).
>
> >
>
> >When I close and restart, gr-ctrlport-monitor times out and segfaults:
>
> >
>
> >2013-11-11 16:02:47.329422 /usr/local/bin/gr-ctrlport-monitor: error:
> Traceback (most recent call last):
>
> >  File "/usr/lib/pymodules/python2.7/Ice.py", line 984, in main
>
> >status = self.doMain(args, initData)
>
> >  File "/usr/lib/pymodules/python2.7/Ice.py", line 1031, in doMain
>
> >return self.run(args)
>
> >  File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py",
> line 97, in run
>
> >radio = self.getRadio(host, port)
>
> >  File
> "/usr/local/lib/python2.7/dist-packages/gnuradio/ctrlport/IceRadioClient.py",
> line 36, in getRadio
>
> >radio = GNURadio.ControlPortPrx.checkedCast(base)
>
> >  File "/usr/local/lib/python2.7/dist-packages/gnuradio_ice.py", line
> 1257, in checkedCast
>
> >return
> _M_gnuradio.ctrlport.GNURadio.ControlPortPrx.ice_checkedCast(proxy,
> '::GNURadio::ControlPort', facetOrCtx, _ctx)
>
> >ConnectTimeoutException: exception ::Ice::ConnectTimeoutException
>
> >{
>
> >}
>
> >
>
> >Segmentation fault (core dumped)
>
> >
>
> >So there are two issues to note here:
>
> >-Something in the ICE instance is breaking on the GNU Radio
> flowgraph side. The port is still open; it just times out. Trying to
> instantiate gr-ctrlport-monitor to an incorrect port just says “connection
> refused,” as expected.
>
> >-gr-ctrlport-monitor is not robust to connection-related errors
> like timeouts or refused connections.
>
> >
>
> >Is there any advice of what I can turn on or enable in GNU Radio or my
> flowgraph to debug the first problem? I can live with the second problem as
> long as I can make sure ICE doesn’t break on me.
>
> >
>
> >Thanks,
>
> >Sean
>
>
>
> Sorry for getting antsy about this, but I’m really not sure how to go
> about debugging ICE server stuff. It seems like it’s buried pretty deeply
> in gnuradio-runtime. Where’s the best place to start looking to find out
> why the ICE server stops responding?
>
>
>
> Sean
>
> ___
> 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] Give sample rate to throttle block dynamically

[Martin Braun (CEL)]

On Wed, Nov 13, 2013 at 07:42:35AM -0800, Jenny Galasso wrote:
> I am parsing the sample rate from a file name and would like to dynamically
> pass that to a downstream block (for instance the throttle block).  I tried
> using a function proble to get the sample rate value and having the throttle
> get the sample rate from it.  It seems like the throttle is only getting the
> initial value from the function probe though and not updating.  Please let me
> know if I'm on the right track, or if there is a better way to pass the sample
> rate to other blocks.

Hi Jenny,

the throttle block is really only used to run offline flowgraphs and make sure
they don't swamp the CPU. Do you have any other clocks in your
flowgraph, or is this the only one?

If you're reading the sample rate from a file name, my suggestion is to
figure that out before you start the FG, and set it while initializing.

If you want to change sampling rates dynamically, this calls for stream
tags. However, there's no block in stock GNU Radio that reads sampling
rates from stream tags.

MB

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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


pgpA3N8gGXaMj.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Announce OOT module for IEEE-802.15.4g MR-FSK

[Wayne Roberts]

The GRC flow graphs are in the examples subdirectory.
There is a local_loopback example, which tests all the blocks without any
hardware.
And there is one for testing UHD sink as transmitter, and another for UHD
source as packet receiver.
I use USRP-B100 talking to CC1200 radio chip, and the mrfsk_TX.grc
generates identical packets.

qa_mrfsk_pkt_sink.py currently doesnt do anything because the individual
framer sinks are tested by themselves.
qa_mrfsk_pkt_sink.py would only need to test the code in mrfsk_pkt_sink.py,
which is only connecting the correlate_access_code to the framer sinks.

I will later study pyBombs.

btw, this protocol is used at www.wi-sun.org

On Wed, Nov 13, 2013 at 6:26 AM, Martin Braun (CEL) wrote:

> On Mon, Nov 11, 2013 at 03:17:14PM -0800, Wayne Roberts wrote:
> > I have reached release functionality of out-of-tree module I use to help
> in PHY
> > conformance/interoperability to the MR-FSK standard in IEEE-802.15.4g.
> >
> > [...]
> >
> > For more info, see the wiki for it
> > https://github.com/dudmuck/gr-ieee802154g
>
> Hi Wayne,
>
> and thanks a lot for publishing this!
> Perhaps you can submit a recipe for PyBombs?
>
> I had a very quick look at it (I don't really have anything to test it
> with). One of the QA codes (qa_mrfsk_pkt_sink) doesn't work properly, it
> uses the installed version to test.
>
> Some more suggestions:
> - Can you add a full UHD-to-bits GRC flow graph in apps/ ? That would
>   help people see how it all works together.
> - Perhaps you can add an IQ capture to test the code without having a
>   transmitter nearby? I'm not sure of the overall bandwidth occupied,
>   but if it's not too big, that might be useful.
>
> Cheers,
> Martin
>
> --
> Karlsruhe Institute of Technology (KIT)
> Communications Engineering Lab (CEL)
>
> Dipl.-Ing. Martin Braun
> Research Associate
>
> Kaiserstraße 12
> Building 05.01
> 76131 Karlsruhe
>
> Phone: +49 721 608-43790
> Fax: +49 721 608-46071
> www.cel.kit.edu
>
> KIT -- University of the State of Baden-Württemberg and
> National Laboratory of the Helmholtz Association
>
> ___
> 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] Give sample rate to throttle block dynamically

[Martin Braun (CEL)]

Hi Jenny,

please stick to the mailing list.

On Wed, Nov 13, 2013 at 12:07:19PM -0800, Jenny Galasso wrote:
> Thanks for your response, Martin- It's very helpful.  I still have some
> confusion about the function probe though.  Briefly, how do I query it's value
> from another block? 

I'm not sure what you mean. You can write the variable name from the
function probe into any field that has a callback.

MB

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

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

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


pgpR2pDjPbnNo.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] how to set global system architecture in pybombs ?

[M Dammer]

I am working on an SDR live DVD with Gnuradio on it. The DVD is based on
XUbuntu 12.04 32bit. As the disk will hopefully being used on different
machines (Intel and AMD) processors I am concerned that certain features
of the (AMD based) build machine like 3Dnow! make the software
unsuitable for Intel chipsets. So how can I configure Pybombs to use
plain i686 architecture as the default for compiling, or is there
nothing to worry about ?
Mark



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

[Discuss-gnuradio] Accessing the uhd_usrp object

[M. Ranganathan]

Hello all!

I want to write a block that can directly access the uhd_usrp_source. This
block is a mac block hence it is up on the food chain and far away from
uhd_usrp_source in terms of its processing function. What is a good way of
passing it a handle to the usrp_source ?

I can think of some hacks (such as a static global pointer where the
uhd_usrp_source C++ object registers itself) but it seems ugly to me to
take that route. Is there a better way to access global objects from within
a block implementation.

Thanks in advance for any help.

Regards,

Ranga

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

Re: [Discuss-gnuradio] how to set global system architecture in pybombs ?

[West, Nathan]

On Wed, Nov 13, 2013 at 2:57 PM, M Dammer  wrote:
> I am working on an SDR live DVD with Gnuradio on it. The DVD is based on
> XUbuntu 12.04 32bit. As the disk will hopefully being used on different
> machines (Intel and AMD) processors I am concerned that certain features
> of the (AMD based) build machine like 3Dnow! make the software
> unsuitable for Intel chipsets. So how can I configure Pybombs to use
> plain i686 architecture as the default for compiling, or is there
> nothing to worry about ?
> Mark
>

You can change the templates to pass gcc whatever CPU type you want to
build for. If you're asking about how to massage GCC to do this,
that's documented over at
http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html.
Something like -mtune=generic should be pretty safe, unless you can
assume more.

Change whatever templates you're recipes will use to always pass that
option to GCC.

-Nathan

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

[Discuss-gnuradio] pfb_arb_resampler_ccf

[????]

hello all??


who can tell me??what is "pfb_arb_resampler_ccf"?and what does it do?




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