Re: [Discuss-gnuradio] About how to write c++ based signal processing block

2012-02-17 Thread Martin Braun 
On Fri, Feb 17, 2012 at 02:01:36AM -0500, Adeel Anwar wrote:
> Hi Martin,
> 
> i have used gr_modtool.py to create custom blocks and all these new blocks are
> working fine. Thanks to u for this good utility.
> 
> I have python/gnuradio installed on two machines. Same version of 
> gr_modtool.py
> (downloaded yesterday) works fine on one but on second machine, it creates new
> module but when we try to add some block,  it exits with following error.
> [...]
> 
> Traceback (most recent call last):
>   File "/usr/local/bin/gr_modtool.py", line 2315, in 
>     main()
>   File "/usr/local/bin/gr_modtool.py", line 2312, in main
>     modtool.run()
>   File "/usr/local/bin/gr_modtool.py", line 748, in run
>     self._run_lib()
>   File "/usr/local/bin/gr_modtool.py", line 787, in _run_lib
>     ed.append_value('add_library', fname_cc)
>   File "/usr/local/bin/gr_modtool.py", line 503, in append_value
>     count=1, flags=re.MULTILINE)
> TypeError: sub() got an unexpected keyword argument 'flags'

Hi Adeel,

Ben Reynwar pointed this out to me yesterday: gr_modtool.py needs Python
2.7. I argued that anyone using the CMake version of the blocks would
have access to 2.7... guess I was wrong.
I'm afraid I can't post a fix to this right now (would mean some
rewriting), but I'll add a version check so the error message becomes
more useful.

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



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

Re: [Discuss-gnuradio] Meet SDR guys IRL: Karlsruhe WSR

2012-02-17 Thread Andre Puschmann 
On 02/15/2012 12:25 PM, Martin Braun wrote:
> Hi everyone,
> 
> some updates: I have booked a table at "Vogelbräu" for 19:30 on Tuesday
> 6 March.
> The adress is "Kapellenstrasse 50" (or www.vogelbraeu.de for an
> IP-compatible adress :).
> It's a pretty decent Microbrewery, the food's good, so if you've been
> travelling, here's the place to get that stomach filled.

Thanks. Added to my calendar.

-Andre


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

Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch

2012-02-17 Thread Andre Puschmann 
On 02/16/2012 07:16 PM, Philip Balister wrote:
>> /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
>> /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
>> make[2]: *** 
>> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
>>  Error 1
>> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 2
>> make: *** [all] Error 2
>>
>> Any hints/ideas? Thanks!
> 
> I feel like the flags from the toolchain file are not getting through to
> gcc, try passing the compiler flags via the command line.

For some reason it's not working for me either. I'm always passing the
parameters via command line. Not sure whether it's a CMake issue. Is it
working for everybody else?

-Andre


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

Re: [Discuss-gnuradio] FSK using VCO

2012-02-17 Thread Adeel Anwar 
One thing i forgot , there should be upsample(pulse shaping ) OR repeat by
N block between "chunk2symbol" and "fm modulator"

On Thu, Feb 16, 2012 at 11:09 PM, Adeel Anwar  wrote:

> Anju,
>
> Try connecting these
>
> data_src(0,1)==>chunk to symbol(-1,1)==>fm
> modulator(sensitivity=(2*pi*(freq_sep/2.0))/samp_rate))
>
> where freq_sep = symb_rate (for non-coherent detection)
>
> On receiver side u can use quadrature demoulator
>
>
> -Adeel
>
> On Fri, Feb 17, 2012 at 12:42 AM, anju babu  wrote:
>
>>
>> HI all,
>>
>>   I'm developing an underwater modem which uses acoustic signal
>> for transmission and reception .for that i need to have a FSK
>> modulator.since CPFSk is not practically possible in underwater ,i decided
>> to use VCO.I have to modulate data from a file sourc(output type byte)
>> using 10khz carrier.i don't know how to do this.when i connected a file
>> source -uchar to float- vco -scopesink and observed output i couldn't see
>> what i was expecting.can't i input the vco with a file source?please help
>> me.
>>
>> thanks in advance
>> ANJU
>> --
>> **
>>
>> ___
>> 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] How to get time from GPSDO

2012-02-17 Thread Wu Ting 
Hi all,

 

I know this is a very basic problem. But I have looked for a lot of
information and discussions and still cannot figure out how to do.

 

In my current GNURadio application, I want to get the time produced by
GPSDO. I found this page

 

 

http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-yo
ur-application

 

and thought usrp->get_mboard_sensor is the function that I need. But I don't
know how to use this function in GNURadio. It seems that the code is written
in C++. So can I use it directly in GNURadio?

 

Thanks,

 

Wu

 

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

Re: [Discuss-gnuradio] E100 compile error: trondeau safe_align branch

2012-02-17 Thread Philip Balister 
On 02/17/2012 02:25 AM, Andre Puschmann wrote:
> On 02/16/2012 07:16 PM, Philip Balister wrote:
>>> /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
>>> /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
>>> make[2]: *** 
>>> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
>>>  Error 1
>>> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all] Error 
>>> 2
>>> make: *** [all] Error 2
>>>
>>> Any hints/ideas? Thanks!
>>
>> I feel like the flags from the toolchain file are not getting through to
>> gcc, try passing the compiler flags via the command line.
> 
> For some reason it's not working for me either. I'm always passing the
> parameters via command line. Not sure whether it's a CMake issue. Is it
> working for everybody else?

I looked at this the other day and it made me very angry :)

It is on my list of things to figure out.

Philip

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

Re: [Discuss-gnuradio] Volk branch on github

2012-02-17 Thread Philip Balister 
On 02/16/2012 11:39 AM, Josh Blum wrote:
> 
> 
> On 02/16/2012 11:32 AM, Josh Blum wrote:
>>
>>
>> On 02/16/2012 11:24 AM, Tom Rondeau wrote:
>>> On Thu, Feb 16, 2012 at 2:08 PM, Josh Blum  wrote:
>>>

> Also, you never want to work on the smallest amount of memory possible.
> This is covered in my discussion on my blog. Making arbitrarily small
 calls
> to work functions causes much more overhead than just running the
 unaligned
> version of a Volk call. I found this out pretty quickly when I started
> looking into things. Better to process a large chunk to get back into
> alignment than try to handle calls to small amounts of data.
>

 Perhaps this is because you have a processor that doesn't penalize you
 for unaligned loads/stores.

 -Josh

>>>
>>> I tested this on a handful of different processors: Core2Due, QuadCore, i7
>>> (first get), i7 (second gen) and they all told me the same thing. You are
>>
>> For most if not all recent x86 processors there is no unaligned penalty.
>> You should be able to always call the unaligned volk routine and see no
>> difference in performance. I'm wondering about neon for example, which
>> has a penalty. And I suppose to a lesser extent, older x86 processors. I
>> dont have numbers now, but I think the volk profiler can confirm this
>> about said processors.
> 
> 
> The answer for neon is probably a case of the "don't do that". In other
> words, keep your blocks fed with aligned multiples, regardless of how
> the scheduler handles things.

The answer is more like:

Aligned is better

and

if you are forced to chose between aligned loads versus stores, align stores

but

start by using NEON and do not worry about alignment since the penalty
for unaligned access is not dreadful.

Philip

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

[Discuss-gnuradio] Bug in GRC, bugs in grc-examples and unit tests [Was: GRC: Just compile XML, no GUI]

2012-02-17 Thread Martin Braun 
On Thu, Feb 16, 2012 at 02:28:21PM -0500, Paul Miller wrote:
> On Thu, Feb 16, 2012 at 10:19:31AM -0800, Josh Blum wrote:
> > > I was wondering if it's a big deal to give gnuradio-companion a switch
> > > to just compile a .grc file without firing up the GUI.
> 
> > Give this a shot: https://github.com/jettero/grcc/blob/grcc/grcc
> > -Josh
> 
> This is exactly why I wrote grcc.  It should probably be a switch
> in the gnuradio-companion script, but grcc does the job for now.
> I'm open to forks and patches, I really just cobbled together
> something that works for me, suggestions welcome.

Yep, that's exactly what I wanted. I think this should be part of grc--I
posted a patch here: https://github.com/mbant/gnuradio/tree/grcunittest

This contains two commits:
76e918438e5 simply adds grcc to gnuradio-companion (plus one more switch
to set the dir). This is pretty simple, and I'd suggest it for 'next'.

724a3ff8798d adds a unit test to gr-howto-write-a-block for the grc
files. This one's very hackish, it shouldn't be merged into anything,
but I'd like to suggest something like this for GR. The current next
branch has some broken grc examples, and with something like this it
would be super easy to track the working state of these grc files.

The most relevant change is in
https://github.com/mbant/gnuradio/blob/grcunittest/gr-howto-write-a-block/apps/CMakeLists.txt
(you can see my solution is ugly, non-portable and so on but does the
trick).

It also has a workaround for a bug
(http://gnuradio.org/redmine/issues/485) in GRC. Probably should have
been two commits.

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



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

Re: [Discuss-gnuradio] Sampling Rate

2012-02-17 Thread Ed Criscuolo 

On 2/17/12 2:07 AM, guelord ingala wrote:

Hi,
I'm getting confused with the concept of "Sampling rate" to set the
UHD:USRP Source and other blocks from the gnuradio-companion. If I'm
still right, the sampling rate must be at least the double of the
operating frequency. But I can see some working applications when this
Nyquist theory is not respected. How come?



GnuRadio uses complex (I & Q) samples.  This results in twice the data
per sample, satisfying the Nyquest criterion.

@(^.^)@  Ed


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

Re: [Discuss-gnuradio] How to get time from GPSDO

2012-02-17 Thread Nowlan, Sean 
Use the "get_time_now" method, which is callable from C++ or from Python 
(through Swig).

http://gnuradio.org/doc/doxygen/classuhd__usrp__sink.html#a74c75fc2a209184856db674489de748c

Sean



From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Wu Ting
Sent: Friday, February 17, 2012 7:45 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] How to get time from GPSDO

Hi all,

I know this is a very basic problem. But I have looked for a lot of information 
and discussions and still cannot figure out how to do.

In my current GNURadio application, I want to get the time produced by GPSDO. I 
found this page

http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-your-application

and thought usrp->get_mboard_sensor is the function that I need. But I don't 
know how to use this function in GNURadio. It seems that the code is written in 
C++. So can I use it directly in GNURadio?

Thanks,

Wu

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

Re: [Discuss-gnuradio] Using volk in Mac: test report

2012-02-17 Thread Tom Rondeau 
Carles,

Thanks for the report! We'll look into those failures. Hopefully just some
minor misundertanding.

As for the generic sometimes being the best arch, I'm not sure I can help
too much on it. I can certainly speculate. Having seen this in my own
machines and looked at some of the kernels where generic wins out (which
have some overlap with yours), I think it's something about the operation
being performed. First, we might be able to do something a bit smarter in
the Volk kernel. But more likely, it's simply because the operation being
performed is so trivial that it doesn't really matter.

Another reason could be that the tests aren't long enough to avoid OS-level
variances while completing a test. The tests use the clock() function for
calculating the time difference, which is only the approximate time of the
process. It might mean that we need to run the tests for a bit longer to
see if that makes any difference. I have noticed that some of the tests
where generic wins, it only wins by a very, very small amount of time.

Tom

On Tue, Jan 17, 2012 at 3:26 PM, Carles Fernandez <
carles.fernan...@gmail.com> wrote:

> Hi all,
>
> I would like to use the volk library in a C++ program that uses
> gnuradio-core and currently builds under Linux and MacOS X. In MacOS
> 1.6.8 (Snow Leopard, updated), I used macports for installing
> gnuradio-core (which is in version 3.3, enough for my app). Since, in
> my understanding (please correct me if I'm wrong), volk is a library
> that can live independently from the gnuradio version, I did the
> following:
>
> $  git clone git://gnuradio.org/gnuradio
> $  cd gnuradio/volk
> $  cmake .
> $  make
> ...
> [100%] Built target volk_profile
> $  sudo make install
>
> Then I ran the tests:
>
> $ lib/test_all
>
> All test but one passed, and I see that in some functions the generic
> architecture is the best one, which is beyond my understanding. The
> test that failed is:
>
> ...
> volk_32fc_32f_multiply_32fc_a: fail on arch sse
> Best arch: sse
> /Users/carlesfernandez/Documents/workspace/gnuradio/volk/lib/testqa.cc:25:
> error in "volk_32fc_32f_multiply_32fc_a_test": check
> run_volk_tests(volk_32fc_32f_multiply_32fc_a_get_func_desc(), (void
> (*)())volk_32fc_32f_multiply_32fc_a_manual,
> std::string("volk_32fc_32f_multiply_32fc_a"), 1e-4, 0, 20460, 1, 0) ==
> 0 failed [true != 0]
> ...
>
>
> I'm quite happy because I see dramatic improvements in some functions
> of my interest (basically I want to implement correlators and mixers,
> so I'm sensible precisely to this function, bad luck), but this
> "generic" superiority in some cases intrigues me. I would appreciate
> if anyone can shed some light on the internals of volk, or if I have
> to configure or install something else. Anyway, thanks to the
> developers for releasing such interesting stuff :-)
>
>
>
>
> This is the complete output, for the records:
>
>
> volk carlesfernandez$ cmake .
> -- The C compiler identification is GNU
> -- The CXX compiler identification is GNU
> -- Checking whether C compiler has -isysroot
> -- Checking whether C compiler has -isysroot - yes
> -- Checking whether C compiler supports OSX deployment target flag
> -- Checking whether C compiler supports OSX deployment target flag - yes
> -- Check for working C compiler: /usr/local/bin/gcc
> -- Check for working C compiler: /usr/local/bin/gcc -- works
> -- Detecting C compiler ABI info
> -- Detecting C compiler ABI info - done
> -- Checking whether CXX compiler has -isysroot
> -- Checking whether CXX compiler has -isysroot - yes
> -- Checking whether CXX compiler supports OSX deployment target flag
> -- Checking whether CXX compiler supports OSX deployment target flag - yes
> -- Check for working CXX compiler: /usr/bin/c++
> -- Check for working CXX compiler: /usr/bin/c++ -- works
> -- Detecting CXX compiler ABI info
> -- Detecting CXX compiler ABI info - done
> -- Found PythonInterp: /opt/local/bin/python (found version "2.6.7")
> -- Boost version: 1.48.0
> -- Found the following Boost libraries:
> --   unit_test_framework
> -- checking for module 'orc-0.4'
> --   package 'orc-0.4' not found
> -- orc files (missing:  ORC_LIBRARY ORC_INCLUDE_DIR ORCC_EXECUTABLE)
> -- Check size of void*
> -- Check size of void* - done
> -- Performing Test have_maltivec
> -- Performing Test have_maltivec - Failed
> -- Performing Test have_mfpu=neon
> -- Performing Test have_mfpu=neon - Failed
> -- Performing Test have_mfloat-abi=softfp
> -- Performing Test have_mfloat-abi=softfp - Failed
> -- Performing Test have_funsafe-math-optimizations
> -- Performing Test have_funsafe-math-optimizations - Success
> -- 32 overruled
> -- Performing Test have_m64
> -- Performing Test have_m64 - Success
> -- Performing Test have_m3dnow
> -- Performing Test have_m3dnow - Success
> -- Performing Test have_msse4.2
> -- Performing Test have_msse4.2 - Success
> -- Performing Test have_mpopcnt
> -- Performing Test have_mpopcnt - Failed
> -- Performing Test have_mmmx
> -- Performin

Re: [Discuss-gnuradio] Receiving signal from a signal generator

2012-02-17 Thread Tom Rondeau 
On Fri, Feb 17, 2012 at 2:52 AM, guelord ingala wrote:

> Hi,
> I've got 2 units of USRP1 and DBSRX dboards. The two USRP are synchronized
> for master and slave. the uhd_fft.py is responding correctly.
> Now I want to use a signal generator to provide 900 MHz. signal level is
> -20 dBm. From the gnuradio-companion, I created a flow graph using UHD-USRP
> Source connected to WX-GUI-FFT Sink. The setup are as follow:
>  For USRP source:
> ID: uhd_usrp_source_0
> Device Addr: fpga=usrp1_fpga_4rx.rbf
> Sync: Don'y sink
> Clock rate: default
> Num Mboards:1
> Mbo Clock source: default
> Mbo Time source:default
> Mbo Subdevice Spec:
> Num Channel: 1
> Sample rate (sps): 32K
> Cho Center freq: 900M
> Cho Gain:30 dB
> Cho Antenna: RXA
> Cho Bandwidth:10M
>
> For FFT Sink:
>Sample rate:32k
>Baseband freq:900M
>
> With this setup, only noise is plotted in the FFT. I don't see the signal
> at 900MHz. And even if I remove the daughterboard from the usrp, the result
> is unchanged: Noise only.
> Can you please tell me what is wrong with the setup, and what to do if I
> want to use the side B. Also which USRP must I use: the master, the slave
> or both. Please help.
>

I think your sample rate is way too low for the USRP. When you run the
program, you should see a warning being printed that you tried to set the
sample rate to 32 kHz but the actual sample rate was something else. This
could cause some confusion in your setup.

Also, make sure that you are going into the right antenna port on the USRP.

Finally, a -20 dBm signal and 30 dB of gain in the USRP is a really loud
signal. You might be swamping your front end. I'd put the input signal down
to -50 dBm to start with and lower the gain. Up the gain slowly as
necessary.

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

Re: [Discuss-gnuradio] ATSC decoding - Now Working!

2012-02-17 Thread Tom Rondeau 
On Thu, Feb 16, 2012 at 4:43 PM, Nick Foster  wrote:

> No, I don't know where that is... I can always take more data though. I'll
> post it on a Dropbox tonight or this weekend. I'm pretty sure the Gnuradio
> ATSC decoder is suffering from some massive bitrot though. If you do get it
> working for you, *please* post your changes for inclusion into Gnuradio!
>
> --n
>

To echo Nick, PLEASE submit your fixes if you get this working again. It's
been on my todo list for a long time, but I just never get a chance to work
on it. Would be great to get it back into shape again.

Also, we might be able to host some data files on gnuradio.org. I need to
look into how much space we have or can set aside for this, but it would be
nice to have stuff like this easily accessible.

Tom




> On Thu, Feb 16, 2012 at 1:31 PM, shea_watson wrote:
>
>>
>> Nick,
>>
>> I apologize if this is bringing back old ghosts but I am doing research
>> with
>> ATSC signals and gnuradio and would like that sample ATSC capture that you
>> posted.  i cannot find where you posted it.  Do you happen to still have
>> it?
>>
>> Thanks,
>> SW
>>
>>
>> Nick Foster-4 wrote:
>> >
>> > Achilleas,
>> >
>> > I live all of a half mile away from the local 10MW broadcast tower, so I
>> > can almost hear ATSC in my fillings at night. I'll get an ATSC capture
>> > and post it online tonight.
>> >
>> > --n
>> >
>> > On Fri, 2010-10-29 at 10:02 -0400, Achilleas Anastasopoulos wrote:
>> >> Bryce and others,
>> >>
>> >> is there any way someone can post captured sample atsc files for
>> >> downloading and testing.
>> >>
>> >> I have some ideas for improving the atsc implementation but need to
>> test
>> >> some things before i propose something meaningful...
>> >>
>> >> Thanks
>> >> Achilleas
>> >>
>> >> ___
>> >> Discuss-gnuradio mailing list
>> >> Discuss-gnuradio@gnu.org
>> >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>> >
>> > ___
>> > Discuss-gnuradio mailing list
>> > Discuss-gnuradio@gnu.org
>> > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> >
>> >
>>
>> --
>> View this message in context:
>> http://old.nabble.com/Re%3A-Re%3A-ATSC-decoding---Now-Working%21-tp30073408p1099.html
>> Sent from the GnuRadio mailing list archive at Nabble.com.
>>
>>
>> ___
>> Discuss-gnuradio mailing list
>> Discuss-gnuradio@gnu.org
>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] E100/E110 Documentation

2012-02-17 Thread Matthias Schäfer 

Hi List,
is there any documentation about the e-series of the usrps (except the 
application notes and the datasheet) out there?


I'm especially searching for informations about how to install the 
images, how to start and -- at best -- a little example application.


Cheers,
Matthias

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

Re: [Discuss-gnuradio] Receiving signal from a signal generator

2012-02-17 Thread John Orlando 
On Fri, Feb 17, 2012 at 10:22 AM, Tom Rondeau  wrote:

> On Fri, Feb 17, 2012 at 2:52 AM, guelord ingala wrote:
>
>> Hi,
>> I've got 2 units of USRP1 and DBSRX dboards. The two USRP are
>> synchronized for master and slave. the uhd_fft.py is responding correctly.
>> Now I want to use a signal generator to provide 900 MHz. signal level is
>> -20 dBm. From the gnuradio-companion, I created a flow graph using UHD-USRP
>> Source connected to WX-GUI-FFT Sink. The setup are as follow:
>>  For USRP source:
>> ID: uhd_usrp_source_0
>> Device Addr: fpga=usrp1_fpga_4rx.rbf
>> Sync: Don'y sink
>> Clock rate: default
>> Num Mboards:1
>> Mbo Clock source: default
>> Mbo Time source:default
>> Mbo Subdevice Spec:
>> Num Channel: 1
>> Sample rate (sps): 32K
>> Cho Center freq: 900M
>> Cho Gain:30 dB
>> Cho Antenna: RXA
>> Cho Bandwidth:10M
>>
>> For FFT Sink:
>>Sample rate:32k
>>Baseband freq:900M
>>
>> With this setup, only noise is plotted in the FFT. I don't see the signal
>> at 900MHz. And even if I remove the daughterboard from the usrp, the result
>> is unchanged: Noise only.
>> Can you please tell me what is wrong with the setup, and what to do if I
>> want to use the side B. Also which USRP must I use: the master, the slave
>> or both. Please help.
>>
>
> I think your sample rate is way too low for the USRP. When you run the
> program, you should see a warning being printed that you tried to set the
> sample rate to 32 kHz but the actual sample rate was something else. This
> could cause some confusion in your setup.
>
> Also, make sure that you are going into the right antenna port on the USRP.
>
> Finally, a -20 dBm signal and 30 dB of gain in the USRP is a really loud
> signal. You might be swamping your front end. I'd put the input signal down
> to -50 dBm to start with and lower the gain. Up the gain slowly as
> necessary.
>

One other potential issue here: if you're tuning the LO to 900 MHz, and
injecting a tone at exactly 900 MHz from a signal generator, the signal
downconverted signal would end up sitting exactly at DC, and may be removed
by DC offset correction if it is enabled.  Once you've widened up your
sample rate a bit per Tom's suggestion (try something on the order of a
couple of MHz, or whatever decimation ratio would get you to something in
this range), try offsetting your input tone to 900.1 MHz and see if it
shows up.

John

-- 
John Orlando
CEO/System Architect
Epiq Solutions
http://www.epiq-solutions.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] ATSC decoding - Now Working!

2012-02-17 Thread Johnathan Corgan 
On Fri, Feb 17, 2012 at 08:31, Tom Rondeau  wrote:

> Also, we might be able to host some data files on gnuradio.org. I need to
> look into how much space we have or can set aside for this, but it would be
> nice to have stuff like this easily accessible.

We can easily conjure up an extra 10 or 20 GB for an example data file
volume.  That's something like a dollar a month.

Johnathan

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

Re: [Discuss-gnuradio] How to get time from GPSDO

2012-02-17 Thread Josh Blum 

> 
> and thought usrp->get_mboard_sensor is the function that I need. But I don't
> know how to use this function in GNURadio. It seems that the code is written
> in C++. So can I use it directly in GNURadio?
> 
>  

All the functions are brought into python via swig, so:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n279

you would do this python:
secs = the_usrp_block.get_mboard_sensor("gps_time").to_int()

-Josh

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

Re: [Discuss-gnuradio] How to get time from GPSDO

2012-02-17 Thread Nowlan, Sean 
Just to enhance my (and everyone's) knowledge, does that call give you 
information substantially different from get_time_now()? Other than you get a 
UHD Time Spec with seconds and fractional seconds?

Sean

-Original Message-
From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Josh Blum
Sent: Friday, February 17, 2012 12:55 PM
To: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to get time from GPSDO


> 
> and thought usrp->get_mboard_sensor is the function that I need. But I 
> don't know how to use this function in GNURadio. It seems that the 
> code is written in C++. So can I use it directly in GNURadio?
> 
>  

All the functions are brought into python via swig, so:
http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n279

you would do this python:
secs = the_usrp_block.get_mboard_sensor("gps_time").to_int()

-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] How to get time from GPSDO

2012-02-17 Thread Josh Blum 


On 02/17/2012 09:58 AM, Nowlan, Sean wrote:
> Just to enhance my (and everyone's) knowledge, does that call give
> you information substantially different from get_time_now()? Other
> than you get a UHD Time Spec with seconds and fractional seconds?
> 

Well, there is a time in the GPSDO in seconds that increments once a
PPS. Then there is a time in the FPGA that increments on each clock cycle.

Supposing you make a new uhd device object and a GPSDO is detected, the
time programmed into the FPGA registers is initialized to march in
lock-step with the GPSDO. This is done automatically, but its as simple
as ->set_time_next_pps(gpsdo_time + 1);

I wanted Wu to know that all the GPSDO sensors are available for access
in python. As in "gps_gpgsa", "gps_gprmc", and "gps_gpgga"

-Josh

> Sean
> 
> -Original Message- From:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
> On Behalf Of Josh Blum Sent: Friday, February 17, 2012 12:55 PM To:
> discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How to get
> time from GPSDO
> 
> 
>> 
>> and thought usrp->get_mboard_sensor is the function that I need.
>> But I don't know how to use this function in GNURadio. It seems
>> that the code is written in C++. So can I use it directly in
>> GNURadio?
>> 
>> 
> 
> All the functions are brought into python via swig, so: 
> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_sink.h#n279
>
>  you would do this python: secs =
> the_usrp_block.get_mboard_sensor("gps_time").to_int()
> 
> -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] Using volk in Mac: test report

2012-02-17 Thread Nick Foster 
On Fri, Feb 17, 2012 at 8:14 AM, Tom Rondeau  wrote:

> Carles,
>
> Thanks for the report! We'll look into those failures. Hopefully just some
> minor misundertanding.
>
> As for the generic sometimes being the best arch, I'm not sure I can help
> too much on it. I can certainly speculate. Having seen this in my own
> machines and looked at some of the kernels where generic wins out (which
> have some overlap with yours), I think it's something about the operation
> being performed. First, we might be able to do something a bit smarter in
> the Volk kernel. But more likely, it's simply because the operation being
> performed is so trivial that it doesn't really matter.
>
> Another reason could be that the tests aren't long enough to avoid
> OS-level variances while completing a test. The tests use the clock()
> function for calculating the time difference, which is only the approximate
> time of the process. It might mean that we need to run the tests for a bit
> longer to see if that makes any difference. I have noticed that some of the
> tests where generic wins, it only wins by a very, very small amount of time.
>

Please ignore the "best arch" reports during the QA code execution; it's
very often wrong. The "best arch" report is intended for the volk_profiler,
which reuses the same test code with much larger datasets for better
execution time resolution, as Tom suggested. The QA code is only intended
to show that Volk is working and to find functions which are executing
incorrectly. Use volk_profiler to benchmark Volk functions; it will create
a custom profile for your machine.

One caveat -- the dataset size on E100/NEON is enough that the profiler
might run for several hours, so either recompile with smaller datasets or
avoid the profiler... eventually I guess I'll make the benchmark program
benchmark itself to set appropriate dataset sizes.

--n


>
> Tom
>
> On Tue, Jan 17, 2012 at 3:26 PM, Carles Fernandez <
> carles.fernan...@gmail.com> wrote:
>
>> Hi all,
>>
>> I would like to use the volk library in a C++ program that uses
>> gnuradio-core and currently builds under Linux and MacOS X. In MacOS
>> 1.6.8 (Snow Leopard, updated), I used macports for installing
>> gnuradio-core (which is in version 3.3, enough for my app). Since, in
>> my understanding (please correct me if I'm wrong), volk is a library
>> that can live independently from the gnuradio version, I did the
>> following:
>>
>> $  git clone git://gnuradio.org/gnuradio
>> $  cd gnuradio/volk
>> $  cmake .
>> $  make
>> ...
>> [100%] Built target volk_profile
>> $  sudo make install
>>
>> Then I ran the tests:
>>
>> $ lib/test_all
>>
>> All test but one passed, and I see that in some functions the generic
>> architecture is the best one, which is beyond my understanding. The
>> test that failed is:
>>
>> ...
>> volk_32fc_32f_multiply_32fc_a: fail on arch sse
>> Best arch: sse
>> /Users/carlesfernandez/Documents/workspace/gnuradio/volk/lib/testqa.cc:25:
>> error in "volk_32fc_32f_multiply_32fc_a_test": check
>> run_volk_tests(volk_32fc_32f_multiply_32fc_a_get_func_desc(), (void
>> (*)())volk_32fc_32f_multiply_32fc_a_manual,
>> std::string("volk_32fc_32f_multiply_32fc_a"), 1e-4, 0, 20460, 1, 0) ==
>> 0 failed [true != 0]
>> ...
>>
>>
>> I'm quite happy because I see dramatic improvements in some functions
>> of my interest (basically I want to implement correlators and mixers,
>> so I'm sensible precisely to this function, bad luck), but this
>> "generic" superiority in some cases intrigues me. I would appreciate
>> if anyone can shed some light on the internals of volk, or if I have
>> to configure or install something else. Anyway, thanks to the
>> developers for releasing such interesting stuff :-)
>>
>>
>>
>>
>> This is the complete output, for the records:
>>
>>
>> volk carlesfernandez$ cmake .
>> -- The C compiler identification is GNU
>> -- The CXX compiler identification is GNU
>> -- Checking whether C compiler has -isysroot
>> -- Checking whether C compiler has -isysroot - yes
>> -- Checking whether C compiler supports OSX deployment target flag
>> -- Checking whether C compiler supports OSX deployment target flag - yes
>> -- Check for working C compiler: /usr/local/bin/gcc
>> -- Check for working C compiler: /usr/local/bin/gcc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Checking whether CXX compiler has -isysroot
>> -- Checking whether CXX compiler has -isysroot - yes
>> -- Checking whether CXX compiler supports OSX deployment target flag
>> -- Checking whether CXX compiler supports OSX deployment target flag - yes
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Found PythonInterp: /opt/local/bin/python (found version "2.6.7")
>> -- Boost version: 1.48.0
>> -- Found the following Boost libraries:
>> --   unit_test_framework
>> -- ch

[Discuss-gnuradio] Scheduler slides from gnuradio conference

2012-02-17 Thread Almohanad Fayez 
I was trying to download the slides about the scheduler from the gnuradio 
conference and for some reason they are not available with the other slides 
 are they posted or available somewhere else online?  thanks


Almohanad (Al) Fayez
alfa...@aol.com

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

Re: [Discuss-gnuradio] How to get time from GPSDO

2012-02-17 Thread Nowlan, Sean 
Thanks! That setup hadn't been 100% clear to me before. Makes sense now.

Sean

-Original Message-
From: Josh Blum [mailto:j...@joshknows.com] On Behalf Of Josh Blum
Sent: Friday, February 17, 2012 1:23 PM
To: Nowlan, Sean
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] How to get time from GPSDO



On 02/17/2012 09:58 AM, Nowlan, Sean wrote:
> Just to enhance my (and everyone's) knowledge, does that call give you 
> information substantially different from get_time_now()? Other than 
> you get a UHD Time Spec with seconds and fractional seconds?
> 

Well, there is a time in the GPSDO in seconds that increments once a PPS. Then 
there is a time in the FPGA that increments on each clock cycle.

Supposing you make a new uhd device object and a GPSDO is detected, the time 
programmed into the FPGA registers is initialized to march in lock-step with 
the GPSDO. This is done automatically, but its as simple as 
->set_time_next_pps(gpsdo_time + 1);

I wanted Wu to know that all the GPSDO sensors are available for access in 
python. As in "gps_gpgsa", "gps_gprmc", and "gps_gpgga"

-Josh

> Sean
> 
> -Original Message- From:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
> [mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org]
> On Behalf Of Josh Blum Sent: Friday, February 17, 2012 12:55 PM To:
> discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] How to get 
> time from GPSDO
> 
> 
>> 
>> and thought usrp->get_mboard_sensor is the function that I need.
>> But I don't know how to use this function in GNURadio. It seems that 
>> the code is written in C++. So can I use it directly in GNURadio?
>> 
>> 
> 
> All the functions are brought into python via swig, so: 
> http://gnuradio.org/cgit/gnuradio.git/tree/gr-uhd/include/gr_uhd_usrp_
> sink.h#n279
>
>  you would do this python: secs =
> the_usrp_block.get_mboard_sensor("gps_time").to_int()
> 
> -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] Using volk in Mac: test report

2012-02-17 Thread Carles Fernandez 
Thanks for the inputs!

We are interested in determining the best architecture at instantation
time. What would be the best strategy? We though about running the
same operations several times for each architecture, measure the
results and use the fastest one for the processing blocks. Would this
be the right approach?

Best regards,
Carles.

On Fri, Feb 17, 2012 at 7:33 PM, Nick Foster  wrote:
> On Fri, Feb 17, 2012 at 8:14 AM, Tom Rondeau  wrote:
>>
>> Carles,
>>
>> Thanks for the report! We'll look into those failures. Hopefully just some
>> minor misundertanding.
>>
>> As for the generic sometimes being the best arch, I'm not sure I can help
>> too much on it. I can certainly speculate. Having seen this in my own
>> machines and looked at some of the kernels where generic wins out (which
>> have some overlap with yours), I think it's something about the operation
>> being performed. First, we might be able to do something a bit smarter in
>> the Volk kernel. But more likely, it's simply because the operation being
>> performed is so trivial that it doesn't really matter.
>>
>> Another reason could be that the tests aren't long enough to avoid
>> OS-level variances while completing a test. The tests use the clock()
>> function for calculating the time difference, which is only the approximate
>> time of the process. It might mean that we need to run the tests for a bit
>> longer to see if that makes any difference. I have noticed that some of the
>> tests where generic wins, it only wins by a very, very small amount of time.
>
>
> Please ignore the "best arch" reports during the QA code execution; it's
> very often wrong. The "best arch" report is intended for the volk_profiler,
> which reuses the same test code with much larger datasets for better
> execution time resolution, as Tom suggested. The QA code is only intended to
> show that Volk is working and to find functions which are executing
> incorrectly. Use volk_profiler to benchmark Volk functions; it will create a
> custom profile for your machine.
>
> One caveat -- the dataset size on E100/NEON is enough that the profiler
> might run for several hours, so either recompile with smaller datasets or
> avoid the profiler... eventually I guess I'll make the benchmark program
> benchmark itself to set appropriate dataset sizes.
>
> --n
>
>>
>>
>> Tom
>>
>> On Tue, Jan 17, 2012 at 3:26 PM, Carles Fernandez
>>  wrote:
>>>
>>> Hi all,
>>>
>>> I would like to use the volk library in a C++ program that uses
>>> gnuradio-core and currently builds under Linux and MacOS X. In MacOS
>>> 1.6.8 (Snow Leopard, updated), I used macports for installing
>>> gnuradio-core (which is in version 3.3, enough for my app). Since, in
>>> my understanding (please correct me if I'm wrong), volk is a library
>>> that can live independently from the gnuradio version, I did the
>>> following:
>>>
>>> $  git clone git://gnuradio.org/gnuradio
>>> $  cd gnuradio/volk
>>> $  cmake .
>>> $  make
>>> ...
>>> [100%] Built target volk_profile
>>> $  sudo make install
>>>
>>> Then I ran the tests:
>>>
>>> $ lib/test_all
>>>
>>> All test but one passed, and I see that in some functions the generic
>>> architecture is the best one, which is beyond my understanding. The
>>> test that failed is:
>>>
>>> ...
>>> volk_32fc_32f_multiply_32fc_a: fail on arch sse
>>> Best arch: sse
>>>
>>> /Users/carlesfernandez/Documents/workspace/gnuradio/volk/lib/testqa.cc:25:
>>> error in "volk_32fc_32f_multiply_32fc_a_test": check
>>> run_volk_tests(volk_32fc_32f_multiply_32fc_a_get_func_desc(), (void
>>> (*)())volk_32fc_32f_multiply_32fc_a_manual,
>>> std::string("volk_32fc_32f_multiply_32fc_a"), 1e-4, 0, 20460, 1, 0) ==
>>> 0 failed [true != 0]
>>> ...
>>>
>>>
>>> I'm quite happy because I see dramatic improvements in some functions
>>> of my interest (basically I want to implement correlators and mixers,
>>> so I'm sensible precisely to this function, bad luck), but this
>>> "generic" superiority in some cases intrigues me. I would appreciate
>>> if anyone can shed some light on the internals of volk, or if I have
>>> to configure or install something else. Anyway, thanks to the
>>> developers for releasing such interesting stuff :-)
>>>
>>>
>>>
>>>
>>> This is the complete output, for the records:
>>>
>>>
>>> volk carlesfernandez$ cmake .
>>> -- The C compiler identification is GNU
>>> -- The CXX compiler identification is GNU
>>> -- Checking whether C compiler has -isysroot
>>> -- Checking whether C compiler has -isysroot - yes
>>> -- Checking whether C compiler supports OSX deployment target flag
>>> -- Checking whether C compiler supports OSX deployment target flag - yes
>>> -- Check for working C compiler: /usr/local/bin/gcc
>>> -- Check for working C compiler: /usr/local/bin/gcc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Checking whether CXX compiler has -isysroot
>>> -- Checking whether CXX compiler has -isysroot - yes
>>> -- Checking whether CX

Re: [Discuss-gnuradio] Using volk in Mac: test report

2012-02-17 Thread Nick Foster 
On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez <
carles.fernan...@gmail.com> wrote:

> Thanks for the inputs!
>
> We are interested in determining the best architecture at instantation
> time. What would be the best strategy? We though about running the
> same operations several times for each architecture, measure the
> results and use the fastest one for the processing blocks. Would this
> be the right approach?
>

Carles,

Run volk_profile. It does exactly what you said, and writes the results to
~/.volk/volk_config. Volk reads this file when it is involked (sorry) to
determine which particular function to execute. So all you do is run
volk_profile once on any given machine, and it's optimized.

--n


>
> Best regards,
> Carles.
>
> On Fri, Feb 17, 2012 at 7:33 PM, Nick Foster  wrote:
> > On Fri, Feb 17, 2012 at 8:14 AM, Tom Rondeau  wrote:
> >>
> >> Carles,
> >>
> >> Thanks for the report! We'll look into those failures. Hopefully just
> some
> >> minor misundertanding.
> >>
> >> As for the generic sometimes being the best arch, I'm not sure I can
> help
> >> too much on it. I can certainly speculate. Having seen this in my own
> >> machines and looked at some of the kernels where generic wins out (which
> >> have some overlap with yours), I think it's something about the
> operation
> >> being performed. First, we might be able to do something a bit smarter
> in
> >> the Volk kernel. But more likely, it's simply because the operation
> being
> >> performed is so trivial that it doesn't really matter.
> >>
> >> Another reason could be that the tests aren't long enough to avoid
> >> OS-level variances while completing a test. The tests use the clock()
> >> function for calculating the time difference, which is only the
> approximate
> >> time of the process. It might mean that we need to run the tests for a
> bit
> >> longer to see if that makes any difference. I have noticed that some of
> the
> >> tests where generic wins, it only wins by a very, very small amount of
> time.
> >
> >
> > Please ignore the "best arch" reports during the QA code execution; it's
> > very often wrong. The "best arch" report is intended for the
> volk_profiler,
> > which reuses the same test code with much larger datasets for better
> > execution time resolution, as Tom suggested. The QA code is only
> intended to
> > show that Volk is working and to find functions which are executing
> > incorrectly. Use volk_profiler to benchmark Volk functions; it will
> create a
> > custom profile for your machine.
> >
> > One caveat -- the dataset size on E100/NEON is enough that the profiler
> > might run for several hours, so either recompile with smaller datasets or
> > avoid the profiler... eventually I guess I'll make the benchmark program
> > benchmark itself to set appropriate dataset sizes.
> >
> > --n
> >
> >>
> >>
> >> Tom
> >>
> >> On Tue, Jan 17, 2012 at 3:26 PM, Carles Fernandez
> >>  wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I would like to use the volk library in a C++ program that uses
> >>> gnuradio-core and currently builds under Linux and MacOS X. In MacOS
> >>> 1.6.8 (Snow Leopard, updated), I used macports for installing
> >>> gnuradio-core (which is in version 3.3, enough for my app). Since, in
> >>> my understanding (please correct me if I'm wrong), volk is a library
> >>> that can live independently from the gnuradio version, I did the
> >>> following:
> >>>
> >>> $  git clone git://gnuradio.org/gnuradio
> >>> $  cd gnuradio/volk
> >>> $  cmake .
> >>> $  make
> >>> ...
> >>> [100%] Built target volk_profile
> >>> $  sudo make install
> >>>
> >>> Then I ran the tests:
> >>>
> >>> $ lib/test_all
> >>>
> >>> All test but one passed, and I see that in some functions the generic
> >>> architecture is the best one, which is beyond my understanding. The
> >>> test that failed is:
> >>>
> >>> ...
> >>> volk_32fc_32f_multiply_32fc_a: fail on arch sse
> >>> Best arch: sse
> >>>
> >>>
> /Users/carlesfernandez/Documents/workspace/gnuradio/volk/lib/testqa.cc:25:
> >>> error in "volk_32fc_32f_multiply_32fc_a_test": check
> >>> run_volk_tests(volk_32fc_32f_multiply_32fc_a_get_func_desc(), (void
> >>> (*)())volk_32fc_32f_multiply_32fc_a_manual,
> >>> std::string("volk_32fc_32f_multiply_32fc_a"), 1e-4, 0, 20460, 1, 0) ==
> >>> 0 failed [true != 0]
> >>> ...
> >>>
> >>>
> >>> I'm quite happy because I see dramatic improvements in some functions
> >>> of my interest (basically I want to implement correlators and mixers,
> >>> so I'm sensible precisely to this function, bad luck), but this
> >>> "generic" superiority in some cases intrigues me. I would appreciate
> >>> if anyone can shed some light on the internals of volk, or if I have
> >>> to configure or install something else. Anyway, thanks to the
> >>> developers for releasing such interesting stuff :-)
> >>>
> >>>
> >>>
> >>>
> >>> This is the complete output, for the records:
> >>>
> >>>
> >>> volk carlesfernandez$ cmake .
> >>> -- The C compiler identification is GNU
>

Re: [Discuss-gnuradio] Using volk in Mac: test report

2012-02-17 Thread Tom Rondeau 
On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster  wrote:

> On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez <
> carles.fernan...@gmail.com> wrote:
>
>> Thanks for the inputs!
>>
>> We are interested in determining the best architecture at instantation
>> time. What would be the best strategy? We though about running the
>> same operations several times for each architecture, measure the
>> results and use the fastest one for the processing blocks. Would this
>> be the right approach?
>>
>
> Carles,
>
> Run volk_profile. It does exactly what you said, and writes the results to
> ~/.volk/volk_config. Volk reads this file when it is involked (sorry) to
> determine which particular function to execute. So all you do is run
> volk_profile once on any given machine, and it's optimized.
>
> --n
>

Carles,
This is discussed on the webpage:
http://gnuradio.org/redmine/projects/gnuradio/wiki/volk

We'll be updating this as things progress with Volk, but the profiler info
is there already.

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

[Discuss-gnuradio] Error calling XMLRPC-Server

2012-02-17 Thread Michael Hartje 
dear readers,

calling the XMLRPC example gives an error:

Executing:
"/usr/src/packages/BUILD/gnuradio-3.5.1/gnuradio-examples/grc/xmlrpc/server_block.py"
Many other examples work fine.

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.7/threading.py", line 530, in __bootstrap_inner
self.run()
  File "/usr/lib/python2.7/threading.py", line 483, in run
self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib/python2.7/SocketServer.py", line 225, in serve_forever
r, w, e = select.select([self], [], [], poll_interval)
error: (4, 'Unterbrechung w\xc3\xa4hrend des Betriebssystemaufrufs')
-8<-

Any help is very welcome.
1. do I need a sw upgrade to anything newer? GRC3.5.1
2. Is python 2.7 for the GRC3.5.1 ok? -- this is the first error
happening with it.
3. I wonder about the blank parameters in the  last line (error reason???)
4. Port 1234 and 8080 is clean and unused -- the server XMLRPC uses 1234
or 8080

Thanks in advance

M. Hartje
--
Prof. Dr.-Ing. Michael Hartje
Labor Hochspannungstechnik / Labor elektrische Messtechnik
Hochschule Bremen 
Neustadtswall 30;   D-28199 Bremen



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

Re: [Discuss-gnuradio] E100/E110 Documentation

2012-02-17 Thread Ben Hilburn 
The E1xx FAQ is a great starting point:

http://code.ettus.com/redmine/ettus/projects/usrpe1xx/wiki/FAQ

Cheers,
Ben

2012/2/17 Matthias Schäfer 

> Hi List,
> is there any documentation about the e-series of the usrps (except the
> application notes and the datasheet) out there?
>
> I'm especially searching for informations about how to install the images,
> how to start and -- at best -- a little example application.
>
> Cheers,
> Matthias
>
> __**_
> 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] E100 compile error: trondeau safe_align branch

2012-02-17 Thread Ben Hilburn 
It doesn't work for me, either.

Cheers,
Ben

On Fri, Feb 17, 2012 at 5:37 AM, Philip Balister wrote:

> On 02/17/2012 02:25 AM, Andre Puschmann wrote:
> > On 02/16/2012 07:16 PM, Philip Balister wrote:
> >>> /tmp/cct93Ve1.s:37: Error: bad instruction `vpadd.f32 d0,d16,d17'
> >>> /tmp/cct93Ve1.s:38: Error: bad instruction `vadd.f32 s16,s0,s1'
> >>> make[2]: ***
> [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/filter/dotprod_fff_armv7_a.c.o]
> Error 1
> >>> make[1]: *** [gnuradio-core/src/lib/CMakeFiles/gnuradio-core.dir/all]
> Error 2
> >>> make: *** [all] Error 2
> >>>
> >>> Any hints/ideas? Thanks!
> >>
> >> I feel like the flags from the toolchain file are not getting through to
> >> gcc, try passing the compiler flags via the command line.
> >
> > For some reason it's not working for me either. I'm always passing the
> > parameters via command line. Not sure whether it's a CMake issue. Is it
> > working for everybody else?
>
> I looked at this the other day and it made me very angry :)
>
> It is on my list of things to figure out.
>
> Philip
>
> ___
> 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] Sampling Rate

2012-02-17 Thread Ben Hilburn 
In the same way that GNU Radio uses complex samples, USRPs also deliver
complex baseband samples; thus, 25 MSPs of complex baseband gives you 25
MHz of bandwidth.

Cheers,
Ben

On Fri, Feb 17, 2012 at 7:30 AM, Ed Criscuolo
wrote:

> On 2/17/12 2:07 AM, guelord ingala wrote:
>
>> Hi,
>> I'm getting confused with the concept of "Sampling rate" to set the
>> UHD:USRP Source and other blocks from the gnuradio-companion. If I'm
>> still right, the sampling rate must be at least the double of the
>> operating frequency. But I can see some working applications when this
>> Nyquist theory is not respected. How come?
>>
>>
> GnuRadio uses complex (I & Q) samples.  This results in twice the data
> per sample, satisfying the Nyquest criterion.
>
> @(^.^)@  Ed
>
>
> __**_
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/**listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Error calling XMLRPC-Server

2012-02-17 Thread mleech 
  

On Fri, 17 Feb 2012 20:39:13 +0100, Michael Hartje wrote: 

> dear
readers,
> 
> calling the XMLRPC example gives an error:
> 
>
Executing:
>
"/usr/src/packages/BUILD/gnuradio-3.5.1/gnuradio-examples/grc/xmlrpc/server_block.py"
>
Many other examples work fine.
> 
> Exception in thread Thread-1:
>
Traceback (most recent call last):
> File
"/usr/lib/python2.7/threading.py", line 530, in __bootstrap_inner
>
self.run()
> File "/usr/lib/python2.7/threading.py", line 483, in run
>
self.__target(*self.__args, **self.__kwargs)
> File
"/usr/lib/python2.7/SocketServer.py", line 225, in serve_forever
> r, w,
e = select.select([self], [], [], poll_interval)
> error: (4,
'Unterbrechung wxc3xa4hrend des Betriebssystemaufrufs')
>
-8

I've used an XMLRPC application as recently as 10 days ago,
but I've been using XMLRPC in Gnu Radio on and off for several years.
Works for me. No special setup required. 

  

Links:
--
[1]
mailto:Discuss-gnuradio@gnu.org
[2]
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] Using volk in Mac: test report

2012-02-17 Thread Carles Fernandez 
Great!

You guys are making all this stuff pretty easy to use, even for
non-experts. Thanks for letting us squeeze our processors :-)

Carles



On Fri, Feb 17, 2012 at 8:33 PM, Tom Rondeau  wrote:
> On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster  wrote:
>>
>> On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez
>>  wrote:
>>>
>>> Thanks for the inputs!
>>>
>>> We are interested in determining the best architecture at instantation
>>> time. What would be the best strategy? We though about running the
>>> same operations several times for each architecture, measure the
>>> results and use the fastest one for the processing blocks. Would this
>>> be the right approach?
>>
>>
>> Carles,
>>
>> Run volk_profile. It does exactly what you said, and writes the results to
>> ~/.volk/volk_config. Volk reads this file when it is involked (sorry) to
>> determine which particular function to execute. So all you do is run
>> volk_profile once on any given machine, and it's optimized.
>>
>> --n
>
>
> Carles,
> This is discussed on the webpage:
> http://gnuradio.org/redmine/projects/gnuradio/wiki/volk
>
> We'll be updating this as things progress with Volk, but the profiler info
> is there already.
>
> Tom
>

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

[Discuss-gnuradio] uhd b100 problems

2012-02-17 Thread dave k 
iam having alot of troubles with my b100. i have to powercycle almost everytime 
to get my flowgraphs running. if i dont i get this
Got a data packet with unknown SID 4294967293

UHD Error:
Got a data packet with unknown SID 4294967293

UHD Error:
Got a data packet with unknown SID 4294967293

UHD Error:
Got a data packet with unknown SID 4294967293

UHD Error:
Got a data packet with unknown SID 4294967293

UHD Error:
Got a data packet with unknown SID 4294967293



any ideas?

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

Re: [Discuss-gnuradio] uhd b100 problems

2012-02-17 Thread Marcus D. Leech 

On 02/17/2012 05:08 PM, dave k wrote:

iam having alot of troubles with my b100. i have to powercycle almost everytime 
to get my flowgraphs running. if i dont i get this
 Got a data packet with unknown SID 4294967293

UHD Error:https://easywebsoc.tdcanadatrust.com/webbanking
 Got a data packet with unknown SID 4294967293

UHD Error:
 Got a data packet with unknown SID 4294967293

UHD Error:
 Got a data packet with unknown SID 4294967293

UHD Error:
 Got a data packet with unknown SID 4294967293

UHD Error:
 Got a data packet with unknown SID 4294967293



any ideas?

___


Fixes for this will be showing up in the "master" UHD repository very soon.

I've been testing them this past week, and things are vastly improved.


--
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] Using volk in Mac: test report

2012-02-17 Thread Nowlan, Sean 
I built Tom's safe_align branch on E100 and ran volk_profile. It segfaulted on 
"RUN_VOLK_TESTS:volk_32fc_s32fc_multiply_32fc_a. I'll get a stack trace for you.

Sean

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org 
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On Behalf 
Of Tom Rondeau
Sent: Friday, February 17, 2012 2:33 PM
To: Nick Foster
Cc: discuss-gnuradio@gnu.org
Subject: Re: [Discuss-gnuradio] Using volk in Mac: test report

On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster 
mailto:n...@ettus.com>> wrote:
On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez 
mailto:carles.fernan...@gmail.com>> wrote:
Thanks for the inputs!

We are interested in determining the best architecture at instantation
time. What would be the best strategy? We though about running the
same operations several times for each architecture, measure the
results and use the fastest one for the processing blocks. Would this
be the right approach?

Carles,

Run volk_profile. It does exactly what you said, and writes the results to 
~/.volk/volk_config. Volk reads this file when it is involked (sorry) to 
determine which particular function to execute. So all you do is run 
volk_profile once on any given machine, and it's optimized.

--n

Carles,
This is discussed on the webpage:
http://gnuradio.org/redmine/projects/gnuradio/wiki/volk

We'll be updating this as things progress with Volk, but the profiler info is 
there already.

Tom

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

[Discuss-gnuradio] Fwd: Re: uhd b100 problems

2012-02-17 Thread Darren Long 
First attempt at posting to the list - didn't spot the need to reply to
all and replied direct by accident.  Obviously my point has been
obsoleted already by the post by Marcus, but it is quoted below anyway.

Cheers,

Darren

 Original Message 
Subject:Re: [Discuss-gnuradio] uhd b100 problems
Date:   Fri, 17 Feb 2012 22:14:47 +
From:   Darren Long 
To: dave k 



I have been having similar issues intermittently, although just
reloading the firmware works for me without the need to cycle power.  
It seems to have improved in the last week or so with updated code. I
use the build-gnuradio script, so not really sure what update improved
it for me as everything gets updated in one go.

Darren


On 17/02/12 22:08, dave k wrote:
> iam having alot of troubles with my b100. i have to powercycle almost 
> everytime to get my flowgraphs running. if i dont i get this
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
> UHD Error:
> Got a data packet with unknown SID 4294967293
>
>
>
> any ideas?
>
> ___
> 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] Using volk in Mac: test report

2012-02-17 Thread Tom Rondeau 
On Fri, Feb 17, 2012 at 5:11 PM, Nowlan, Sean
wrote:

>  I built Tom’s safe_align branch on E100 and ran volk_profile. It
> segfaulted on “RUN_VOLK_TESTS:volk_32fc_s32fc_multiply_32fc_a. I’ll get a
> stack trace for you.
>
> ** **
>
> Sean
>

Really interesting that it's the same block. Hopefully, it's a single,
simple fix. I'll look into it when you can get me the stack trace.

Thanks for reporting!
Tom



>
>
> *From:* discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org[mailto:
> discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] *On Behalf
> Of *Tom Rondeau
> *Sent:* Friday, February 17, 2012 2:33 PM
> *To:* Nick Foster
> *Cc:* discuss-gnuradio@gnu.org
> *Subject:* Re: [Discuss-gnuradio] Using volk in Mac: test report
>
> ** **
>
> On Fri, Feb 17, 2012 at 2:30 PM, Nick Foster  wrote:
>
> On Fri, Feb 17, 2012 at 11:20 AM, Carles Fernandez <
> carles.fernan...@gmail.com> wrote:
>
> Thanks for the inputs!
>
> We are interested in determining the best architecture at instantation
> time. What would be the best strategy? We though about running the
> same operations several times for each architecture, measure the
> results and use the fastest one for the processing blocks. Would this
> be the right approach?
>
> ** **
>
> Carles,
>
> ** **
>
> Run volk_profile. It does exactly what you said, and writes the results to
> ~/.volk/volk_config. Volk reads this file when it is involked (sorry) to
> determine which particular function to execute. So all you do is run
> volk_profile once on any given machine, and it's optimized.
>
> ** **
>
> --n
>
> ** **
>
> Carles,
>
> This is discussed on the webpage:
>
> http://gnuradio.org/redmine/projects/gnuradio/wiki/volk
>
> ** **
>
> We'll be updating this as things progress with Volk, but the profiler info
> is there already.
>
> ** **
>
> Tom
>
> ** **
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc

2012-02-17 Thread Almohanad Fayez 

I also agree that a big issue with gnuradio is that it tries to take over all 
the computing resources in an application but in my opinion that this is not an 
inherent issue with the gnuradio scheduler not wanting to play with other 
applications.  Some people complain that gnuradio doesn't provide an API with 
functions that can be called to a process data in their external applications, 
I haven't tried this per se, but isn't that the purpose behind gnuradio 
supports running c++-only apps?  But people need to be careful what they ask 
for, if they get only an API to call basic gnuradio functionality to process 
data they want to be processed the overall performance might not be acceptable 
because they are ultimately giving up the scheduler.  Processing is done in 
gnuradio the way they are, at least in my opinion, to address the issue of 
running a Synchronous Dataflow (SDF) graphs which is exactly what you want for 
signal processing, and an integral part of running SDF graphs is running a 
suitable scheduler.

What gnuradio lacks is coherent links to the scheduler in my experience it is 
fairly difficult to step through the code with gdb to figure out what the 
scheduler is doing, if users are able to have some control over the scheduler 
or replace it entirely for custom applications where gnuradio needs to work in 
cohesion with other apps then gnuradio can run as part of a larger system 
versus being the only system running.  While this might be outside the scope of 
a GSoC project but it's a necessity for gnuradio to progress beyond its current 
state.

Almohanad (Al) Fayez




-Original Message-
From: Andrew Davis 
To: Jens Elsner ; discuss-gnuradio 
Sent: Thu, Feb 16, 2012 9:03 am
Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc


>I don't agree. We'll hopefully settle the matter some day. :-)
Me too, DREAM is an amazing SDR program that could benefit from
NURadio and show off GNURadio as-well. But this idea has been batted
round before and never really develops, possibly due to the way
NURadio is currently setup. When I get some free time i'll continue
etting some of the python examples ported to C++, so that potential
evelopers who prefer C over python can see how things can be done
rom C world. I think this will get people who find GNURadio to start
orting other C based programs to the GNURadio framework.
On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner  wrote:
 Andrew,

 Am 15.02.2012 19:41, schrieb Andrew Davis:

> Well some major GNUradio program would drive up sales of USRP's :)
>
> Back on topic, IMHO Gnuradio's problem with large apps stems from it
> trying to be the source to sink and everything in between of a radio.


> Lets take DREAM for example, they do transfer functions and digital
> AGC and the likes that GNUradio by design should not do.


 If you could elaborate on this point - why should GNU Radio not implement
 channel equalization (I assume that's what you mean?) or digital AGC?


> If you want
> to re-write DREAM with GNUradio you will end up writing about +200
> blocks, not much fun.


 Since I suggested this particular project, I obviously cannot agree. :-)

 Pulling the code base into GNU Radio might be a nice addition to
 the available receivers and it can be useful for all amateur radio
 operators world wide.

 Plus DRM is broadcasting so we don't need to worry about timing issues,
 a real drawback of GNU Radio (and high level SDR in general).

 How fine the signal processing chain needs to be chopped up is a
 matter of taste and performance, I believe.


> What people want is simple input to there
> program and a simple output API, not there entire program. They don't
> what to figure out how to write a GNURadio block or know anything
> about the complexities of GNURadio. They want to say "get me a signal
> at 100MHz, filter and interpolate to 1ksp with these cutoff
> frequencies then send me the data and let me do the rest", no need to
> know anything about GNURadio, what other API makes you learn as much
> about it?


 I am not sure I understand your point here. That is not GNU Radio, I
 see GNU Radio as a scheduler with a big collection of signal processing
 blocks attached.

 [...]


> Back to DREAM,
> a lot of the filters, audio input/output, signal conditioning, etc
> could be in GNURadio, but a lot of the middle section cannot. GNURadio


 Then it would be nice to find out what exactly is lacking to add this
 to GNU Radio.


> can not be the whole program, just helper functions in big programs
> like this. Only about %20 of DREAM could be replaced with GNURadio API
> calls, but instead you will have to rewrite it %100 as GNURadio blocks
> with the current block to block only mentality 


 I don't agree. We'll hopefully settle the matter some day. :-)

 Jens



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

Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc

2012-02-17 Thread Andrew Davis 
Yes, I could feed the blocks work functions directly, but this is
tricky sometimes. I'm working on a simple program that needs to route
data from different sources to changing functions and blocks and then
to multiple sinks. The current scheduler is just to static in flow for
this task ( I believe, tell me if i'm wrong ).

On Fri, Feb 17, 2012 at 7:17 PM, Almohanad Fayez  wrote:
> I also agree that a big issue with gnuradio is that it tries to take over
> all the computing resources in an application but in my opinion that this is
> not an inherent issue with the gnuradio scheduler not wanting to play with
> other applications.  Some people complain that gnuradio doesn't provide an
> API with functions that can be called to a process data in their external
> applications, I haven't tried this per se, but isn't that the purpose behind
> gnuradio supports running c++-only apps?  But people need to be careful what
> they ask for, if they get only an API to call basic gnuradio functionality
> to process data they want to be processed the overall performance might not
> be acceptable because they are ultimately giving up the
> scheduler.  Processing is done in gnuradio the way they are, at least in my
> opinion, to address the issue of running a Synchronous Dataflow (SDF) graphs
> which is exactly what you want for signal processing, and an integral part
> of running SDF graphs is running a suitable scheduler.
>
> What gnuradio lacks is coherent links to the scheduler in my experience it
> is fairly difficult to step through the code with gdb to figure out what the
> scheduler is doing, if users are able to have some control over the
> scheduler or replace it entirely for custom applications where gnuradio
> needs to work in cohesion with other apps then gnuradio can run as part of a
> larger system versus being the only system running.  While this might be
> outside the scope of a GSoC project but it's a necessity for gnuradio to
> progress beyond its current state.
> Almohanad (Al) Fayez
>
>
> -Original Message-
> From: Andrew Davis 
> To: Jens Elsner ; discuss-gnuradio
> 
> Sent: Thu, Feb 16, 2012 9:03 am
> Subject: Re: [Discuss-gnuradio] "GNU Radio is crap" and GSoc
>
>>I don't agree. We'll hopefully settle the matter some day. :-)
>
> Me too, DREAM is an amazing SDR program that could benefit from
> GNURadio and show off GNURadio as-well. But this idea has been batted
> around before and never really develops, possibly due to the way
> GNURadio is currently setup. When I get some free time i'll continue
> getting some of the python examples ported to C++, so that potential
> developers who prefer C over python can see how things can be done
> from C world. I think this will get people who find GNURadio to start
> porting other C based programs to the GNURadio framework.
>
> On Thu, Feb 16, 2012 at 8:52 AM, Jens Elsner  wrote:
>> Andrew,
>>
>> Am 15.02.2012 19:41, schrieb Andrew Davis:
>>
>>> Well some major GNUradio program would drive up sales of USRP's :)
>>>
>>> Back on topic, IMHO Gnuradio's problem with large apps stems from it
>>> trying to be the source to sink and everything in between of a radio.
>>
>>
>>> Lets take DREAM for example, they do transfer functions and digital
>>> AGC and the likes that GNUradio by design should not do.
>>
>>
>> If you could elaborate on this point - why should GNU Radio not implement
>> channel equalization (I assume that's what you mean?) or digital AGC?
>>
>>
>>> If you want
>>> to re-write DREAM with GNUradio you will end up writing about +200
>>> blocks, not much fun.
>>
>>
>> Since I suggested this particular project, I obviously cannot agree. :-)
>>
>> Pulling the code base into GNU Radio might be a nice addition to
>> the available receivers and it can be useful for all amateur radio
>> operators world wide.
>>
>> Plus DRM is broadcasting so we don't need to worry about timing issues,
>> a real drawback of GNU Radio (and high level SDR in general).
>>
>> How fine the signal processing chain needs to be chopped up is a
>> matter of taste and performance, I believe.
>>
>>
>>> What people want is simple input to there
>>> program and a simple output API, not there entire program. They don't
>>> what to figure out how to write a GNURadio block or know anything
>>> about the complexities of GNURadio. They want to say "get me a signal
>>> at 100MHz, filter and interpolate to 1ksp with these cutoff
>>> frequencies then send me the data and let me do the rest", no need to
>>> know anything about GNURadio, what other API makes you learn as much
>>> about it?
>>
>>
>> I am not sure I understand your point here. That is not GNU Radio, I
>> see GNU Radio as a scheduler with a big collection of signal processing
>> blocks attached.
>>
>> [...]
>>
>>
>>> Back to DREAM,
>>> a lot of the filters, audio input/output, signal conditioning, etc
>>> could be in GNURadio, but a lot of the middle section cannot. GNURadio
>>
>>
>> Then it would be nice to find out what exactl

[Discuss-gnuradio] UHD Announcement - February 17th 2012

2012-02-17 Thread Josh Blum 
Hello list,

A bunch of great work has been merged into the master. For those
following the work on the master branch, and not a release, you will
need to update your firmware and FPGA images:

http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Binary-downloads
http://files.ettus.com/uhd_releases/master_images/

---
-- TX bandwidth doubled with complex-int8 mode
---
In my last announcement, RX bandwidth was doubled with complex-int8
mode. Now for this announcement, the same capability has been developed
for the transmit direction. This means 50Msps for USRP2/N-series and 16
Msps for B100.

To make use of this feature, grab the latest master branch and set the
over-the-wire format to "sc8".
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#a0ba0e946d2f83f7ac085f4f4e2ce9578

---
-- Controlling the dynamic range in sc8 mode
---
The wire format has 8 bit numbers, but the DSP has 16 bit numbers.
Naturally, users will need a way to control how those 8 bits are used
effectively. Previously, the user could supply an arbitrary scalar.
Since, the scalar wasn't very intuitive, it has been replaced with the
following instead:

peak: specifies a fractional sample level to calculate scaling with the
sc8 wire format. When using sc8 samples over the wire, the device must
scale samples (both on the host and in the device) to satisfy the
dynamic range needs. The peak value specifies a fraction of the maximum
sample level (1.0 = 100%). Set peak to max_sample_level/full_scale_level
to ensure optimum dynamic range.

Example: Suppose that you are receiving 50 Msps with sc8 mode over the
wire and fc32 host samples. Full-scale is 1.0, but you know that you
will never see a sample above 0.3 in amplitude. Set peak=0.3 to get the
most out of 8-bit of dynamic range. GRC users: this is the stream args
parameter of the USRP source/sink block.

http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1stream__args__t.html#aa54b7dc3e2c71d11c774d8b4a15984cc

---
-- A path for users to customize the DSP
---
I want to make it easier for users to drop in custom verilog, before, or
after the DDC/DUC, or in other places in the transmit/receive chains.

It is now possible to code custom verilog modules to a specific
interface, and to modify only the top-level makefile to tie a custom
module into the DSP chain. In addition, users can put settings registers
into their own address space which can be accessed through the UHD API
(courtesy of Johnathan Corgan's user register work).

The end result is that users can create custom DSP logic and settings
without diving into the gory details of the existing DSP chains or C++
source to make mods. Clearly, this cannot cover all possible FPGA
modifications, but it should be very useful for most.

A helpful read-me:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt

Templates for custom module interfaces:
http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/show/fpga/usrp2/custom

---

Feedback and testing is always welcome!
-Josh

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

Re: [Discuss-gnuradio] How to get time from GPSDO

2012-02-17 Thread Wu Ting 
Hi, Sean and Josh,

 

Thank you so much for your help. My problem is solved now. Thanks again.

 

Wu

 

From: Nowlan, Sean [mailto:sean.now...@gtri.gatech.edu] 
Sent: 2012年2月18日 1:00
To: Wu Ting; discuss-gnuradio@gnu.org
Subject: RE: [Discuss-gnuradio] How to get time from GPSDO

 

Use the “get_time_now” method, which is callable from C++ or from Python
(through Swig).

 

http://gnuradio.org/doc/doxygen/classuhd__usrp__sink.html#a74c75fc2a20918485
6db674489de748c

 

Sean

 

 

 

From: discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org
[mailto:discuss-gnuradio-bounces+sean.nowlan=gtri.gatech@gnu.org] On
Behalf Of Wu Ting
Sent: Friday, February 17, 2012 7:45 AM
To: discuss-gnuradio@gnu.org
Subject: [Discuss-gnuradio] How to get time from GPSDO

 

Hi all,

 

I know this is a very basic problem. But I have looked for a lot of
information and discussions and still cannot figure out how to do.

 

In my current GNURadio application, I want to get the time produced by
GPSDO. I found this page

 

http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#using-the-gpsdo-in-yo
ur-application

 

and thought usrp->get_mboard_sensor is the function that I need. But I don’
t know how to use this function in GNURadio. It seems that the code is
written in C++. So can I use it directly in GNURadio?

 

Thanks,

 

Wu

 

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

[Discuss-gnuradio] Passing numpy arrays into vector parameters

2012-02-17 Thread Burak TUYSUZ 
Hi all,

I saw that there was a feature request 2 years ago.
http://gnuradio.org/redmine/issues/399
Is there any progress on that or any idea how to do that?
Thank you
-Burak
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio